Yii: Когда использовать однонаправленное наследование таблицы. Уточнение использования и понимания

Question

Предполагая, что у меня есть интернет-магазин, в котором продукты хранятся и продаются либо целым числом, либо десятичным весом. Существуют разные типы продуктов. Не все элементы связаны. Мне нужно решить, следует ли помещать их в отдельные таблицы (нормализовать) или использовать метод, называемый однонаправленным наследованием таблицы, который позволяет мне хранить все продукты в одной таблице, но использовать разные классы моделей для каждого типа продукта.

Простой пример есть.

Рис будет храниться за килограмм (десятичный), в отличие от зерна (целое число). Рис будет продаваться за килограмм (десятичный), но вы не можете продать 1,5 яблок (десятичных).

Это то, на что наследуется одно табличное наследование или я пропустил то, для чего оно предназначено?

DB Пример

CREATE TABLE `product` (
`id` int(10) UNSIGNED NOT NULL AUTO_INCREMENT, 
`name` varchar(255) NOT NULL, 
`unit` varchar(100) NOT NULL, 
`stock` decimal(10,3) NOT NULL, 
PRIMARY KEY (`id`) 
); 

INSERT INTO `product` (`name`, `unit`, `stock`) 
VALUES 
('Rice', 'Kilo', 10.00), 
('Apple', 'Each', 500), 
('Orange', 'Each', 230), 
('Flour', 'Kilo', 55.3), 
('Coke', 'Litre', 123.5); 

модели (только продукт и Kilo блок типа показаны для простоты)

class Product extends CActiveRecord { 
    ... 
     STUFF 
    ... 
    protected function instantiate($attributes) 
    { 
     switch($attributes['unit']) 
     { 
      case 'Kilo': 
       $class='KiloUnit'; 
       break; 
      case 'Each': 
       $class='EachUnit'; 
       break; 
      case 'Litre': 
       $class='LitreUnit'; 
       break; 
      default: 
       $class=get_class($this); 
     } 
     $model=new $class(null); 
     return $model; 
    } 
} 

class KiloUnit extends Product { 
    public static function model($className=__CLASS__) 
    { 
     return parent::model($className); 
    } 
    public function defaultScope() 
    { 
     return array(
      'condition'=>"type='Kilo'", 
     ); 
    } 

    public function rules(){ 
     array('stock', 'numerical'), 
    } 

    public function attributeLabels() 
    { 
     return array('stock' => 'Kilo'); 
    } 

и правила для модели 'в каждой ячейке' будет что-то вроде

array('stock','numerical', 'integerOnly'=>true) 

и attributeLabel для модели «в каждой ячейке» будет что-то вроде

return array('stock' => 'Quantity'); 

Таким образом, если я хочу работать со всеми продуктами, я могу использовать следующее:

$products = Product::model()->findAll(); 
foreach($products as $p) 
{ 
    do something 
} 

Если бы я только хочу иметь дело с продуктами с кило как блок типа

$products = KiloUnit::model()->findAll(); 
foreach($products as $p) 
{ 
    do something 
} 

Answer 1

Одна вещь, я бы, вероятно, изменить то, что вы могли бы сделать, это создать таблицу с именем measurement затем хранить measurement_id в ваш стол продукта. Затем вы можете перенести некоторые из ваших других функций в модель измерения вместо того, чтобы иметь ее в модели продукта. Затем, когда вы создаете продукт, вы можете легко создавать выпадающие списки всех опций measurement. Я не знаю, что в этой ситуации обязательно есть правильный или неправильный путь.

Answer 2

Я сделал немного больше исследований на Одиночный стол Наследование, поскольку я был немного незнакомым с термином и решил, что это действительно заслуживает ответа, а не кучу комментариев.

Наследование отдельных таблиц вступает в игру, когда у вас есть группа похожих объектов, которые необходимо сохранить в базе данных. Вы можете либо разбить объекты на отдельные таблицы, либо если они достаточно похожи, вы можете сохранить их в одной таблице с полем для определения того, что есть. объекты разные, потому что они нуждаются в другой обработке или имеют несколько разные атрибуты.В вашем случае я бы не рассматривал различные единицы измерения, достаточно значимые, чтобы называть их Наследование одного стола, но в целом вы могли бы иметь предметы, запасенные по объему, и предметы, запасенные количеством, которые имеют одинаковый набор атрибутов, но разные методы справиться с истощением запасов или стоимостью, поэтому, я думаю, вы могли бы это назвать технически. Наследование отдельных таблиц. Но я даже не думаю, что это достаточно важно, так как методы обработки этих двух элементов даже схожи.

Вот пример классов предметов, которые, возможно, были бы более похожими на эту концепцию. Подумайте о производственном приложении. В этом случае у вас есть предметы, некоторые купленные, некоторые изготовлены. эти элементы имеют одни и те же атрибуты, но у изготовленного товара есть спецификация материалов и атрибуты, связанные с производственным процессом, в то время как приобретенные товары будут иметь поставщиков и атрибуты, связанные с процессом покупки. вполне возможно, что все эти атрибуты поместились бы в одну и ту же таблицу, некоторые из них были бы нулевыми для купленных предметов, а некоторые были бы нулевыми для изготовленных предметов, но с использованием Single Table Inheritance вы могли бы искать все элементы с одним запросом или заниматься с ними с классом, который знает об их уникальных качествах. В этом случае вы сохраняете некоторое время на объединениях и упрощаете внешний интерфейс, потому что различия намного более поразительны, а союзы SQL могут быть дорогостоящими. Но только для разных единиц измерения? вероятно, не так стоит.

Вот ссылка на документацию Yii на Single Table Inheritance.