Много таблиц в одной строке в реляционной базе данных

Question

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

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

1. Добавить столбцы для каждого типа, т.е.добавьте Service_id и Product_id в Invoice_Row, оба столбца которых имеют значение NULL.Если они оба равны NULL, это специальное обвинение, не относящееся ни к чему, но если один из них удовлетворен, то это строка, относящаяся к этому типу.

2. Добавить странныйСистема на основе строки / идентификатора, например: Type_table, Type_id.Это будет строка / varchar и целое число соответственно, первая будет содержать, например, «Сервис», а вторая - идентификатор в таблице «Сервис».Это явно слабая связь и ужасно, но это способ ее решения, если вы обращаетесь к БД только из кода, как такового.

3. Абстрагируйте понятие «что-то»это связано с новыми таблицами, для которых Product и Service теперь являются абстракцией, а в таблице Invoice_Row вы бы ссылались на что-то вроде ChargeableEntity_id.Тем не менее, таблица ChargeableEntity здесь, по существу, будет избыточной, поскольку для нее также потребуется какой-то способ связи с абстрактной таблицей «бэкэнда», что возвращает нас к одной и той же проблеме.1018 * Какой путь вы бы выбрали, или какие есть другие варианты решения этой проблемы?

Answer 1

По сути, вы спрашиваете, как добиться полиморфизма в реляционной базе данных. Существует много подходов (как вы сами демонстрируете) к этой проблеме. Одним из решений является использование наследования «таблица на класс». В этой настройке будет родительская таблица (сродни вашей «платной статье»), которая содержит уникальный идентификатор и поля, общие для продуктов и услуг. Будет две дочерние таблицы, продукты и товары: каждая будет содержать уникальный идентификатор для этой сущности и специфичные для нее поля.

Одним из преимуществ этого подхода по сравнению с другими является то, что вы не получите одну таблицу с множеством обнуляемых столбцов, которая по сути становится дампом для описания чего-либо («без схемы»).

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

Answer 2

Я полагаю, что это зависит от вариантов использования.

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

2. Иначе, если вы ведете две отдельные таблицы, одну для Продукта и другую для Продажи.Вы используете логику приложения, чтобы определить, в какую таблицу вставить.И получение всех продаж по существу будет означать объединение получения всех продуктов и получения всей продажи.

Я бы лично выбрал подход 2, чтобы избежать объединений и вставки в две таблицы при каждой продаже.