Это хороший случай, чтобы использовать EAV или нет - PullRequest
Новая
       25

Это хороший случай, чтобы использовать EAV или нет

0 голосов
/ 29 ноября 2018

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

В моей ситуации на данный момент существует только несколько типов (скажем, 8), но в ближайшем будущембудущее с почти 100% уверенностью может расти.Но рост контролируется мной, а не определяется пользователями.Это будет зависеть от меня, чтобы вырастить тип продукта.

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

Ответы [ 3 ]

0 голосов
/ 29 ноября 2018

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

Таким образом, если продукт содержит «Cogs», то у вас есть таблица с «количеством зубов», «радиусом» и т. Д. Другой тип продукта имеет «Scews» со свойствами «Длина», «Рилинг» и т. Д. И еслиТип продукта имеет как винтики, так и винтики, он просто имеет отношение к каждому из этих подтипов.

0 голосов
/ 29 ноября 2018

Многое зависит от операций, которые будут выполняться над сущностями.Если вы будете:

  • часто добавлять новые атрибуты к продуктам;

  • добавлять много типов продуктов;

  • реализовать полный поиск по типу продукта (или другую функцию «полный тип продукта»);

Я рекомендую использовать EAV.В прошлом я реализовал структуру данных EAV с ADO.NET и MS SQL, и у меня нет проблем с производительностью.

Кроме того, Мортен Борк выше рекомендует использовать «подтипы».Но если вы хотите реализовать некоторые функции «полного типа продукта», я думаю, это будет сложнее, чем использовать модель чистого EAV.

0 голосов
/ 29 ноября 2018

Нет короткого хорошего или плохого ответа на эту проблему, потому что это зависит от многих вещей.

  • У вас есть много типов продуктов?
  • Как вы думаете, каждыйиз них будут развиваться (подумайте, что произойдет, когда вы добавите новые поля к продуктам)?
  • Нужно ли обрабатывать «варианты» продуктов?
  • Намерены ли вы добавить полностьюновые виды продукции?

и т. д.EAV - это, вероятно, хороший способ, если вы ответите, если ответите «да» на некоторые или все эти вопросы.

Что касается C #, в прошлом я реализовал с ним каталог данных EAV и использую Entity Framework поверх SQL Server (то есть СУБД).Это работало хорошо для меня.

Но если вам нужно работать со многими продуктами, производительность может быстро стать проблемой.Вы также можете найти решение «NoSQL», вы об этом думаете?

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

...