Является ли плохой практикой использование одного поля в таблице для хранения ссылки на идентификатор для записей из двух разных потенциальных таблиц? - PullRequest
Новая
       4

Является ли плохой практикой использование одного поля в таблице для хранения ссылки на идентификатор для записей из двух разных потенциальных таблиц?

0 голосов
/ 02 апреля 2020

У меня есть логическое поле в таблице job с именем external. Если оно истинно, то job является внешним, а если ложно, то оно внутреннее, очевидно.

Если job является внешним, то ему необходимо хранить ID, который ссылается на запись в client таблицы, и если она внутренняя, то ей необходимо сохранить ID, который ссылается на запись в таблице staff.

Мне потребуется, чтобы пользователь выбрал, является ли job внутренним или внешне, возможно, даже прежде чем они узнают client или staff для выбора. Поэтому я не могу просто покончить с полем external, хотя я не уверен, будет ли это хорошей или плохой идеей в любом случае.

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

Есть ли проблемы, которые могут это вызвать, и это по какой-то причине плохая практика? Потому что я чувствую, что это вполне может быть.

Я использую Firestore с Flutter, но я думаю, что этот вопрос относится к базам данных в целом.

1 Ответ

0 голосов
/ 02 апреля 2020

У нас был похожий сценарий, где childrow мог указывать на разные родительские таблицы. У нас было два поля: ReferencingTypeName (родительская таблица), ReferencingTypeId (первичный ключ PrentTable).

Проблема в том, что мы не можем создать FOREIGN KEY в этом сценарии. Мы должны были убедиться, что бизнес-логика c правильно с ней справилась.

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

+---------------------+-------------------+
| ReferencingTypeName | ReferencingTypeId |
+---------------------+-------------------+
| Client              | <ClientPrimaryId> |
| Staff               | <StaffPrimaryId>  |
+---------------------+-------------------+
...