alex_llЕсть большой соблазн запихать это все в одну таблицу разделив только признаком тип накладной.
В результате эволюции нашей системы все мы пришли к выводу, что документы должны быть в ОДНОЙ таблице. Может быть, кроме только лишь каких-то извращенных. В новой версии именно так и будет. Завтра напишу плюсы этого, сейчас домой пора :).

Теория теорией, но так можно обосновать любой подход в принципе. Так что тут надо больше на практику опираться в конкретной предметной области.

Что дало бы хранение в одной таблице кучи разных документов?

1. Взаимосвязь документов определяется единообразно. Если у нас из прихода генерится расход или наоборот, а тем более взаимосвязь документов склада и коммерческих документов - нет заботы о том, как эту взаимосвязь вывести на экран либо учитывать возможность генерации документа из документа.
2. Если по документу склада приход составил 10 штук, из них 5 зарезервировали для перепродажи, на оставшиеся 5 ДВУМЯ документами перехода права собственности полностью израсходовали приход. Запрос доступного остатка по любому документу в такой системе получается одним запросом к одной таблице.
3. Если основные поля выделить в одну таблицу, а отличительные особенности - в другие и связать их 1 к 1, то при добавлении полей возникает дилема, куда добавлять это поле. В 100% случаев развитие системы приводит к тому, что поле, добавленное в дочернюю таблицу, хочется использовать и для других случаев. Если же добавить его в основную и зарезервировать (не показывать) - при необходимости вместо экспедитора туда можно вбить какого-нибудь приемщика. Через пяток лет для зарезервированных полей найдется такое применение, о котором сейчас даже никто и не подозревает.
4. Если бизнес-процесс на предприятии построен таким образом, что не должно быть документов с неутвержденными проводками (это бывает намного чаще, чем можно себе это представить), то для нахождения таких документов необходимо исполнять запрос только к одной таблице. Потому как взаимосвязь документа и проводки единообразна и выводится совершенно стандартно.
5. Про нумерацию документов писали, если одна табличка - один индекс поднимается, мало того, что кода во всех случаях меньше (типа case), так и серверу проще на самом деле жить.
6. При внесении изменений в триггер меняется все в одном месте, тем более что обработка группы типов документов чаще всего стандартна, например, реализация движения ТМЦ на складе или проверка, что документ утвержден.
7. В сервисные процедуры можно передавать просто ID документа, по этому значению всегда можно будет определить, что это за документ, а если таблиц несколько - придется передавать дополнительную информацию.
8. Клинически проще реализация ссылочной целостности.

Вот, в общем, что вспомнилось. Отмечу, я не агитирую вставлять ВСЕ документы в одну таблицу. Например, документы склада, финансовые, коммерческие, движения ОС, планирования (не финансового),... - в одну. Но бюджетированию там белать нечего, бюджет не связан с оперативным учетом. Проводки - в другую. Это что касается заголовков, составы - тоже в том же количестке таблиц соответственно заголовкам.

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

Теория учит, что если есть новая сущность - надо создавать новую табличку, но практика всегда смеется над такой теорией. Какое счастье, что поставщики, плательщики, сотрудники, юр. лица, пользователи ОС и прочие партнеры хранятся в одной таблице! А в свое время это чуть не про#$али.

Апологеты минимилизма могут про 3 таблички и не вспоминать, теоретически можно и в одной таблице с 2-мя полями, одно из которых IDENTITY, все сделать. Пользоваться этим ровно также невозможно, как и системой из 3-х таблиц.

Marat_LА у вас сколько атрибутов имеют сотрудники?
А сколько фирмы? А как вы это пересекаете?
Или у вас пол-таблицы пустота?
Ну там, ИНН, адрес, еще с десяток будет. ИНН может быть пустой, например. Введены категории партнеров. А плательщик он или контрагент в конечном счете вообще к докуенту относится, в котором он [партнер] используется.

Marat_Lодин только НДС уже создает такое количество разнотипных проводок даже по одному журналу
Кто ж запрещает делать у проводки состав и связать заголвки проводок и документов?

Marat_L(ex: приход оплачен или не оплачен)
Вот этого уже я не понял. Приход - это на склад?

TimKa
Берете код товара из одного документа и кидаете в другой. Поясните в чем удобство-то?
Удобство - вообще этого не делать. Товары - ТМЦ -это справочник. Из документа генерим документ, в который попадают все остатки по нему. Взаимосвязь документа ничего общего с тем, что в них один товар, не имеет, это, например, контроль, что по конкретному заказу не отгружено больше, чем заказано, пусть даже есть 2 корректировки этого заказа, 2 резерва и 5 перемещений, рожденных из этого заказа.

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

TimKaОстатки считать лучше не по документам, а по регистрам учета, имхо
Все зависит от того, как понимать такие остатки. Остаток по заказу я вам привел. ничего общего ни со складскими остатками ни с проводками это не имеет.

TimKaПрепочитаю различать документы и проводки по ним
Я тоже. И зачем только это было писать?

TimKaесли у вас еще и одни и те же поля используются в разных целях, то целостности данных точно придет капут
Что вы понимаете под целостностью данных? Про пяток лет - надеюсь вы не со зла, уж больше живем, и не только мы. Существует вообще концепция согласно которой все поля кроме PK необязательные, а остальное мы на клиенте обставим (слава богу, у нас не так). И ничего, живет и процветает.

TimKaпервые правила нормализации не соблюдаются, а не то что высшие
Идите читайте про нормализацию, а заодно и про денормализацию. И без примеров не приходите. Будем считать, что у нас тут также презумпция невиновности соблюдается. Потому приведите мне пример, что нарушает структура, в которой в заголовке документов склада указано 2 ссылки на склад, вторая заполняется только для перемещения и для обычного прихода пустая.

TimKaзавтра уйдет человек, который помнил кто приемщик а кто экспедитор
Для этого случая есть документация. Да и аргумент какой-то странный. А если уйдет тот, кто помнил, как таблица зовется и поля в ней и куда они ссылаются?

TimKaв одном и том же поле если это отгрузочная - то хранится клиент, а если внутр перемещение - то склад
Не надо впадать в крайности. Склады отдельно, партнеры отдельно, счета отдельно, и т.д. Если поле ссылается на справочник складов, оно не ссылается на справочник партнеров.

TimKaно не можете себе позволить ввести явное правило о том что у каждого документа, сиреч таблицы, будет поле "проведен" ? По моему второе гораздо проще и понятнее
Что значит этот признак? наличие проводок? наличие утвержденных проводок? Зачем он вообще, если его измение ничего не решает? Если его "опустить" - по документу исчезнут проводки, и наоборот?

TimKaтри =заголовок=, =доп поля=, и =детали=
Вы меня с кем-то путаете, я про дополнительные поля в отдельной таблице не писал. А ускорение работы и уменьшение нагрузки на дисковую подсистему в нашем случае абсолютно реальный факт, просто взаимосвязь документов уже частично переделали, так что есть данные, что было ДО и что стало ПОСЛЕ.

TimKaизменить ее, я предпочитаю второе, и уж точно не вижу первое как преимущество
А я предпочитаю сотрудников, не дублирующих код и тестирующих свои доработки. Так как чаще ошибки бывают, когда надо сделать одно и то же в 10 местах, сделали в одном оттестировали, те кто правильно сделал, идут курить бамбук, а остальные - реплицировать изменения в остальные 9 мест, при этом аккуратность и внимательность резко снижаются. Кстати, никто не утверждал, что процеура (=триггер) одна и большая. Да и комментирование кода помогает. Вообще какие-то странные аргументы пошли :).

TimKaВам все равно придется писать код в самой процедуре, которая извлекает тип данного документа, и уж потом производит действия
Есть набор операций, которые я могу произвести с документом независимо от его смысла. Например, проверка утвержденности документа, проводок, проверка на доступность документа конкретному пользователю. Порядка 30% операций (проверок) у нас типичны, остальные группируются по типам документов (например, расчет учетной стоимости расхода вообще не зависит от того, расход это со склада или выдача МБП).

TimKaпотому что не понял, в чем проще, и о какой целостности идет речь. Если в многотабличной системе целостность обеспечивается средствами сервера
Если делать ее декларативно (то есть, через references). Однако еще на заре развития системы от них отказались, из-за реализаци ссылочной целостности на триггерах и групповой проверке ссылочной целостности при груповых операциях элементарно повышается скорость работы.

Marat_LДа, приход на склад от поставщиков. У нас если была предоплата, то НДС приходуется сразу на 19 счет, а если не было - то прячется на другой (непомню какой).
У вас видимо объединено понятие коммерческого документа и документа склада. У нас же у документа склада отсутствуют налоги в принципе, его задача - формировать складское движение и учетную стоимость в заивисимости от ТМЦ, даты, метода учета на складе и еще кучи признаков (в том числе прихода на склад по оплате). Для формирования учетной стоимости на складе неважно, НДС это или нет. В такой формулировке оплачивается ккоммерческий документ, из него рождается прямо или косвенно документ склада (или наоборот, кстати). Далее, проводки можно генерить не для документа, уж если очень хочется, а для взаимосвязи (при всей бредовости такой мысли, имеется бизнес-процесс пости у половины наших клиентов, когда отгрузка и переход права собственности разделены по времени, так просто сделали отдельный документ, по большому счету представляющий пару Акта ППС и документа склада, и по нему генерим проводки). Это если совсем полная задница.

Marat_LКстати оплата у вас тоже в этой таблице?
С оплатами сложнее. Оплаты бывают как таковые (платежка), так и оплаты коммерческих документов (платежкой можно оплатить 2 документа и наоборот), так и оплаты их строк (необходимо для учета в книгах покупок/продаж хотя бы потому, что документ может быть оплачен не полностью). Первые - это финансовые документы, остальные - это разные таблички и таковыми они останутся (это следствие того, что даже оплата документа используется в таком большом количестве различных бизнес-процессов у наших клиентов, в том числе оплата коммерческих документов оплатами коммерческих документов, их просто совсем нецелесообразно в одну кучу с документами валить).

Marat_LНо все-таки сваливать справочники в одно, неужели дает выигрыш по производительности системы?
А справочники в одну кучу и не валятся. У нас порядка двух сотен таблиц под справочники заведено. Если про партнеров - то для меня это один справочник. Может ли быть плательщиком физ. лицо? Да. Может ли быть юридическое? Да. Хотите разделить их по типу партнеров, по категории в отношении той или иной сущности - это всегда пожалуйста, введением поля типа это делается замечательно.

Marat_LДык если надо просто скопировать - зачем внимательность?
Позволю себе пойти на шаг дальше, зачем вообще копировать, если это одно и то же? Речь именно о небольших изменениях, которые иногда забываются.

TimKaКстати отказ от декларативной поддержки в пользу триггерной изза причин повышения производительности для меня соувсем уж новость, интересно, на какой системе так обстоят дела, что код, написаный пользователем работает быстрее встроенного механизма связывания по ключам?
На любой. Это определяется не системой, а прежде всего объемом данных. Условие CONSTRAINT (в принципе любое декларативное) проверяется сервером столько раз, сколько изменяется строк (так как проверить надо для каждой), триггер в этом случае работает 1 раз. Другое дело, заметно это или нет.

TimKaА триггер получается, проверяет всю совокупность строк как одну единицу, непроверяя кждую? Я действительно этот вопрос не изучал, для меня это новость.
В inserted набор строк лежит, их можно одним exist-ом проверить.

Кроме того, возможны ситуации, когда проверка может вообще не понадобиться:
1) если другая более существенная и дешевая по ресурсам проверка выполнена раньше и обнаружена ошибка.
2) если производится репликация данных и данные УЖЕ ПРОВЕРЕНЫ на отправляющей стороне.

Более того, есть ситуации, при которых совершенно невозможно реализовать ссылочную целостность на CONSTRAINT, например, это ВСЕ БЕЗ ИСКЛЮЧЕНИЯ ситуации, когда репликация таблицы осуществляется только через процедуру и на PK таблицы есть ссылки в других таблицах.

По поводу ссылок.
1) Существуют другие сервера, кроме MSSQL (хотя, на MSSQL прирост скорости при работе с группой записей также заметен).
2) Не все слепо принимайте на веру что пишут, самая банальная статья, отражает взгляд автора, а за Use money for Currency я бы сразу уволил (хотя, большинство - разумные вещи).

TimKaхоть и полмира по ней живет
Во-первых, полмира не то что не имеет компьютер, а даже его не видели никогда. Во-вторых, даже если речь идет о правильной половине, а) как-то живет вторая половина? б) разве ж это тоже не теория, только немного другая?

TimKaЛюди спорят, только =собираясь= делать в новой версии по-новому, я же делал и так и сяк, и понял что раздельные таблицы значительно лучше, а против так ни одно аргумента существенного не было выдвинуто, или я не увидел :)
Сделали уже, взаимосвязь, я писал, видимо, невнимательно читаете.

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

TimKaСергей, у вас получается избыточность информации, т.е. если отгрузочная, значит поле должно быть null
1) Это не проверяется, ибо незачем.
2) NULL - нет информации, какая тут может быть избыточность? Вот если бы поле было обязательным и туда бы писали пото же склад что и в первое - тогда та.

TimKaмодифицировать базу практически налету - достаточно запретить выписывать один тип документа, вместо того чтобы останавливать весь процесс, и не греть голову о соблюдении целостности, так как она заложена в структуру средствами сервера.
Достаточно обновление данных производить в разрезе типа документа.

TimKaкуда бы этот набор инсертед девался, или вы считаете - раз триггера нет, то и набора записей inserted нет?
Да. inserted формируется исключительно для триггера, во всех остальных случаях он просто отсутствует, так как неправильные обработанные записи не помещаются в лог.

TimKaа теперь пишете, что Существуют другие сервера, кроме MSSQL
Это относилось к Вашим ссылкам, представленным в качестве аргументов. Они касались только MSSQL.

TimKaпо поводу Use money for Currency была дискуссия на этом форуме, пришли к мнению что это верная позиция, насколько я помню.
Будут проблемы с округлением, зависящие от контекста операции.

TimKaесли надо изменить бизнес правило, добавить одну процедуру на документ итп.
Под if делается и все.

TimKaПро сервера - да существуют и другие, но анализ по всем проводить не собираюсь, вы-то так и не сказали на каком у вас система
Текущее место работы - MSSQL2000 и ASE. До этого приходилось работать и на DB2/INFORMIX/ORACLE. Про наличие сего факта для MSSQL я уже писал.

TimKaПро округление - инетерсно, в каком случае проблем с округлением нет?
Если как numeric. Более того, он на всех платформах проблем не знает.