Альтернатива EAV?

Question

[magary4]

только что пришла в голову идея, и сразу решил предложить на критику здесь

возьмем классический пример с продуктами и их параметрами
допустим нас устраивает что параметров специфических типу продукта будет до 15.
что если создать в таблице 15 полей extra1, extra2, ... extra15
а уже в бизнес-логике реализовать согласованность полей бд к свойствам обьекта.

public function getProducts() {
  $items = query ( ..... );
  
  foreach($items as $item) {
    switch($item->type) {
      case "tv":
         $product = new Product();
         $product->matrix = $item['extra1'];
         $product->remoteControl = $item['extra2'];       
         .................
       break;
       case "dvd":
         $product = new Product();
         $product->format = $item['extra1'];
         $product->voltage = $item['extra2'];       
         .................
        break;
     }
  }

}

ну и реализовать поиски по аналогии, т.е. если ищем морозильную камеру с 5ю ящиками, знач описываем что надо искать запись где extra12=5

Answer 1

[Yuri Shikanov]

костыль это, а не альтернатива, уже давно в нормальных СУБД, вроде PostgreSQL есть типы данных вроде массива и хэш-таблицы

Answer 2

[Igor Kalashnikov]

Это вполне себе нормальный подход. Встречал такое (param1,param2) даже в крупных энтерпрайз решениях, т.к. не всегда можно альтер тейбл эффективно выполнить, чтобы добавить поле, и (или) ваш кейс, когда есть набор атрибутов которые свойственны части сущностей и не пересекаются.

Только маппинг для каждой сущности я бы вынес отдельно:

var productToExtraMap = {
  'tv'  : {
   matrix :  'extra_1',
   remoteControl : 'extra_2'
   },
  'dvd' : { 
    ...
   }
}

и по такой мапе собирать объекты.

Тогда у вас будет 1 место где собирается объект и 1 место где декларируется маппинг. Не будет лишних вложенных ифов и т.п.

П.С. Мапу можно и по другому развернуть, это уже как вам удобнее.