SQL. Do I need to create a separate table?

Question

SQL

There is a DB - a kindergarten.
Tables: Child , Parent . They have the same properties - this is the full name, everything else is different (parent: passport data, place of work ..., child: group number, medical book ...)
So, is it worth creating a separate table like Person , where to insert the full name and create a one-to-one relationship for the Child and Parent tables ?
Or all the same to duplicate the data in both tables?
Then what if an Employee (employee) also appears with a full name, and there is dubbing?

Answer 1

In general, in real life, the surnames of the parent and the child may be different, it seems to me that person, there is a full name and all that (and it may be worth thinking about what will happen if a person changes his surname, how to organize the story, if necessary) .
Instead of child-parent, you can make some kind of parentof (with parentId, childId fields).
Instead of employee - employmentcontract - where employeeid - foreign key to person

Answer 2

imkho: for surnames, names and patronymics to stir up in general 3 separate tables and to connect them on ID with all.

Answer 3

tihhanovski is talking to you. This is complete crap - Child and Parent tables. What is their meaning? Each table (i.e. relation, mathematically speaking) is a certain fact that may be true for some combination of attributes (and then the entry in the table exists), or not be true (and then there is no entry in the table). What is the essence of the facts "Child" or "Parent"? In both cases, it is a person. Those. only one table is needed to store information about a person, and that is the Person table.
Another thing is that you also want to store information about who is the parent of whom. The ParentId field in the Person table will not be enough, because the registered parent can be one, or maybe two (or even none, if your kindergarten may have orphans). Of course, you can have two fields - the first parent and the second parent, and give the opportunity to put NULL there, but not the fact that this is the best solution. Here, for the purposes of storing the parent-child relationship (I draw your attention to the fact that it is the parent-child RELATIONSHIPS, and not the individual entities "parent" and "child"), you can create a separate table of the form Parent (ChildId, ParentId), where both fields are external keys to the Person table and both fields form a composite primary key. Then you can safely enter both children and parents in one table,
PS Regarding the fact that the data is different in Child and Parent - the point is not that the full name should be taken out, but that it is necessary to separate the general data about the person and leave them in the Person table (by the way, you probably want to store the gender of the person in Person), and place the differing data in other tables, such as Place of Work and Medical Information. The fact that parents have a job, and children have honey. information, this is, roughly speaking, a coincidence. Tomorrow they will tell you that medical information for parents also needs to be stored (for example, if they visit the kindergarten building). One or two joins is more than an adequate query in a normal normalized database.