When should you allocate data to a separate table?

Question

Database design

Hello everyone, colleagues)

Let's say there is a certain product table, it describes the name, product activity flag, slag, and other things. Now these other things include a lot of things that in my opinion should not be there. Let me explain - the product in this case is a partner project, I don’t know why it was called that in this system, but it is. So, in this product / project there is data - callback_url, secret_key, flags of which api version to use to work with this partner project. In my opinion, all these settings should be in a separate table product_settings, well, if already in the code everywhere product, and not project. Since in fact these are settings, and not direct information about the product. Am I right? Or it is possible to cut everything in one table?

Second question. Now, according to the task, I am making it possible to generate reports on these same products for partners. And each product should be able to set a flag whether it needs to be added to the report. Should this flag, again, be added to the product table or moved to, say, the new product_report_settings table? Why doubt? In the first described example, there are a lot of settings and, in my opinion, it is obvious that it is better to store them in a separate table. And here it’s just a flag, whether to add it to the report or not. That's where this line, when it is better to put the settings in a separate table? It seems to me that even if this is one field, it is better to put it in a separate meaningful table. Why?

1. The name and description of the table will indicate what kind of data it is within the framework of this product, what it is needed for, and for what functionality.
2. There will be no porridge in the main table.
3. Although it is not planned to increase the number of settings now, but the project is long-term and anything can change there, so additional settings may appear later.

Of the minuses - extra links by keys.

What do you think about this topic?

Answer 1

Well I see sense to take out a specific field (flag) in the separate table. Because this private branch will not give anything good:

1. the colleague's surprise factor: why was there a need to separate a particular flag?
   
2. an additional table that needs a JOIN.
   
3. additional code
   
4. additional migrations and support
   

In my opinion, all these settings should be in a separate product_settings table, well, if already in the code everywhere product, and not project. Since in fact these are settings, and not direct information about the product.

If we separate metadata and settings, then all at once, and not for the sake of one flag. Then there is a point in refactoring and bringing order.

Answer 2

Personally, I think that this needs to be voiced to your partner. And let him think. The base is his.