Разработка базы данных «EAV» или «Наследование классов / бетонных столов» для контроля запасов - PullRequest
Новая
       7

Разработка базы данных «EAV» или «Наследование классов / бетонных столов» для контроля запасов

3 голосов
/ 05 августа 2010

Я разрабатываю систему управления запасами для строительного проекта. Кладовщик несет ответственность за добавление новых запасов и их распределение / возврат сотрудникам. Предметы (и, следовательно, их атрибуты) будут очень разнообразными; например стальные изделия, одежда, установки / машины, инструменты и т. д.

У меня вопрос: стоит ли использовать схему Наследование классов / бетонных таблиц или схему на основе EAV. Я не знаю, какие атрибуты будут у элементов, поэтому, вероятно, подход наследования классов / бетонных таблиц потребует от конечного пользователя добавления новых таблиц в базу данных (возможно ли это?).

Пожалуйста, смотрите мою предложенную схему EAV . Будет ли это разумным решением? Думаю, я прав, говоря, что для идентификации товара на складе необходимо выполнить несколько самостоятельных объединений в запросе к таблице 'EV'?

N.B. Разработка с использованием PHP, MySQL и Zend Framework.

Ответы [ 2 ]

1 голос
/ 05 августа 2010

  • Если изменения атрибутов немногочисленны, переходите к Наследование таблиц , но изменения в схеме должны быть сделаны вами или администратором базы данных.Программная модификация схемы на основе пользовательского ввода кажется плохой идеей.

  • Если изменения атрибутов встречаются довольно часто, рассмотрите возможность использования ориентированной на документы базы данных как MongoDB или CouchDB .

  • Если изменения атрибутов являются общими и вы ограничены реляционными базами данных, используйте EAV.

0 голосов
/ 08 сентября 2013

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

Предположим, вы создаете интернет-магазин, если у вас есть разные товары с разными атрибутами.Обычно продукт использует набор атрибутов.Используя шаблон наследования таблиц классов, вы можете иметь по одной таблице на каждый набор продуктов, наследуя общую таблицу с общими атрибутами продукта.Когда требуется новый атрибут, у вас есть две опции:

  • изменить таблицу множеств и добавить новый столбец с именем атрибута
  • создать новый набор (то есть новую таблицу) сновый столбец и установите текущий набор продуктов для наследования нового, добавив, таким образом, новый атрибут.

Изменение таблицы во время выполнения может действительно вызвать проблемы из-за блокировки, возникающей во время изменения.Однако, начиная с MySQL 5.6, программист может указать тип LOCK, т.е. LOCK = NONE, а также ALTER ONLINE | OFFLINE.Очевидно, что поставщики БД работают в этом направлении, чтобы обеспечить возможность чередования баз данных во время выполнения.

Проблем с блокировкой таблицы также можно избежать / минимизировать.Проблемы с блокировкой обычно возникают при изменении огромных таблиц, т.е. более 100 тыс. Записей.Однако наследование позволяет распределять продукты в разных наборах и, таким образом, иметь относительно небольшое количество записей в таблице.

Например, если у нас есть 10 различных типов продуктов, у нас есть 10 различных таблиц.Предположим, что у нас есть 10 000 товаров для каждого типа, это означает, что у нас более 100 000 товаров, однако добавление нового атрибута в набор приведет к добавлению нового столбца в таблицу, содержащую только 10 000 строк.Добавление нового столбца в таблицу с 10-тысячными строками займет меньше секунды, так что изменение схемы базы данных во время выполнения при работе с наследованием таблиц классов - действительно плохая идея?

Я был бы рад услышать большемнения здесь на этот.Спасибо, ребята.

...