Кот Матроскин,

Дело, дело предлагайте... а не цепляйтесь за слова...

Mr.FontaineВидится невооружённым глазом, что велика вероятность иметь в БД товары "Молоко Весёлый молочник 1л", "Молоко Веселый молочник 1 л.", "Молоко 'Веселый молочник' 1литр"

Вероятность равна нулю, товар вводится и продаётся или по штрих коду или по артикулу (коду) и соответственно описывается в БД один раз (если вы не про Эксель конечно)
Mr.Fontaineне смог придумать как в три поля запихнуть параметры автомобиля

Зайдите на любой сайт. Чтоб продать, достаточно BMW / М4 / купе

vmag(нужно только задействовать мозг...
если своего нет - то чужой):

Mr.FontaineНо Вы почему-то решили, что Ваш вариант лучше. Ну вот и докажите чем лучше-то?

Это вы решили, что я решил, а я просто поделился своим опытом....

Mr.Fontaineвот и поделитесь опытом добавления характеристики "Синяя" к товару "Рубашка / муж. хлопок Турция/ р. 52"

Дальше уже всё платно будет ...
- Самый простой вариант это одно или несколько полей memo для хранения характеристик товара...
- Но можно сделать и отдельный классификатор Параметров (Код_Параметра, Название_Параметра),
тогда к товару добавится подчиненная таблица, связующая её с классификатором Параметров, ну для
рубашки это как к бричке пятое колесо, возьмём лучше для примера авто BMW / M4 / Купе:
Код_Параметра, Название_Параметра
1, Цвет
2, АКПП
3, Тип салона
4, Кузов
5, ГУР
..............
Тогда Связующая Таблица параметров к BMW / M4 / Купе будет, например, такая (фрагмент):
Key/Код_Товара/Код_Параметра/Значение
1,345(типа код этой бэхи из таблицы товар), 1 (типа код параметра), Черный
2,345(типа код этой бэхи из таблицы товар), 2 (типа код параметра), Есть оба варианта
3,345(типа код этой бэхи из таблицы товар), 3 (типа код параметра), Кожаный
4,345(типа код этой бэхи из таблицы товар), 4 (типа код параметра), Оцинкованный
5,345(типа код этой бэхи из таблицы товар), 5 (типа код параметра), Электрический
.................................................................................................

- Ну и получается, что количество параметров - бесконечно (добавляются только записи в классификатор
параметров, а не поля в БД)...
- Для каждого экземпляра товара в связующей таблице свой эксклюзивный набор параметров и их значений...
- Если торговая организация много профильная, то сам классификатор параметров тоже может быть, например,
хотя бы двух уровневым, дабы не предлагать для заполнения параметров рубашки параметры авто:
Код_Параметра, Код_Направления, Название_Параметра
- ну и предвидя возможные палки в колеса типа "параметры могут иметь разные величины", отвечаю сразу,
что нет проблем: любой параметр хранится как тест, а в классификаторе параметров хранится описание его типа (тоже поле текст или код типа 1 - это текст, 2 - это дата, 3 - это Денежный...)
(если кому то вдруг понадобиться на перспективу и про функции преобразования типов тоже сообразите сами)...
- Итого Классификатор параметров будет примерно такой:
Код_Параметра, Код_Направления, Название_Параметра, Тип_Параметра
1,1(код направления одежда),Цвет,txt
2,2(код направления авто),Год Выпуска,Date

Ыи чем вышеописанное принципиально отличается о ранее упомянутого EAV?

Ну дак, это я его просто прикрутил для примеру в конце, а так оно и не нужно то (мне по крайней мере)...

"Другой проблемой EAV является кажущаяся сложность изучения начинающими разработчиками. Как мы выяснили в этой статье, всё работает очень просто и понятно. Надеюсь, что она помогла вам."

http://gurumagento.varshevsky.com/struktura-bazy-dannyx-magento-znakomstvo-s-eav.htm

SERG1257полностью проигнорированной в статье является полная незащищенность от ошибок . Такая база легко съест все что туда положить - в любую таблицу, любое поле, любое значение, но будет ли такое питание здоровым?

А с этим никто и не спорит - у нас же как ? А... так можно всё пихать - и пошло, поехало... я исключительно
прикрутил классификатор параметров для примера тем, кому мало трёх уровней классификатора описания товара или действительно
без параметров - ну никак (в результате получился гибрид)... И всё равно эту ветку (EAV) не желательно
использовать как основную колею, для продаж и учета вполне хватит таблицы товар и трёх уровней обычного классификатора описания товара... А эту дополнительную ветку с классификатором параметров
можно нарастить со временем и использовать, например, для печати полных характеристик того же авто на
ценник в авто салоне или для более точного поиска товара по определенным характеристикам...
Думаю, что если реализовать на практике именно такой гибрид, то с очень большой вероятностью,
после начала процесса торговли, ветка ЕАV в этом гибриде так и останется не востребованной....