what is the correct way to design a 'table to row' relationship?

问题

I am trying to model the following in a postgres db.

I have N number of 'datasets'. These datasets are things like survey results, national statistics, aggregated data etc. They each have a name a source insitution a method etc. This is the meta data of a dataset and I have tables created for this and tables for codifying the research methods etc. The 'root' meta-data table is called 'Datasets'. Each row represents one dataset.

I then need to store and access the actual data associated with this dataset. So I need to create a table that contains that data. How do I represent the relationship between this table and its corresponding row in the 'Datasets' table?

an example

'hea' is a set of survey responses. it is unaggregated so each row is one survey response. I create a table called 'HeaData' that contains this data.

'cso' is a set of aggregated employment data. each row is a economic sector. I create a table called 'CsoData' that contains this data

I create a row for each of these in the 'datasets' table with the relevant meta data for each and they have ids of 1 & 2 respectively.

what is the best way to relate 1 to the HeaData table and 2 to the CsoData table?

I will eventually be accessing this data with scala slick so if the database design could just 'plug and play' with slick that would be ideal

回答1:

Add a column to the Datasets table which designates which type of dataset it represents. Then a 1 may mean HEA and 2 may mean CSO. A check constraint would limit the field to one of the two values. If new types of datasets are added later, the only change needed is to change the constraint. If it is defined as a foreign key to a "type of dataset" table, you just need to add the new type of dataset there.

Form a unique index on the PK and the new field.

Add the same field to each of the subtables. But the check constraint limits the value in the HEA table to only that value and the CSO table to only that value. Then form the ID field of Datasets table and the new field as the FK to Datasets table.

This limits the ID value to only one of the subtables and it must be the one defined in the Datasets table. That is, if you define a HEA dataset entry with an ID value of 1000 and the HEA type value, the only subtable that can contain an ID value of 1000 is the HEA table.

create table Datasets(
    ID     int identity/auto_generate,
    DSType char( 3 ) check( DSType in( 'HEA', 'CSO' ),
    [everything else],
    constraint PK_Datasets primary key( ID ),
    constraint UQ_Dateset_Type unique( ID, DSType ) -- needed for references
);

create table HEA(
    ID     int not null,
    DSType char( 3 ) check( DSType = 'HEA' ) -- making this a constant value
    [other HEA data],
    constraint PK_HEA primary key( ID ),
    constraint FK_HEA_Dataset_PK foreign key( ID )
        references Dataset( ID ),
    constraint FK_HEA_Dataset_Type foreign key( ID, DSType )
        references Dataset( ID, DSType )
);

The same idea with the CSO subtable.

I would recommend an HEA and CSO view that would show the complete dataset rows, metadata and type-specific data, joined together. With triggers on those views, they can be the DML points for the application code. Then the apps don't have to keep track of how that data is laid out in the database, making it a lot easier to make improvements should the opportunity present itself.

来源：https://stackoverflow.com/questions/30014676/what-is-the-correct-way-to-design-a-table-to-row-relationship