Я пытаюсь создать уникальное ограничение для нескольких таблиц. Я нашел ответы на подобные вопросы здесь, но они не совсем отражают дух того, что я пытаюсь сделать.
Например, у меня есть три таблицы: t_Analog, t_Discrete, t_Message.
CREATE TABLE t_Analog(
[AppName] [nvarchar](20) NOT NULL,
[ItemName] [nvarchar](32) NOT NULL,
[Value] [float] NOT NULL,
CONSTRAINT [uc_t_Analog] UNIQUE(AppName, ItemName)
)
CREATE TABLE t_Discrete(
[AppName] [nvarchar](20) NOT NULL,
[ItemName] [nvarchar](32) NOT NULL,
[Value] [bit] NOT NULL,
CONSTRAINT [uc_t_Discrete] UNIQUE(AppName, ItemName)
)
CREATE TABLE t_Message(
[AppName] [nvarchar](20) NOT NULL,
[ItemName] [nvarchar](32) NOT NULL,
[Value] [nvarchar](256) NOT NULL,
CONSTRAINT [uc_t_Message] UNIQUE(AppName, ItemName)
)
Моя цель — сделать AppName и ItemName уникальными для всех трех таблиц. Например, имя элемента Y в приложении X не может существовать как в аналоговых, так и в дискретных таблицах.
Обратите внимание, что этот пример надуман, фактические данные для каждого типа различаются и достаточно велики, чтобы сделать объединение таблиц и добавление столбца типа довольно уродливым.
Если у вас есть какие-либо предложения по подходам к этому, я хотел бы услышать их!
---- НАЧАТЬ РЕДАКТИРОВАНИЕ 26 апреля 2012 г., 13:28 CST ----
Спасибо всем за ваши ответы!
Кажется, может быть причина изменить схему этой базы данных, и это нормально.
Объединение таблиц в одну таблицу на самом деле не является приемлемым вариантом, поскольку существует порядка 30 столбцов для каждого типа, которые не совпадают (изменение этих столбцов, к сожалению, не вариант). Это может привести к тому, что большие участки столбцов не будут использоваться в каждой строке, что кажется плохой идеей.
Добавление 4-й таблицы, как упоминают Джон Сикора и другие, может быть вариантом, но я хотел бы сначала проверить это.
Изменение схемы, чтобы быть:
CREATE TABLE t_AllItems(
[id] [bigint] IDENTITY(1,1) NOT NULL,
[itemType] [int] NOT NULL,
[AppName] [nvarchar](20) NOT NULL,
[ItemName] [nvarchar](32) NOT NULL,
CONSTRAINT [pk_t_AllItems] PRIMARY KEY CLUSTERED ( [id] )
CONSTRAINT [uc_t_AllItems] UNIQUE([id], [AppName], [ItemName])
) ON [PRIMARY]
CREATE TABLE t_Analog(
[itemId] [bigint] NOT NULL,
[Value] [float] NOT NULL,
FOREIGN KEY (itemId) REFERENCES t_AllItems(id)
)
CREATE TABLE t_Discrete(
[itemId] [bigint] NOT NULL,
[Value] [bit] NOT NULL,
FOREIGN KEY (itemId) REFERENCES t_AllItems(id)
)
CREATE TABLE t_Message(
[itemId] [bigint] NOT NULL,
[Value] [nvarchar](256) NOT NULL,
FOREIGN KEY (itemId) REFERENCES t_AllItems(id)
)
У меня только один вопрос по этому подходу. Обеспечивает ли это уникальность для подтаблиц?
Например, не может ли существовать «Элемент» с «id» 9 с таблицами t_Analog, имеющими «itemId» 9 со «значением» 9,3, и в то же время t_Message имеет «itemId» 9 со «Значением» "фу"?
Возможно, я не совсем понимаю этот подход с дополнительными таблицами, но я не против этого.
Пожалуйста, поправьте меня, если я ошибаюсь в этом.