I have argued with my friend for DB schema.
Our app reads a kind of csv file, and then inserts data(almost 200 rows) into table. Sometimes the app needs to delete data by filename.
So, i suggest folloing table schema -> [Key], [Text], [FileName]
it is able to insert data with filename, then delete data by filename(delete from [TABLE] where filename ='boolaboola').
But my friend, he insists on "Why not create and delete 'TABLE' whenever data inserted?"
His table schema is -> [Key], [Text]
His idea is [When the app reads a file, the app creates one table whose name is the filename. Then insert data into the new table. When we need to delete data by filename, just drop table.]
Even though our table does not need foreign key.
I couldn't agreed with that idea. In my experience, I felt that DB schema is wrong... but I cannot explain and persuade my friend.
Please help me. Am I wrong? or how can I persuade my friend?
In general, I agree with you. Changing the database schema should IMHO generally be a rare action, preferably only when the software is updated. I know this is very strict and 'un-NoSQL', but this is a traditional relational database after all :).
For a more specific recommendation, it would help to know how you're intending to use this data. Storing it in one table (perhaps partitioned or with an index on 'filename' for performance, if that's an issue) is more flexible: it allows you to easily do analyses that span data from multiple files.
Also if you later want to use some kind of O/R-mapper or other tooling, it often helps to have your table schema rather static.
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With