News for hackers. Stuff that matters.

A comment on SQL is 43 years old – Here’s why we still use it today. Parent comment

Re:SQL is 43 years old – Here’s why we still use it today by path411 on Wednesday May 03, 2017 @12:28AM (#14253041)
In the projects I've worked on that require frequent table modification, I came to the opinion that the correct approach would be to store the data where the columns/values are stored in a table or set of tables based on types and linked together with a relationship to the original table as the parent. The big downside I could see is performance, but maybe I'm falsely assuming that this would still be faster than NoSQL? (I haven't actually used nosql however.) But, for my projects, the performance hit should/would not be a problem.

Since my experience is probably just limited, I'm curious if there is an easy to explain example where this is incorrect? (Or I guess maybe most people disagree with me and see my above opinion as always/most of the time incorrect)

[ Parent | on HN ]
Re:SQL is 43 years old – Here’s why we still use it today by hackits on Thursday May 04, 2017 @01:01AM (#14262565)
I will agree with your approach. With any large system or government database schema adding another table and then adding a relation to the necessary reports is 100x better than changing the parent table.

I've seen too often jobs being quoted for clients for simply adding a column to table blow out to 4-5 month development tasks. Turns out the table was being used by an old C/C++ program with oracle C bindings. That had to be updated, and that in turn caused another application to stop working.

[ Parent | on HN ]
Re:SQL is 43 years old – Here’s why we still use it today by nickpeterson on Wednesday May 03, 2017 @07:30AM (#14254777)
This is correct if I understand you. Basically, when people add something new to a schema, they're generally tacitly also admitting it's optional. Optional fields should not exist on the same table as non-optional fields, because then you have to allow everything to be null or a specially designated value.
[ Parent | on HN ]