News for hackers. Stuff that matters.

A comment on Feature Casualties of Large Databases. Parent comment

Re:Feature Casualties of Large Databases by roenxi on Wednesday December 02, 2020 @05:26AM (#25275131)
Yes and no. When you describe '...split it into a list of elements by commas...' style problems you are describing un-normalised data. SQL is explicitly designed to deal with normalised data, so it isn't a fault if it struggles.

NULL is unpleasant to deal with, but it is unavoidable - sometimes the value of data isn't known and the database has to represent that somehow.

But I'm with you on getting out of SQL quickly as the code gets longer. It is a bad language and it is better to be working in something else.

[ Parent | on HN ]
Re:Feature Casualties of Large Databases by zozbot234 on Wednesday December 02, 2020 @07:06AM (#25275616)
PostgreSQL supports arrays as a first-class feature. There's very little issue with "unnormalized" data when the data will never be used as a lookup key within the database.
[ Parent | on HN ]
Re:Feature Casualties of Large Databases by roenxi on Wednesday December 02, 2020 @03:41PM (#25281290)
SQL was designed somewhat before PostgreSQL decided to support arrays. It is a terrible, terrible language for dealing with non-normal data.

If you are doing string parsing in SQL, mistakes were made.

[ Parent | on HN ]