There is a table in which all operations related to expenses are recorded. If there is an expense related to the type of "Advance", then it is also necessary to save an advance payment, which is stored in another table with relevant information. For all other types of expenses, the advance_id field will contain a NULL value. Is this good practice or is it better to put this information in a separate table? If so, why?

  • One attribute - one field. The type of expense "Advance" is never an entity, so what is a separate table? - Akina
  • And if there were two or more attributes that relate exclusively to the type of "Advance"? - Undefined
  • So what? there would be two or more fields. Yes, there are cases when it is possible (and sometimes even advisable) vertical separation into two or more tables with a 1: 1 relationship (are you hinting at this?), But this is clearly not the case. - Akina
  • Yes, 1: 1 relationship. As if there will be a lot of such types as "Advance", the table will become huge with fields for each type. It turns out that for such cases it is better not to use relational databases at all? - Undefined
  • one
    when it makes sense to divide the table into several with a 1: 1 relationship? There are two main cases. The first is that there are several user groups, some of them should have access to all the data in the table, the rest only to a few fields. These several fields are placed in a separate table, and different access rights are distributed to these two tables - the second group does not have access to a table with fields that should not be available to this group. The second case - the vast majority of requests go only to a part of the fields - in this case the separation speeds up the work due to the fact that the table is more compact. - Akina

0