SQL - внешний ключ, ссылающийся на первичный ключ разных таблиц (Postgres)

Question

Это для проекта.Я создаю базу данных для различных видов записей для офиса.Существует таблица, в которой собраны все первичные ключи этих таблиц записей.Итак, мне нужно иметь внешний ключ, ссылающийся на эти таблицы.И я потерян.Я спросил моего очень верного друга в Google, но я не понял некоторых возможных ответов на этот вопрос.

Вот что я придумал (имена таблиц не являются их настоящими именами, просто хочу, чтобы это былоздесь).

Редактировать: я использую Postgres

RecordsTable:

recordId -> references record1 id,record2 id,record2 id
docId -> identifies what kind of record it is
filingDate

Record1:

id
attribute2
attribute3

Record2:

id
attribute2
attribute3

Запись 3:

attribute2
attribute3

На самом деле, записи 1, записи 2 и записи 3 имеют более 30 столбцов в каждом (представьте, например, свидетельство о рождении)

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

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

Если что-то неясно, пожалуйста, дайте мне знать, чтобы я мог объяснить это подробнее,Заранее спасибо

Answer 1

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

Чтобы сохранить id уникальным для всех трех таблиц, вам потребуется один столбец identity.(Если вы не используете Oracle или Postgres, если это так, отредактируйте ваш вопрос.) Таким образом, пользователи должны будут получить идентификатор записи из таблицы «Записи», прежде чем они смогут заполнить детали.Возможно, вы сможете создать пользовательский интерфейс, который сделает это за них.

RecordsTable: id int identity, filingDate
Record1: id int foreign key references RecordsTable(id), ...
Record2: id int foreign key references RecordsTable(id), ...

Вы получите тип документа, например:

select  case
        when record1.id is not null then 'Type1'
        when record2.id is not null then 'Type2'
        ...
        else 'Unknown'
        end
from    RecordsTable rt
left join
        Record1 r1
on      rt.id = r1.id
left join
        Record2 r2
on      rt.id = r2.id

Answer 2

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

Если вам нужна ваша основная таблица для ссылки на любую из трех разных таблиц (и у них такие разные столбцы, что вы не можете объединить их в одну таблицу), настройте основную таблицу следующим образом:

RecordsTable:
Id -> primary key for the table
docType -> identifies what kind of record it is: 1, 2, or 3
docID1 -> Foreign key to table1, if docType = 1; NULL otherwise
docID2 -> Foreign key to table2, if docType = 2; NULL otherwise
docID3 -> you get the idea
filingDate

Но если у вас есть три вида сущностей с очень различным содержанием, вам действительно нужно перечислить их все вместе? Может быть, вы не совсем, и в этом случае вы можете просто сохранить их как отдельные таблицы. Если имеет смысл перечислить их все вместе, концептуально у вас есть одна сущность («по звучанию») с тремя подтипами. Возможно, имеет смысл упростить задачу для себя и сохранить их в одной таблице с множеством пустых столбцов (столбцы VARCHAR не занимают места, когда они пусты). Это немного расточительно, но у современных компьютеров есть свободное место и мощность, и ваше время ценно. Но вы возражаете,

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

Это не проблема! Сделайте запрос SELECT только со столбцами, которые вы хотите показать для сводки. Если пользователь выбирает запись, тогда сделайте SELECT * и покажите полный результат.

Если вы хотите разобраться с нечастыми полями, сделайте это, как указано выше.

По сути, вам нужно немного программировать. Не думайте, что дизайн вашей базы данных - это вся ваша программа: задача базы данных - хранить данные, а задача приложения - что-то с ними делать.