Merging tables with a 1 to 1 relationship in a database

database-design

Is it a good idea to merge two tables that have a 1..1 relationship together?

I have inherited a database with too many tables linked together in a 1..1 relationship. I'd like to evaluate the benefits of merging these tables where possible to have more tidy model with higher query performance.

For example table t1 has 150 records and table t2 has 150 records, they each contain 5 columns and these two tables have a 1..1 relationship. Would it be a good idea to merge them into one table, say t3 which contains all the columns from t1 and t2?

Also does it make any difference if these tables are reference tables (less than 200 records) or an operational tables?

Any idea is appreciated.

Best Answer

If they are small reference tables then I would be more inclined to merge them than if they are not. If reference tables, then they are likely separated due to over the top normalisation and merging them makes séance from query performance perspective.

If they were large fact tables I would be less inclined to wade in before checking ramifications, as it could be that they were separated onto separate file groups with files on different spindles for parallel operations. If this is the case however, I would still be inclined to merge them, and consider table partitioning.

Either way, be sure to thoroughly check for Database and client application dependencies before Changing the table structure.

Related Solutions

Constraint many to many table between two child tables

Why must the employees working on a project strictly belong to the same division that owns the project? That sounds more like a business rule that you can leave up to your application to enforce rather than something that requires DRI.

But let's say you need to enforce this using DRI. You said you have a many-to-many table associating employees with projects. Assuming you are using SQL Server, you could expand this table as follows:

CREATE TABLE dbo.Employee_Project (
     ProjectID            INT
   , ProjectDivisionID    INT

   , EmployeeID           INT
   , EmployeeDivisionID   INT

   , Hours                INT

   , CONSTRAINT FK_Project FOREIGN KEY (ProjectID, ProjectDivisionID) 
        REFRENCES dbo.Project(ProjectID, DivisionID)

   , CONSTRAINT FK_Employee FOREIGN KEY (EmployeeID, EmployeeDivisionID) 
        REFERENCES dbo.Employee(EmployeeID, DivisionID)

   , CONSTRAINT CK_EmployeeProjectSameDivision CHECK (ProjectDivisionID = EmployeeDivisionID)
);

This is what's going on here:

We have two composite foreign keys here, one for Employee and one for Project, so we can have the DivisionID for both entities in the same table and guaranteed by DRI to be correct.
These composite foreign keys require a UNIQUE index on the referenced tables. So in addition to your primary keys on EmployeeID and ProjectID in those tables, you'll need unique keys on (EmployeeID, DivisionID) and (ProjectID, DivisionID).
The CHECK constraint guarantees that an employee can only be assigned to a project owned by the same division.

If you want to see another example of this design pattern, here's the answer I gave to a design problem that had similar requirements.

One to one relationship or another approach

To remove extra fields the best approach (In my eye of course) would be to insert site_id to clan,team and game tables.

In the site table we have site_id which is primary key(unique) and we have a field in the name of url.

url field should be unique.

one-to-one relationship between your three tables with site table.

This is the way to go.

Best Answer

Related Solutions

Constraint many to many table between two child tables

One to one relationship or another approach

Related Question