I have 7 tables. Each table represents transmission type where each row in table represents the Trasmission.
These are the tables:
Some of the tables have task_reference_id field and some of them doesn't have.
This means that one task can referenced by many tables.
No I have to change this structure: Each transmission table with task_reference_id field should reference to many tasks references.
This means that I need to add 5 tables with fields: task_id, transmission_id that will hold the tasks references.
But this makes me think, instead of adding 5 new tables maybe I can create parent "Transmission" table that all other tables will "inherit" from (primary key will be foreing key in the parent table).
And such it will take only one table to make references to tasks. This table will have base_transmission_id, task_id field.
What do you think?
What will be better: add 5 tables or change the structure with parent table so I will have to add only 1 table in order to reference the tasks?
I would go for supertype/subtype, here are few examples.
Related
In my tables for SQL, I have many tables each with an ID column I wish to keep incrementing, along with a main name table with an ID which will be the same value as the corresponding IDs in other tables for the relevant information. I wish to be able to make it so that, when I delete a row from the name table with a certain ID, all values across other tables with the same ID get deleted also. The issue appears to be that, if i create foreign key constraints from the name ID on the name table to the other IDs across other tables, it means these tables are no longer allowed to automatically increment.
I am trying to build a table which will hold the 'relationship' of a parent table and a child table. However each column in both tables are no keys or unique and there are duplicate values in each.
Example
Table A - Parent (Fact)
**CartNumber**
Table B - Child
**CartNumber** not unique
CartValue
CartNumber from table A links to CartNumber in B.
I have tried to implement a foreign key with NOCHECK but of course that will not work since the child column is not a primary key or unique. Bear in mind, I am ONLY trying to define that there is a link between the two columns/tables. Is there any way to define a 'loose' relationship between the two columns? Preferably a method where I can reference the sys views or information schema to extract this information
To be honest: This design smells and - if possible - you should think about changing this...
There is no chance to define a FOREIGN KEY CONSTRAINT on non-unique columns the way you describe it.
But: To define a JOIN there is no need for a FK!
My suggestion:
Create a VIEW like this:
CREATE VIEW dbo.MyView
AS
SELECT a.Col1,a.Col2,...
,b.Col1,b.Col2,...
FROM TableA AS a
[INNER/LEFT/RIGHT/FULL OUTER] JOIN TableB AS b ON a.RelField=b.RelField;
With such a VIEW you will get the data joined on this non-unique information.
UPDATE
Taken form your comment:
the end goal is just to provide an external web service with information that says Column A from Table A is used to join onto Column B from Table B
You can create a meta-table like this:
CREATE TABLE dbo.ColumnReference
(
ColumnReferenceID INT IDENTITY
,TABLE_NAME_A VARCHAR(255) NOT NULL
,COLUMN_NAME_A VARCHAR(255) NOT NULL
,TABLE_NAME_B VARCHAR(255) NOT NULL
,COLUMN_NAME_B VARCHAR(255) NOT NULL
);
--inlcude SCHEMA if needed...
In this case you can maintain these relations in your own structure..., you might even add details, rules, what ever...
The web service will call this directly. You might use a VIEW to combine existing relations (defined as FK CONSTRAINT) with your own meta table (simply with UNION ALL).
Currently, we have a 'messages' table with a column called "content_id" that creates a 1:1 relationship with anything a message can attach to, which are multiple other types of table data.
For instance, a message can be attached to another table row with a primary key that is an ID, and another message might be associated with another table's row with primary key of datatype varchar(36), or a uuid. There may be more tables to which a message could be assigned to one of their rows, with any other data type.
Lastly, a message can only be associated to a SINGLE ONE of any of those rows of various primary key data type.
Is there a better solution to this than a single column of varchar(36) in the messages table that can hold ints OR uuids?
If I use a join table for each relationship, I could put a UNIQUE index on the two columns that join them to make the same relationship. Is that architecture more efficient?
The DB is postgres, if that matters...
On a SaS project (Software as a Service), imagine this scenario:
The main table for customers, those who use the application, is tenant and it primary key is the column id.
I have 3 tables to manage data from tenants and one specific table to manage a functionality of vacancies:
Period, Unity and Shift all those with PK id and FK tenant_id.
My table vacancy have 3 Foreign Keys
period_id - References to "Period" table
unity_id - References to "Unity" table
shift_id - References to "Shift" table
Now the problem:
I need to guarantee that all these 3 FK's are reference to rows on Period, Unity and Shift tables that belong to the same Customer on the tenant table.
I was clear in my explanation?
Maybe i can create a Trigger to handle those validations. I really don't know if SGBD already have resources to do with that.
For information: I'm using SQL Server with Eloquent ORM. But, if really exists a solution for this, the best would be one that who works everywhere.
1) Ensure that your tenant_id is defined as NOT NULL on the tables Period, Unity and Shift.
2) Create the following unique keys on that tables:
Period(tenant_id, period_id)
Unity(tenant_id, unity_id)
Shift(tenant_id, shift_id)
3) Define column tenant_id for table vacancy as NOT NULL.
4) Define the folowing FKs on table vacancy:
(tenant_id, period_id) referencing Period(tenant_id, period_id)
(tenant_id, unity_id) referencing Unity(tenant_id, unity_id)
(tenant_id, shift_id) referencing Shift(tenant_id, shift_id)
This way you can guarantee that every linked row has the same tenant_id.
In SQL Server 2008, how does one design a 1:1 and 1:m relationship?
Any relationship requires that the "parent" table (the one side) have a Primary (or unique) Key (PK), that uniquely identifies each row, and the "child" table (the other side) have a Foreign Key column or columns, that must be populated with values that are the same as some existing value[s] of the Primary Key in the parent table. If you want a one to many (1-M) relationship then the Foreign Key should be an ordinary attribute (column or columns) in the child table that can repeat (there can be many rows with the same value)
If you want a one to one (1-1) relationship then the Foreign key should itself be a Primary Key or unique index in the child table that guarantees that there may be at most one row in the child table with that value.
A 1-1 relationship effectively partitions the attributes (columns) in a table into two tables. This is called vertical segmentation. This is often done for sub-classing the table entities, or, for another reason, if the usage patterns on the columns in the table indicate that a few of the columns need to be accessed significantly more often than the rest of the columns. (Say one or two columns will be accessed 1000s of times per second and the other 40 columns will be accessed only once a month). Partitioning the table in this way in effect will optimize the storage pattern for those two different queries.
Sub-Classing. The above actually creates a 1 to zero or one relationship, which is used for what is called a sub-class or subtype relationship. This occurs when you have two different entities that share a great number of attributes, but one of the entities has additional attributes that the other does not need. A good example might be Employees, and SalariedEmployees. The Employee table would have all the attributes that all employees share, and the SalariedEmployee table would exist in a (1-0/1) relationship with Employees, with the additional attributes (Salary, AnnualVacation, etc.) that only Salaried employees need.
If you really want a 1-1 relationship, then you have to add another mechanism to guarantee that the child table will always have one record for each record/row in the parent table. Generally the only way to do this is by enforcing this in the code used to insert data (either in a trigger, stored procedure or code outside the database). This is because if you added referential integrity constraints on two tables that require that rows always be in both, it would not be possible to add a row to either one without violating one of the constraints, and you can't add a row to both tables at the same time.
One-to-One Relationship
Create Table ParentTable
(
PrimaryKeyCol ... not null Primary Key
, ...
)
Create Table ChildTable
(
, ForeignKeyCol ... [not] null [Primary Key, Unique]
, ...
, Constraint FK_ChildTable_ParentTable
Foreign Key ( ForeignKeyCol )
References ParentTable( PrimaryKeyCol )
)
In this case, I can never have more than one row in the ChildTable for a given ParentTable primary key value. Note that even in a One-to-One relationship, one of the tables is the "parent" table. What differentiates a One-to-One relationship from a One-to-Many relationship purely in terms of implementation is whether the ChildTable's foreign key value has a Unique or Primary Key constraint.
One-to-Many Relationship
Create Table ParentTable
(
PrimaryKeyCol ... not null Primary Key
, ...
)
Create Table ChildTable
(
, ForeignKeyCol ... [not] null
, ...
, Constraint FK_ChildTable_ParentTable
Foreign Key ( PrimaryKeyCol )
References ParentTable( PrimaryKeyCol )
)
In this scenario, I can have multiple rows in the ChildTable for a given ParentTable primary key value.
A 1:1 relationship exists where table A and table B only exist once in regards to each other.
Example: A student has 1 master student record. The student would be table A and the record in table B. Table B would contain a foreign key to the student record in table A (and possibly vice-versa)
A 1:m relationship exists where table A can be referenced or linked to by many entries in table B.
Example: A student can take several books out from the library. The student again would be table A and the book could be the entry in table B. The entry in table B would contain a foreign key to who checked the book out, and many books could reference the same student.