У меня есть 2 таблицы, которые могут предоставить соответствующую запись, представляющую некоторый элемент, приблизительно смоделированный следующей диаграммой классов. Это очень упрощено, каждый из источников является отдельной составной моделью.
Думая об этом с точки зрения базы данных, а не ООП, таблица элементов содержит записи о любом возможном элементе. Если вы хотите знать, что такое определение виджета или определение gawgaw, это цель таблицы элементов. Таблицы Source * представляют типы местоположений физических элементов, причем каждая запись представляет определенное местоположение. Исходные * таблицы также содержат большое количество непересекающейся информации.
Коллекции определенных экземпляров виджетов или gewgaws содержатся в источниках, то есть Source1 имеет 10 различных виджетов и 3 различных gewgaws, в то время как Source2 может содержать только 1 отдельный виджет на данный момент.
Чтобы представить отношение, если бы существовала только 1 исходная таблица, я бы обычно использовал сводную таблицу с идентификатором источника и идентификатором элемента в качестве внешних ключей.
Моей первой мыслью о том, как представить магазин второго типа, было создание другой сводной таблицы, то есть item_source2, а затем, когда мне нужно подсчитать инвентарные номера инвентаризации, выполнить объединение между item_source1 и item_source2.
Это не выглядит особенно элегантно, нарушает СУХОЙ и вводит союз, где, возможно, он не нужен.
Следующая мысль - обобщить таблицу item_source1, чтобы также иметь поле для ключа Source2.id. На практике для любой данной записи только один из Source1.id или Source2.id будет допустимой ссылкой, в то время как другой должен быть нулевым - определенный виджет не может существовать в 2 местах одновременно.
С программной точки зрения я могу создать логику для тестирования и реализации этой схемы, но для меня ясно, что это не лучшая практика, но я не могу понять, как решить эту проблему с помощью проектирования базы данных.
Я буду реализовывать это в схеме Laravel, но, возможно, понимание аспекта проектирования здесь гораздо важнее.