Плюсы и минусы различных схемных схем для таблиц, которые имеют отношение к одному элементу данных

Question

Я разрабатываю систему, которая будет иметь базу данных.Я имею в виду, что каждая таблица имеет произвольный PK, генерируемый и поддерживаемый системой.

Моя среда (для разработки и производства) - Windows 7;Delphi;и встроенная база данных (вероятно, Firebird).

Мои структуры данных включают в себя одну таблицу OWNER, с которой связано очень мало информации - вероятно, не больше, чем имя и описание.Остальная часть структуры данных будет состоять из 50 таблиц, каждая с именем и описанием, а также со списком других атрибутов - скажем, в среднем по 20 на таблицу.Кроме того, может быть 20 ассоциативных таблиц, большинство из которых будут иметь только атрибуты FK, хотя небольшая часть будет иметь дополнительные атрибуты.Я намерен (по крайней мере, начать с) полностью нормализовать схему.

Для данного ВЛАДЕЛЬЦА большинство таблиц будет иметь O (от 10 ^ 3 до 10 ^ 4) записей, хотя одна или две будут иметь O (от 10 ^ 5 до 10 ^ 6).Количество ВЛАДЕЛЬЦЕВ, вероятно, будет O (от 10 ^ 2 до 10 ^ 3).Большинство обращений, вероятно, будут кластеризованными - будет существенное количество обращений для одного ВЛАДЕЛЬЦА, а затем значительное количество обращений для другого ВЛАДЕЛЬЦА.

Каждый элемент данных будет принадлежать ровно одному ВЛАДЕЛЬЦУ и не может бытьпереводится из ВЛАДЕЛЬЦА в ВЛАДЕЛЬЦА.Все обращения к базе данных будут знать, какой владелец они используют;доступ никогда не будет иметь доступа к содержимому более чем одного ВЛАДЕЛЬЦА.

Мне известны следующие три варианта проектирования моей схемы:

1. Используйте таблицу OWNER, как описано.Используйте OWNER PK в качестве внешнего ключа в каждой таблице (хотя, возможно, не в ассоциативных таблицах).Добавьте OWNER PK в качестве дополнительного условия в каждый запрос, объединение, хранимую процедуру, представление и т. Д.
2. Добавьте столбец в таблицу OWNER, содержащий небольшой код - скажем, четырехзначное целое число.Для каждого ВЛАДЕЛЬЦА создайте дубликат набора таблиц - к именам таблиц для конкретного ВЛАДЕЛЬЦА будет добавлен соответствующий код в качестве суффикса.Для этого потребуется каждый доступ, чтобы предварительно получить суффикс-код из базы данных.Тогда доступ будет иметь соответствующий набор таблиц.
3. Для каждого ВЛАДЕЛЬЦА создайте дублированную базу данных с дублирующимися таблицами и именами таблиц.Это подразумевает, что, вероятно, будет вспомогательная общая база данных, содержащая данные о соответствующей дублирующей базе данных.Опять же, эта общая база данных должна была бы получить доступ перед любым доступом - или серией обращений для одного конкретного ВЛАДЕЛЬЦА.

Каковы плюсы и минусы этих различных подходов?Я пропустил какие-либо другие варианты общего дизайна?

Изменить отредактировано - вместо этого я предоставил свой собственный ответ.

Answer 1

Вариант № 1 безусловно лучший. Очевидно, что вы планируете использовать сгенерированный системой идентификационный номер и для этой записи ... в противном случае вы столкнетесь с проблемой, если ваш OWNER pk - это имя человека, и у вас будет несколько Джона Смита.

Вариант № 2 будет работать нормально, но добавляет слишком много сложности. Пока у вас уже есть OwnerId в качестве PK в таблице OWNER, используйте jsut fk для остальных и сэкономьте дополнительные издержки и усилия.

Вариант № 3. Эта опция хороша, если у вас плохой интерфейсный интерфейс и вы хотите иметь возможность легко читать записи вручную и разбираться в них ... но все дополнительные таблицы замедляют работу и создают дополнительные подпрограммы, которые имеют быть записанным во внешний интерфейс для отслеживания таблиц.

Answer 2

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