Необходимо построить БД в которой будут документы "Платежное требование",
"Счет", "Счет-фактура", "Информационные письма", "Банковская выписка" и пр.
Очень хочется, чтобы в БД присутствовали связи.

Рассмотрим отдельный случай:
Есть документ платежное требование, который может быть создан на основании счета и на основании счета-фактуры. Я вижу два решения (со связями между таблицами):

1 вариант

* - ключи

Таблица "Счетов"
-------------
*Номер счета
Данные счета

Таблица "Счетов-фактур"
-------------
*Номер счета-фактуры
Данные счета-фактуры

Таблица "Платежные требования на основании счета"
-------------
*Номер платежного требования
Данные платежного требования

Таблица "Платежные требования на основании счетов-фактур"
-------------
*Номер платежного требования
Данные платежного требования

связи
*Счет.Номер счета <-> * Платежное требование на основании счета.Номер платежного требования на основании счета
*Счет-фактура.Номер счета-фактуры <-> Платежное требование на основании счета-фактуры.Номер платежного требования на основании счета-фактуры

Вариант 2

Таблица Документ
--------
* Номер документа
* Тип документа
Общие данные для всех документов (Дата, пользователь добавивший документ и т.п.)

Таблица Счет
--------
* Номер счета
Данные счета

Таблица Счет-фактура
--------
*Номер счет-фактуры
Данные счет-фактуры

Таблица Платежные требования
--------
*Номер платежного требования
Тип документа основания
Номер документа основания

связи
*Документ.Номер документа <-> *Счет.Номер счета
*Документ.Номер документа <-> *Счет-фактура.Номер счет-фактуры
*Документ.Номер документа <-> *Платежное требование.Номер платежного требования
*Документ.Номер документа <-> * Платежное требование.Номер документа основания
*Документ.Тип документа <-> Платежное требование.Тип документа основания

Как сделать лучше.
Предполагается, что база будет большая.

Paul SacksВторой вариан считается более премлимый в практике потому, что он является вариантом классического бухучета.
А если смотреть на базу данных не только с точки зрения бухучета, а с точки зрения программирования и администрирования базы данных. Таблица становится узким местом базы данных.

Александр Гoлдун
И в чем же узость?

1. Для доступа к любому документу программы будет использоваться таблица Документ.
2. Количество строк таблицы Документ из 2 варианта будет в несколько раз больше чем количество строк в любой таблице содержащей документ из 1 варианта (поскольку количество строк в таблице Документ = количество строк в таблице Счет + количество строк в таблице Счет-фактура ...), соответственно я считаю, что поиск по ней, join'ы буду обрабатываться дольше.

Большая - это 30-40 Гб

Если ставить вопрос таким образом, то мне неначем было начинать это обсуждение. Я хотел бы получить мнение разных людей, тем более кто-то может уже и решал похожие вопросы. Вариант №2 более близок мне, но я могу не видеть множества подводных камней, очевидных для других людей.

30-40 Гб - может быть и перегиб, но это размер работающей сейчас БД. Учитывая полнейшую анархию в БД реальный её размер может быть значительно меньше. Полнейшая анархия - это когда в базе данных стали появляться таблицы вида ИМЯ_ПОЛЬЗОВАТЕЛЯ_ИМЯ_ТАБЛИЦЫ, т.е. каждый разработчик создает необходимые себе таблицы для реализации своих задач. Есть задача по созданию новой БД и закачки данных из старой. Задача не только акуальная, но, что важнее, политическая.

ОПСа я не понял зачем во втором варианте нужна таблица документов с общими данными.
Под общими данными документа я понимаю следующие:
Дата документа
Дата внесения документа в БД
Пользователь добавивший документ
Флаг - распечатан документ или нет

to ОПС: Вероятно это издержки объектно-ориентированного программирования. Вы правы - данные о том кто и когда создал документ логично распологать вместе с документом.

to Александр Гoлдун: с Вашими замечаниями, после некоторых раздумий не согласиться сложно.

Всем спасибо.