How to choose attribute and table?

Question

I am considering the database design for a student registration system. Firstly, the system will accept the registration from any person whose data will be stored. Then the admin will check the forms and choose the students to be accepted. Should I use the two separated tables, the first one is to store the information of the registered person and the second one is to store the information of the accepted students? Or should I use only one table and use an attribute(confirmedOrNot) to mark (0 or 1) whether that person has been accepted or not as shown in the following diagram? The accepted person should also pay the fee before the due date. Otherwise, they will be removed from the accepted list. I also used an attribute to mark that. Only the persons who have been accepted and paid the fee are the final student list of the system. Is that design reasonable? What would be a better design?

Answer 1

Whether a student is "accepted" or not sounds like an attribute of a student. The natural thing to do is to put all students in one table and make "accepted" an attribute in this table. If you make two tables, then you presumably will have two tables that have all the same fields in them. When a student is accepted, you have to copy all his data from the "pending" table to the "accepted" table, and then maybe delete the record from the "pending" table. That's way more work than just changing the value in one field. More important, if the data you keep on a student changes, you have to remember to change both tables, and to change the code that copies the data. You're creating more work for yourself. Sooner or later someone will make a mistake and make fields in the two tables different sizes, or forget to copy a new field, etc, and then you get lost data.