Как я могу ограничить отношение внешнего ключа, где он может ссылаться на несколько других таблиц?

Question

У меня есть таблица под названием inventory_movements, и я планирую сохранить движение продукции внутри и вне склада, он имеет такие поля, как

1- movement_id(PK) 
2- product_id(FK) 
3- quantity int 
4- unit_price decimal 
5- movement ENUM('in','out') 
6- date datetime 
7- ????????? (reference)(e.g. sell(out)- purchase(in)- fire loss(out) 
- sales return (in) - purchase return (out) 

Моя проблема заключается в том, что я хочу, чтобы сохранить ссылку движения (причина движения), где находится идентификатор заказа, или идентификатор покупки, идентификатор возврата покупки, .... и т. д.

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

очень плохое решение состоит в том, чтобы добавить столбец для каждого ссылочного типа (идентификатор продажи, идентификатор покупки, идентификатор продажи и т. Д.) И заполнить правильный номер в каждом движении, а остальные - недействительными, но это проклятие против нормализация, и я не могу добавить больше ссылок позже.

Что делать в этой ситуации?

пожалуйста, считают, что я очень новичок, благодаря

Answer 1

У вас есть несколько подходов. Один из них состоит в том, чтобы иметь один внешний ключ для типа таблицы с ограничением, гарантирующим, что ровно один не является нулевым. Я согласен с тем, что это неудобно, но некоторые люди предпочитают его (например, Дэвид Феттер рассказал о преимуществах такого подхода).

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

1. приводится таблица транзакций документов
2. таблицы для продажи/данные о покупке (или, возможно, различные таблицы для этого).

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

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

(Оригинальный дизайн вопрос ответить ниже.

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

Первый заключается в использовании основной конвенции положительных чисел приходя (покупка и продажа), но она ломается для локальных движений (перемещение между складами).

Один из вариантов заключается в том, чтобы иметь отдельную таблицу состояний, которая представляет собой глобальную и местных штатах. Например, покупки, продажи, разные склады и т. д. Затем вы представить передачу как графическую связь между состоянием. Вы также можете иметь таблицу документов, которая может представлять покупки и продажи, с соответствующими классификациями и т. Д. Это позволяет трехстороннюю связь между внутренним, внешними и документами.Например, продажа может иметь состояние в качестве инвентаря (или определенного склада), состояние продажи и документ торгового счета.

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