您应该在多少列中创建另一个表？

Question

I had a table that nearly reached 20 columns.

I find each one necessary since it's a "project" table, and the project has columns that indicate stuff such as when it was created, when it was updated, its id, who started it, who finished it, some metadata such as keywords, the content of the project itself, a brief description and some other stuff.

I was happy with my table, but then I browsed some questions through stackoverflow and saw stuff like "your table should never have more than 10 columns" and suggestions that if it was the case, you should split your table into smaller ones.

Following StackOverflow's advice, I split my table into two tables, but I'm finding it more complicated to manipulate. Now, when each project is created, I have to create two new records, each one for each table. I have to handle errors on the creation of either record, which means that if the creation of the record on the second table fails, I have to do yet another query to rollback the creation of the first record. Data retrieval and record deletion has also been made more complex, since now I have to do that on two tables.

I'm using the Sails.js framework, and trying to use associations, but I find that it's pretty much the same, I still have to repeat tasks for each table.

Is it really worth it to split your table into smaller ones if it gets that big? Or should I just keep my 20 column table? My project is new, not even online, so I don't know performance. I've never understood associations/joins or databases in general, as in, I've never understood why people do it, so, what are the benefits?

Answer 1

Keep your 20 column table, to be honest 20 columns is not a lot considering 5 columns are taken, as you tell, by who when (created, edited) and the ID.

There are other considerations when designing a database table, the number of columns should not be a priority. You can think about splitting it into multiple tables when you have some performance issues but for now keep your table. Go to 40 columns and still you should not care.

The person that said never more then 10 was either talking about some performance issues that can be addressed, or it was a specific case where it made a difference or has some strange "standards".

But you should really understand database design, as you will see how to design your tables better, but for now make tables with as many fields you want as long as you respect some normalization rules

Answer 2

I think you never want to change qour schema after your database was in use som for some time.

Think about features/functions you propably could wanting to implement in feature, and decide basing on that, if you want to have 40 columns.

I prefer to have everything as compact as possible, so i got a lot of foreign-keys and a lot of small tables for the reason to not write or have saved anything twice.