Мне нужно хранить данные, относящиеся к «элементам», где будут различные типы элементов, все с общими атрибутами, а затем каждый тип со своими дополнительными атрибутами. Я ожидаю, что это общее требование; какое решение для лучших практик? Мы используем SQL Server.
... и т.д.. для нескольких типов вещей. В наших реальных данных каждый специализированный тип обычно добавляет 2-5 столбцов; будет 5 типов для начала. Мы будем добавлять типы с течением времени, но, вероятно, всего на 3 или 4 больше (если это так). Добавление типов требует разработки, поэтому это не похоже на «теги», которые могут быть добавлены конечными пользователями. Мы предполагаем, что добавление типа потребует изменений в уровне БД и клиента, а также, возможно, и среднего уровня. Это совершенно нормально.
Мы сделаем множество запросов по всем пунктам (транспортные средства, в приведенном выше примере); мы редко беспокоимся о деталях определенного типа предмета (автомобиль, лодка).
Отдельные таблицы для автомобилей, лодок и т. Д. С дублированными столбцами. Например, примерно:
CREATE TABLE [Cars] (
[Id] IDENTITY PRIMARY KEY,
[Price] DECIMAL (19, 4),
[Make] NVARCHAR(200),
[Model] NVARCHAR(200),
[Owner] INT,
[Id] INT PRIMARY KEY,
[Style] NVARCHAR(200),
[Color] NVARCHAR(200),
[EngineSize] DECIMAL(19, 2)
)
CREATE TABLE [Boats] (
[Id] IDENTITY PRIMARY KEY,
[Price] DECIMAL (19, 4),
[Make] NVARCHAR(200),
[Model] NVARCHAR(200),
[Owner] INT,
[Id] INT PRIMARY KEY,
[Displacement] DECIMAL(19, 4),
[PortOfOrigin] NVARCHAR(200)
)
Достаточно просто, машины идут в Cars, а лодки идут в Boats. Если мы добавим больше типов транспортных средств, мы добавим таблицу. Если мы добавим еще один общий столбец, мы должны вернуться и добавить его во все таблицы транспортных средств. Отчетность по транспортным средствам в целом может быть получена в объединенном представлении всех таблиц (будьте осторожны с колонкой Id).
Одна таблица с данными Vehicle, таблица для дополнительных данных Car и таблица для дополнительных данных Boat. Например, примерно:
CREATE TABLE [Vehicles] (
[Id] IDENTITY PRIMARY KEY,
[Price] DECIMAL (19, 4),
[Make] NVARCHAR(200),
[Model] NVARCHAR(200),
[Owner] INT,
[Type] INT -- A type ID, e.g. "Car" vs. "Boat"
)
CREATE TABLE [Cars] (
[Id] INT PRIMARY KEY,
[Style] NVARCHAR(200),
[Color] NVARCHAR(200),
[EngineSize] DECIMAL(19, 2)
)
CREATE TABLE [Boats] (
[Id] INT PRIMARY KEY,
[Displacement] DECIMAL(19, 4),
[PortOfOrigin] NVARCHAR(200)
)
Таким образом, у каждого автомобиля будет одна строка в Vehicles и одна связанная строка в Cars. Каждая лодка будет иметь один ряд в Vehicles и один связанный ряд в Boats. Если мы добавим больше типов транспортных средств, мы добавим таблицу. Отчетность по транспортным средствам в целом может быть сделана только по таблице Vehicle. При получении сведений о конкретном Car или Boat мы используем соединение.
Одна таблица элементов, отдельная таблица атрибутов элементов со строкой для каждого дополнительного атрибута. Например, мягкая схема для деталей. Например, примерно:
CREATE TABLE [Vehicles] (
[Id] IDENTITY PRIMARY KEY,
[Price] DECIMAL (19, 4),
[Make] NVARCHAR(200),
[Model] NVARCHAR(200),
[Owner] INT,
[Type] INT
)
CREATE TABLE [VehicleDetails] (
[VehicleId] INT,
[Name] NVARCHAR(200),
[Value] NVARCHAR(MAX)
)
Таким образом, каждый автомобиль получает одну строку в Vehicles и три строки в VehicleDetails (по одному для "Style", "Color" и "EngineSize"). Отчетность в основном делается на основе таблицы Vehicle. Отчетность по деталям быстро становится грязной. Мягкие схемы имеют свое место, в основном вокруг пользовательских данных, но я предполагаю, что это не будет хорошим выбором здесь.
Одна таблица с общими столбцами, имеющими значение только для кода без БД:
CREATE TABLE [Vehicles] (
[Id] IDENTITY PRIMARY KEY,
[Price] DECIMAL (19, 4),
[Make] NVARCHAR(200),
[Model] NVARCHAR(200),
[Owner] INT,
[Type] INT,
[Detail01] NVARCHAR(MAX),
[Detail02] NVARCHAR(MAX),
[Detail03] NVARCHAR(MAX),
[Detail04] NVARCHAR(MAX),
[Detail05] NVARCHAR(MAX),
[Detail06] NVARCHAR(MAX),
[Detail07] NVARCHAR(MAX),
[Detail08] NVARCHAR(MAX),
[Detail09] NVARCHAR(MAX),
[Detail10] NVARCHAR(MAX)
)
Таким образом, данные Car назначат Style для Detail01, Color для Detail02 и EngineSize для Detail03; для лодок мы поместили бы Displacement в Detail01 и PortOfOrigin в Detail02. Точно так же может быть место для этого с определенными пользователем схемами, но я предполагаю, что это не будет хорошим ответом, когда вы можете управлять структурой БД.