В одной операции разные роли ведут свои реквизиты, причем у каждой группы товара свои реквизиты.

Например:
операция: поставка товара.

Продукция: кабель.
Бухгалтерия заносит завод производителя(из справочника производителей кабеля), а кладовщики заносят цвет оплетки, жильность.

Продукция: трансформатор
Бухгалтерия заносит завод производителя(из справочника производителей трансформаторов), тип смазки, а кладовщики ничего не заносят

и т.д.

Как лучше организовать структуру?

С EAV не охота связываться, пока расматриваю такой вариант:
В документе храним все столбцы (для всех реквизитов). А связку организуем в таблице со следующими полями:
- роль;
- группа товара;
- имя столбца из документа.

Что еще можете предложить? Или все таки стоит подумать об EAV?

Сергей Васкецовэто зависит (кроме личных предпочтений и религий) от количества произвольных атрибутов.
Подскажите: какова зависимость?
Предположим, что кол-во реквизитов 400 штук.

Гост ьПредположим, что кол-во реквизитов 400 штук.
Уточню: БД Oracle 10 - в ограничения по кол-ву столбцов не упераемся

Борис Бритвапроблема в том что заводить табличку с 400 столбцами, а заполнять в каждой строке по 10-20 полей оставляя остальными нулями не есть очень хорошо

Чем это не есть очень хорошо?

Борис Бритватем более что атрбиут может появится новый - в таком случае прийдется в DDL переделывать таблицу.

а чем это плохо?
В случаае EAV прийдется DML писать на вставку строки.
Что так, что так, а запрос прийдется писать :)


Борис Бритва
Посмотрите инфу про EAV.

EAV удобен при создании БД, но затем он превращается в головную боль, поскольку любые запросы превращаются в монстров. :)

Сергей ВаскецовПо сути, что кладовщики и бухгалтеры что-то куда-то в номенклатурном справочнике заносят - откровенно говоря бред, но допустим.

Номенклатура одна и таже. А вот доп. свойства с каждой поставкой могут быть разные.

Сергей Васкецов Бухгалтерия не может занести "цвет оплетки" или она вообще не видит такой параметр, как "цвет оплетки"?

Бухгалтерия не видит цвета оплетки - этого нет ни в накладной, ни в сертификате, но зато по спецификации она видит завод изготовителя.
Кладовщики видят товар фактически и видят цвет оплетки. А сертификаты к кладовщикам не поступают, остаются в бухгалтерии

Борис Бритватрудночитабельностью информации

Здесь вижу только одну сложность: поиск поля при модификации самого поля - да и это не сложность, если выполнять запрос в ручную, а не через визуальный редактор.
Кстати, для этих типов таблиц можно создать свой виз.редактор. Для EAV его все равно прийдется создавать.
При выборке и модификации значения атрибута проблем нет - поскольку интерусют же не все сразу, а конкретные поля.

Борис Бритва
Такой вариант тоже подходит. Но если потом эту характеристику решите не использовать и удалить ее или переименовать ее, то строку в таблице проще совращать.


Удаление - плохая операция в БД :)

Борис Бритва
Вы правы, но с другой стороны запросы чтобы выбрать из 400 колонок только нужные в конкретной ситуации могут вызвать те же сложности.

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

Борис БритваУдаление плохая, но если завели неправильно и надо коректно отменить транзакцию? С названием лоханулись или дублировали запись существующую. + другие экстренные случаи.
Ничего не удаляя апдейтом отправляем эти записи в историю. Так надежней - всегда можно восстановить и позволит всегда знать о фактах удаления. А также это даст аналитику: там где много "удалений" надо либо технологию ввода, либо оператора менять :)

Борис Бритва
Зачем же тогда вообще создавать много таблиц в бд если можно обойтись десятком для описания всего? =)

В идеале для каждой сущности своя таблица. В данном случае, сущонсть одна: документ. И плодить лишние таблицы желания (да и необходимости - как понял) нет.

Борис Бритва
В любом случае решение принимать Вам, я могу только посоветовать свою точку зрения, а переубеждать или склонять к ней не собирался )

Спасибо Вам!
Данная дискуссия позволила собрать мысли воедино и прийти к, надеюсь :), правильному решению.