вопрос с базой данных вопрос

Question

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

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-синтаксис, а затем как второй вариант, дополнительные функции базы данных, такие как trigger 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 = «г» и title_xcode = «р»

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