We have a table called Contracts which has a lot of columns. Some columns are for employees, some columns are for managers, some columns are for locals and so on. Since the table is growing, that's why I wanna refactor it. I have the following options,

  1. Keep one table Contracts for all columns.
  2. Keep a separate table for each contract, EmployeeContract, LocalContract, ManagerContract and so on.
  3. Keep one table Contracts for common columns and separate table for EmployeeContract, LocalContract, ManagerContract and so on.

Is it fine to have a parent-child with one-to-one relations?

Update: I am looking whether it makes sense to have sub-class and super-class like features in tables. Contracts will be super-class(super table) and EmployeeContract, LocalContract, ManagerContract are sub-classes(or sub tables)?

  • Is the new table you describe going to be something like "ContractType", where the listed types are Employee, Local, Manager? In that case, there would be a one to many relationship as there can be more than 1 Employee, Local or Manager. If I've missed what you're asking please elaborate on the question and possibly give examples with data in your current table.
    – SQL_Hacker
    Dec 9, 2019 at 17:31
  • It sounds as though Employees, Locals, and Managers are subclasses of some kind of superclass of people who can have contracts. If this is true, see if you can reword your question so as to take this into account. Dec 10, 2019 at 12:48
  • Sql_Hacker and Walter, I updated the question. Dec 11, 2019 at 7:17
  • @SQL_Hacker nice I have found a very good answer of you at dba.stackexchange.com/questions/120176/… Dec 11, 2019 at 7:31


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Browse other questions tagged or ask your own question.