а зачем нужна таблица tt_movement?

NeoxПоказывает с какого прихода списывается товар(расходом)а почему тогда она устанавливает связь между "головами" документов, а не между отдельными позициями?

DymytryУважаемые,
а объясните новичку вот этот момент в дискуссии: - {нежелательно делать} вынесение в отдельные таблицы товаров (таблица товаров должна быть одна)
- Для склада - да. Для витрины - не факт. Когда номенклатура стабильна, а нагрузка высока применение структурированных данных станет предпочтительнее с т.з. производительности.Имеется ввиду что если товаров слишком много, то общая таблица будет слишком большой и медленной?Не будет. Деление товара на разные таблицы по видам, имхо, имеет смысл в настолько узком случае (очень высокая нагрузка, немного видов товаров, редкие появления новых видов товаров, крайне редкие изменения перечня характеристик товаров), что не стоит на него заморачиваться.

DymytryНе совсем понятно, как вообще можно сделать общую таблицу по товарам, если у них разное количество параметров. Например товар "утюг" имеет параметры "вес" и "производитель", а товар "холодильник" - еще и "цвет", "число отсеков", "наличие морозилки". Как их объединить в одной таблице? Я вижу варианты:
1) сделать таблицу со всеми возможными колонками - то есть и морозилка, и вес утюга, и в той строке где параметр не нужен - ставить null.
2) сделать таблицу с общими для всех товаров параметрами (цена, название), а то что специфично (наличие морозилки) - хранить в отдельных таблицах для каждого типа товара, а потом делать join.

Какой способ лучше?Вроде бы уже неоднократно, в т.ч. и в данном топике, обсудили, что 2-ой вариант правильнее.

Dymytrymiksoft, спасибо за совет.

Во втором варианте мне не очень нравится такой побочный эффект:
Допустим я пишу URL запрос для выбора товаров вида &type=phone&country=korea&company=samsung чтобы посмотреть все телефоны самсунг из кореи. Так вот в программе (в моем случае это java) мне придется разбирать какие поля к каким таблицам относятся. Ведь часть полей относится к общей таблице, и часть к таблицам по типам товаров. И чтобы транформировать URL запрос в SQL запрос мне надо это знать. В итоге мне придется как-то жестко вбивать названия полей в свой код, или каждый раз считывать их из базы. Что не очень как-то. Или это можно обойти?Во-первых, если у вас есть таблица с фиксированными полями, то нет ничего страшного в том, чтобы жестко вбивать имена полей из нее в код. Ведь для остальных таблиц Вы все равно это делаете? Тем более, что это можно автоматизировать, например, генерацией некоего фрагмента кода на этапе создания/модификации этой таблицы.
Во-вторых, конкретно у товара можно вообще все характеристики хранить в EAV-е и тогда не нужно будет делать выбор какое поле из какой таблицы.

Кстати, тут:miksoftDymytry2) сделать таблицу с общими для всех товаров параметрами (цена, название), а то что специфично (наличие морозилки) - хранить в отдельных таблицах для каждого типа товара, а потом делать join.

Какой способ лучше?Вроде бы уже неоднократно, в т.ч. и в данном топике, обсудили, что 2-ой вариант правильнее.я ответил неправильно, т.к. неправильно прочитал Ваш пост.
Правильным вариантом я считаю хранение атрибутов товара в EAV-е - так, как сделал топикстартер в последнем его варианте (или похоже).

DymytryСпасибо!

А правильно ли я понял, что в таком случае в моей таблице аттрибутов мне придется все их значения хранить в одной колонке, то есть все данные будут одного типа (скорее всего VARCHAR)? Нет ли в этом плохого? Ведь если я занесу туда например цену, то я не смогу сортировать и фильтровать данные по ее текстовому значению.Тут возможны варианты.
Во-первых, значения атрибутов можно нормализовать, т.е. в основной табличке оставить только их id, а их самих хранить в отдельной таблице(-ах), где уже больше пространства для маневра. В т.ч. сортировку можно задавать дополнительным числовым полем.

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

DymytryНо в итоге получается что наличие дополнительной таблицы для данного типа товара неизбежно. Там может быть цена, геометрические размеры, вес и другие цифровые параметры по которым возможен поиск и сортировка. Возникает вопрос: а если доп. таблица неизбежна, то зачем EAV?Эта таблица одна для всех типов товаров, а не для данного типа.