Может ли поле указывать на 2 разных FK или какой-нибудь лучший вариант для этого случая?

Question

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

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

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

В настоящее время мойэто схема

CREATE TABLE `settings` (
  `setting_id` int(6) NOT NULL,
  `description` varchar(32) NOT NULL,
  `code` int(6) DEFAULT NULL,
  `created` datetime NOT NULL,
  `updated` timestamp DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
  PRIMARY KEY (`setting_id`),
  KEY `code` (`code`),
  CONSTRAINT `settings_ibfk_1` FOREIGN KEY (`code`) REFERENCES `field_values` (`fv_id`) ON UPDATE CASCADE
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

И она не работает для обработки настроек из нескольких таблиц в системе.

Answer 1

Вы можете попробовать супертип / подтип.Сохраните все общие столбцы в таблице Setting.

create table Setting (
      SettingID   integer     not null
    , SettingType char(1)     not null
    , SettingName varchar(32) not null
    , Description varchar(32) not null
    , Created     timestamp default CURRENT_TIMESTAMP
    -- other common-to-all-setups columns here
);
alter table Setting add constraint pk_setting primary key (SettingID);


create table LanguageSetting (
      SettingID   integer     not null
    , Updated     timestamp default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP
    -- other columns specific to this setup-type here
);
alter table LanguageSetting 
  add constraint pk_langset  primary key (SettingID)
, add constraint fk1_langset foreign key (SettingID) references Setting(SettingID);


create table AgeFilterSetting (
      SettingID   integer     not null
    , Updated     timestamp default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP
    -- other columns specific to this setup-type here
);
alter table  AgeFilterSetting 
  add constraint pk_ageflt  primary key (SettingID)
, add constraint fk1_ageflt foreign key (SettingID) references Setting(SettingID);


create table OtherSetting (
      SettingID   integer     not null
    , Updated     timestamp default CURRENT_TIMESTAMP on update CURRENT_TIMESTAMP
    -- other columns specific to this setup-type here
);
alter table  OtherSetting 
  add constraint pk_othset  primary key (SettingID)
, add constraint fk1_othset foreign key (SettingID) references Setting(SettingID);

.

Answer 2

Вы можете использовать inheretance в вашей модели данных. Родительская таблица имеет первичный ключ, а дочерняя таблица имеет первичный ключ как внешний ключ к родительской таблице. Здесь - еще один вопрос SO с похожей темой.

MSSQL DDL Пример:

CREATE TABLE [Child1](
    [ParentId]  int    NOT NULL,
    CONSTRAINT [PK2] PRIMARY KEY CLUSTERED ([ParentId])
)

CREATE TABLE [Child2](
    [ParentId]  int    NOT NULL,
    CONSTRAINT [PK3] PRIMARY KEY CLUSTERED ([ParentId])
)

CREATE TABLE [Parent](
    [ParentId]  int    NOT NULL,
    CONSTRAINT [PK1] PRIMARY KEY CLUSTERED ([ParentId])
)


ALTER TABLE [Child1] ADD CONSTRAINT [RefParent1] 
    FOREIGN KEY ([ParentId])
    REFERENCES [Parent]([ParentId])

ALTER TABLE [Child2] ADD CONSTRAINT [RefParent3] 
    FOREIGN KEY ([ParentId])
    REFERENCES [Parent]([ParentId])