Kann ein Feld auf 2 verschiedene FKs oder eine bessere Option für diesen Fall verweisen?

Question

Ich bin mit dieser Situation fest: Ich habe meine wichtigsten Systemeinstellungen Tabelle, um alle Standard-Systemwerte zu halten. Ein Beispiel ist Standardsprache ist Englisch. Standardfilter ist die Altersbeschränkung für das Filtern von Benutzerinhalten usw. Es gibt ungefähr 40 unterschiedliche Werte, die für den Moment beibehalten werden müssen.

Nun werden alle diese Werte in mehreren Nachschlagetabellen und auch in der Tabelle master field_value gespeichert, die alle kleinen Lookups enthält. Sprachcodes befinden sich in der Sprachen-Lookup-Tabelle. Alter Filter hat seine eigene Nachschlagetabelle und viele andere. Andere kleinere Einstellungen befinden sich alle in der Tabelle field_value.

Also muss ich das setting_value Feld auf alle diese Tabellen verweisen, es sei denn, ich habe 1 colunm pro Einstellung und behalten Sie den Rest als NULL.

Derzeit mein Schema ist dies

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; 

Und es funktioniert nicht, Einstellungen aus mehreren Tabellen über das System zu handhaben.

Answer 1

Sie könnten versuchen, super-Typ/Subtyp. Behalten Sie alle gemeinsamen Spalten in der Tabelle Setting bei.

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

Sie könnten inheretance in Ihrem Datenmodell verwenden. Die Elterntabelle hat einen Primärschlüssel und die Kindertabelle hat ihren Primärschlüssel als Fremdschlüssel für die Elterntabelle. Here ist eine andere SO Frage mit einem ähnlichen Thread.

MSSQL DDL Beispiel:

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])