вопрос проектирования базы данных

Question

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

xcode
id code
r  role
p property

code
r admin
r staff
p title
....

тогда я бы хотел иметь представление:

role (select * from code where xcode='r')
r admin
r staff

property (select * from code where xcode='p')
p title

тогда предположим, что у нас есть сущность

myentity
id - 1
role - admin (foreign key to role)
title - title (foreign key to property)

Очевидно, я не могу создать внешний ключ для представления, но это должно сказать идею, которую я имею в виду. Как я могу отразить такое поведение, используя, когда это возможно, стандартный синтаксис SQL, а затем в качестве второй опции, дополнительные возможности базы данных, такие как триггер ECC ...?

Потому что, если я скажу, что роль и заголовок в myentity являются внешним ключом для «кода», то вместо представлений ничто не помешает мне вставить роль в поле заголовка.

спасибо Leonardo

Answer 1

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

Преимущества таблицы на код:

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

Кроме того, я заметил, что вы хотите иметь возможность развертывания «на любом сервере базы данных». В этом случае избегайте триггеров. Триггеры обычно плохие новости в большинстве сценариев, но они имеют синтаксис для конкретного продукта.

Answer 2

То, что вы пытаетесь сделать, в большинстве случаев является ошибкой анти-паттерна и дизайна. Просто создайте разные таблицы вместо представлений.

В некоторых редких случаях такой дизайн имеет смысл. В этом виде включите поле xcode в первичный ключ / внешний ключ. Итак, ваша сущность будет выглядеть так:

myentity
id - 1
role_xcode
role - admin (foreign key to role)
title_xcode
title - title (foreign key to property)

Затем вы можете создать проверочные ограничения для принудительного применения role_xcode = 'r' и title_xcode = 'p'

(извините, я не знаю, являются ли они стандартными, они существуют в oracle и настолько просты, что я ожидаю их и на других rdbms)