vladka63Есть логика в вашем ответе, Анна. Бесспорно есть..
А завтра их будет 15..

Хорошо, а что бы вы посоветовали, если бы этого "завтра" не было.
Т.е, точно известно - что единожды будет добавлено наименование с описанием в трех полях.Не надо делать разные таблицы для одной бизнес-сущности, потом будет неудобно с этим работать.

Если не стоит остро вопрос оптимизации хранения (например, там миллиарды записей), то лучше оставить всё в одной таблице.

Щукина Аннаvladka63,

ещё раз, если в первый раз эта мысль была озвучена не достаточно ясно:
заняться нормализацией базы. хотя бы до третьей нормальной формыМне вот непонятно, как это сделать на практике?

Вот у нас есть продукция, там есть записи Экскаваторы и Бульдозеры
У экскаваторов есть атрибут "объём ковша", у бульдозеров нет
Вполне типичная ситуация для любой торговой фирмы, например. Только там 100500 типов товаров, а не два.

Как следует поступить? Делать 2 таблицы? Делать EAV? Делать связанные сущности свойства экскаватора/бульдозера?

ИМХО вполне нормальным является вариант, когда в таблицу запихивают все атрибуты, а заполняют подходящие, хотя, конечно, тут есть недостатки.

alexeyvgВот у нас есть продукция, там есть записи Экскаваторы и Бульдозеры
У экскаваторов есть атрибут "объём ковша", у бульдозеров нет
Вполне типичная ситуация для любой торговой фирмы, например. Только там 100500 типов товаров, а не два.

Как следует поступить? Делать 2 таблицы? Делать EAV? Делать связанные сущности свойства экскаватора/бульдозера?

ИМХО вполне нормальным является вариант, когда в таблицу запихивают все атрибуты, а заполняют подходящие, хотя, конечно, тут есть недостатки.Вообще, такое квалифицированно обсуждают в Проектировании БД, но выскажу такую мысль - нужно исходить из бизнес-смысла этих таблиц.

Если для бизнеса это только "Продукция", то нужно делать одну таблицу. Или одну таблицу, + EAV для свойств.

Если для бизнеса это разные по смыслу сущности, то не надо объединять их в одной таблице. Тогда стандартный подход - делать таблицу Продукция, и 2 подчинённых таблицы со связью 1-1, с специфическим набором атрибутов.

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

PizzaPizzaИМХО зависит от количества продуктов...

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

Я храню
продукты с описанием (id_product, name, etc) (1, экскаватор Э1, дорогой, красивый), (2, бульдозер БМ, дешевый, молодежный)
все параметры продуктов в одной таблице (id_product, id_param_name, value) (1,100,60)
наименования параметров в библиотеке (id_param_name, param_name)(100, скорость)

то есть для любого продукта тут может быть любое количество атрибутов и никаких null

Дальше удобно делать пивотом отчет по известному мне сету параметров или же делать группы параметров в библиотеке (id_param_name, param_name, id_group) и собирать запрос по ним. Опять же в библиотеку можно вынести особенности атрибутов (id_param_name, param_name, type, group) (100, скорость, км/ч, group). С группами можно конечно уйти в спираль нормализации и бесконечности справочников, но это уже зависит от задачи и рвения разработчика.

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

Но для ТС я такого не посоветую, не зная, нужно ли такое усложнение.

И даже EAV - зачем это? Какой нибудь парикмахерской?
10 лет у фирмы были продукты с 60 параметрами, потом появились продукты с 3мя, и ещё 10 лет ничего не поменяется. А потом фирма исчезнет, или все перейдут на нейронные компьютеры.

И зачем бизнесу вкладывать бабло в изменение модели данных и приложений, что это им даст, какой навар? Удовлетворение программиста от "нормализации"?
Или возможность добавить через 10 лет новый параметр одним нажатием кнопки? А эта возможность позволит сэкономить, уволив их единственного программиста? Если нет, то какой смысл делать одной кнопкой? Начальник распорядится - программист добавит параметр, без всяких EAV

Я попытался дать рецепт, исходя из формулировок ТС, ИМХО не нужно ему никаких изменений модели данных, для их бизнес-процессов, нагрузок, объёмов, частоты изменений, сложности данных и т.п. Просто ждя некоторых типов использовать 3 поля, этого достаточно.