SoylentNews is people
SoylentNews
SQL and relational database management systems or RDBMS were invented simultaneously by Edgar F. Codd in the early 1970s. The simple fact that both arrived early in the life of computing, and that for 90% of the time they just work, means databases have become a 'solved problem' you no longer need to think about.
It's like how MailChimp has become synonymous with sending email newsletters. If you want to work with data you use RDBMS and SQL. In fact, there usually needs to be a good reason not to use them. Just like there needs to be a good reason not to use MailChimp for sending emails, or Stripe for taking card payments.
But people do use other other email automation software and payment solutions, just like people use NoSQL databases. Yet even with other database technology available, albeit less mature technology, SQL still reigns and reigns well.
So, finally, here are 8 reasons we still use SQL 43 years after it was first cooked up.
It's clickbait, I tell ya!
(Score: -1, Offtopic) by Anonymous Coward on Thursday May 04 2017, @12:29PM
N/T
(Score: 0) by Anonymous Coward on Thursday May 04 2017, @12:32PM
because very few people realized that persistence, neworked object, search/indexing, and an inference engine should be a very well integrated language extension for all high level languages. Picolisp gets it right, if you want something more newb friendly maybe Pharo.
(Score: 5, Informative) by TheRaven on Thursday May 04 2017, @12:45PM (5 children)
sudo mod me up
(Score: 3, Insightful) by Anonymous Coward on Thursday May 04 2017, @12:57PM (1 child)
I've never heard of MailChimp
Check your spam folder.
(Score: 3, Insightful) by hemocyanin on Thursday May 04 2017, @02:20PM
That summary reads like it is the victim of product placement.
(Score: 3, Informative) by Anonymous Coward on Thursday May 04 2017, @02:20PM (2 children)
Apparently MailChimp is something like GNU Mailman [wikipedia.org] but for the hip millenials who prefer paying for stuff and don't care about control or privacy.
(Score: 2) by goodie on Thursday May 04 2017, @02:40PM
Yup, and it plugs right in many cloud CRMs like Salesforce so it's likely to stick around for a while unfortunately...
(Score: 4, Funny) by LoRdTAW on Thursday May 04 2017, @05:14PM
I thought it was because it throws feces everywhere.
(Score: 3, Interesting) by theluggage on Thursday May 04 2017, @01:01PM (18 children)
(1) Why RDBMS and (2) Why SQL
(1) is easy - its a good model of data organisation with a strong theoretical underpinning and can easily be used to implement flat files, document stores, graph databases etc. especially with a dash of "sugar" from the RDBMS (e.g. PostgreSQL's support for JSON). Obviously there's a role for specialised databases for extreme applications (e.g. graph - I'm not sure what Mongo etc. are meant to be for) but most real-world applications will benefit from the relational capabilities (e.g. you've done your document store = table with ID and a JSON field - now it needs an ownership and permissions system, which is a natural application for relational).
(2) is harder to see - SQL itself is a semantic train wreck and - even if you're a pragmatic type (or even a pragmatic tuple) and its non-mathematically-sound terminology doesn't give you hives, it's just plain inconsistent, verbose, poorly standardised and is a prime example of COBOL-esque "Unlight Lamp" syndrome. Why hasn't something more concise, logical and which makes it easier to compose queries programatticaly emerged?
(Score: 3, Insightful) by pTamok on Thursday May 04 2017, @01:29PM
I think the reason SQL continues to be used is inertia. Once the installed base is large enough, replacing the 'ecosystem' is hard.
In other words, the expected pain of transition is not outweighed by the expected gain of using something new (and hopefully better). There doesn't appear to be anything 'obviously' better.
There's also plenty of COBOL running on inertia too. Also, don't underestimate the amount of hard-coded business analysis that has gone into legacy applications. If you just re-code the codebase in a new language, you find you have swapped one fragile set of inter-related processes implemented on a computer for an equivalent set of of fragile inter-related processes on a computer, with no actual gain in business agility. Doing the job properly, by doing a proper analysis of the current business and its goals, then writing the support software in the light of that analysis, then managing the transition from old to new, is costly and takes time. You need some pretty amazing benefits to justify it.
(Score: 2) by goodie on Thursday May 04 2017, @02:44PM
Why hasn't something more concise, logical and which makes it easier to compose queries programatticaly emerged?
My personal opinion is that it's because it's really hard to actually do that well. As in 90% will be relatively easy and the last 10 will be a big mess (see my other post on the Vietnam reference). The big PITA is also vendor-specific implementations of SQL, support or lack thereof for certain features etc. That makes it difficult to work with multiple RDBMS without some sort of translation tool that will not have everything implemented for every platforms etc. And data type conversion between the RDBMS and the application can also be tough sometimes...
(Score: 2) by Grishnakh on Thursday May 04 2017, @04:21PM (5 children)
and is a prime example of COBOL-esque "Unlight Lamp" syndrome
How is this a bad thing? "Unlight lamp" reminds me of the text adventures of the early 80s, back when computers actually used to be fun. Now with Windows 10, spyware, ridiculously slow software despite incredibly powerful hardware, and worst of all, flat UIs, computers just aren't much fun any more.
I remember the days when computers run at under 1 MHz (sometimes well under), yet they could accept keypresses as fast as you could type them. These days, there's a huge, visible lag in typing most of the time, despite CPUs being over 1 or 2 GHz and having tons of extra helper hardware (GPUs, DMA, etc.). Software has gotten so ridiculously bloated that all the performance gains are squandered. Just look at the popular new way of developing desktop apps these days: Electron. "Yeah, let's spin up a whole new web browser for every simple little app!"
(Score: 3, Insightful) by theluggage on Thursday May 04 2017, @05:22PM (4 children)
How is this a bad thing? "Unlight lamp" reminds me of the text adventures of the early 80s, back when computers actually used to be fun.
Sure - its all fun and games until someone gets eaten by a grue. Or you query flies out of the server, collides with the pile of junk mail (haha!) only to be grabbed by a small lower-half-of-the-room cleaning robot*. No, I don't want to have that sort of "fun" when I'm trying to write a query - the underlying logic provides an adequate sufficiency of mental exercise.
"Natural language" computer languages like SQL, COBOL, VAX/VMS command line invariably fail because they don't really understand natural language and you end up having to memorise the correct commands anyway. Worse, they accept a small number of variations (e.g. glue words like WITH, TO that don't follow any sort of consistent logic about when they're needed) which I find makes it harder to remember.
I remember the days when computers run at under 1 MHz (sometimes well under)
Bet you could remember the hex codes for all the commonly used machine code instructions, too... So much for natural language.
These days, there's a huge, visible lag in typing most of the time,
Pro tip: Office 2016 actually does that deliberately... I threw up in my mouth a little bit. There's a registry hack to turn it off.
Electron. "Yeah, let's spin up a whole new web browser for every simple little app!"
To be fair, that's mainly Because Security: they could all run in a single browser instance if you didn't mind giving Javascript full access to your system...
*Sorry, I know I haven't got that quite right but I've got a headache and forgot to TAKE ASPRIN. (or was that TAKE ASPRIN USING GLASS... or TAKE ASPRIN USING WATER...?)
(Score: 2) by Grishnakh on Thursday May 04 2017, @05:53PM (2 children)
Bet you could remember the hex codes for all the commonly used machine code instructions, too... So much for natural language.
No, actually I'm just thinking of the 8-bit microcomputers of the time, plus also the IBM PC, various mainframes, etc. All those things were fast. Maybe not so much at actual computation speed, but they had very low latency for user-interactive stuff usually.
Pro tip: Office 2016 actually does that deliberately... I threw up in my mouth a little bit. There's a registry hack to turn it off.
WTF? Why would they do this?
(Score: 2, Informative) by Anonymous Coward on Thursday May 04 2017, @06:19PM (1 child)
Because they thought it looked good. However, you can turn it off:
http://www.laptopmag.com/articles/office-2013-typing-animation-disable [laptopmag.com]
(Score: 0) by Anonymous Coward on Friday May 05 2017, @07:39AM
Strange. My Office 2016 doesn't seem to do that, and I don't have that key. I do however have DisableHardwareAcceleration = 1, so that may be the reason.
(Score: 2) by kaszz on Thursday May 04 2017, @11:32PM
To be fair, that's mainly Because Security: they could all run in a single browser instance if you didn't mind giving Javascript full access to your system...
What is needed is a sandboxed process space. Not necessarily a full browser and all of it is still highly inefficiently designed and programmed.
On top of that. Javascript is a design error all the way.
(Score: 2) by Thexalon on Thursday May 04 2017, @04:31PM
My guess is that the problem is that the semantics can get really hard.
Here's an example of the kinds of things you need to be able to ask an RDBMS: "Given a detailed listing of each individual purchase, which includes 4 kinds of information (loyalty card number, credit card number, delivery address, and name) that may connect multiple purchases by the same customer together, how many customers in the last 6 months have purchased at least 5 pairs of shoes and 10 pairs of socks, and how much did they pay for them?"
A reasonably skilled SQL jockey should be able to put something together that would express this question correctly, and it wouldn't be all that long either compared to the description of the question I just asked in English.
It's also not like there haven't been attempts to replace SQL over the last 4 decades. Many ORMs effectively try to do exactly that by adding a code layer that translates into SQL. So far, the results have been not good enough to dislodge SQL. Which is a pretty strong indication that SQL is pretty darn good at what it does.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2, Informative) by Anonymous Coward on Thursday May 04 2017, @09:45PM
Alternative? The folks at C2 drafted up a query language tentatively called "SMEQL" that is more functional in nature, where any new operations are new functions (or API-like calls) instead of the COBOL-esque key-words used by SQL.
SMEQL Overview [c2.com]
Base operators [c2.com]
Example query [rosettacode.org]
Column selection can be "meta-tized" in that you can use the regular table operations to "compute" which columns to show (SELECT equivalent). This can allow one to use a data-dictionary (column description table(s)) to select columns.
Spread the word.
Another possible contender is Tutorial-D and its close cousin "REL", but it also suffers some syntactic complexity problems. The REL implementers are allegedly more concerned with "relational purity" than syntax simplification. The purity issue is not a show-stopper with SMEQL, and "solving" it would only have a minor impact on the draft SMEQL standard. (The "purity wars" get nasty.)
(Score: 3, Funny) by requerdanos on Thursday May 04 2017, @10:12PM
SQL itself is a semantic train wreck... Why hasn't something more concise, logical and which makes it easier to compose queries programatticaly emerged?
Well, Soylentnews has a story on their front page giving eight reasons why. Here's a link to the story itself [sqlizer.io] and to the SN coverage [soylentnews.org]. If you're in a hurry just expand the spoiler for a quick list of all eight reasons.
(Score: 2) by meustrus on Friday May 05 2017, @02:47AM (6 children)
SQL has its problems, to be sure. But in its defense, it is one of the only languages we use that describes what the result looks like instead of . The beauty in SQL is that most of the time the database engine can figure out the most efficient algorithm to fetch your data just based on your spec. You just can't do that with procedural or object-oriented code.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 2) by Wootery on Friday May 05 2017, @04:05PM (4 children)
Well, obviously. That's not a defence of SQL, it's a defence of relational database languages. The question is whether SQL is good at what it does.
SQL has lots of silly things like using a different syntax for UPDATE vs INSERT, for instance. If we could burn it down and start over, we could fix those.
(Score: 0) by Anonymous Coward on Sunday May 07 2017, @07:38AM (1 child)
While I agree there's a lot of annoyances with the syntax, that particular thing can be fixed in a new standard version by allowing both "styles" with either command. Thus, that specific problem is not a reason to start over.
(Score: 2) by Wootery on Tuesday May 09 2017, @03:57PM
In reality what's happened is that MySQL invented a non-standard INSERT syntax with the UPDATE-like named-parameters style, and it won't work outside MySQL. [bennadel.com]
I agree MySQL isn't so terrible that we should start again, but it sure ain't perfect.
(Score: 2) by meustrus on Tuesday May 09 2017, @01:43PM (1 child)
Other such languages being...? I'd love to see another language that specifies the result instead of the algorithm. Your UPDATE vs INSERT example is just one of the many problems I alluded to, but without an alternative I think it's just something we put up with.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 2) by Wootery on Tuesday May 09 2017, @03:53PM
Yes, exactly my point. It's not a particularly great language, it's an acceptable language of a very useful kind.
(Score: 2) by meustrus on Tuesday May 09 2017, @01:40PM
Huh, I really should have previewed that first. A broken tag got rid of the end of sentence two ("how to get the result") and borked the rest of the comment.
If there isn't at least one reference or primary source, it's not +1 Informative. Maybe the underused +1 Interesting?
(Score: 4, Interesting) by Nerdfest on Thursday May 04 2017, @01:04PM (16 children)
... yet after 40 years, the *vast* majority of people seem to be utterly incapable of wring anything approaching readable SQL. They use all caps, alias tables to single characters, use horrible names, and a variety of other sins that somehow have become the 'convention' from the mainframe crowd. Luckily, writing SQL these days is relegated to ORM and reporting tools, which in general actually do a better job than people. Not that I'm bitter.
(Score: 4, Interesting) by goodie on Thursday May 04 2017, @01:36PM (3 children)
Haha I know, people still have a hard time (mind you they might have a hard time writing code to begin with), and I should know because I teach it to graduate students who like to write spaghetti. I see two main issues from my SQL teaching experience:
1- Many students/people who write SQL are not trained to *think* about a problem, design an algorithm, and implement/debug it. They go head first into code and it quickly becomes this mess (I always think of Tetsuo at the end of the Akira movie...) that they cannot debug. So a big part of my job is to teach them that. Think about the business issue, what you could do to solve it, and then think about code, not the other way around. Same goes for data modelling (when to/not to normalize, dimensional vs relational models etc.). Most people don't think in terms of structures, they think in terms of result. Since many engines don't provide built-in standard/pattern checking and refactoring capabilities, people get away with crap which is then bound to object models and so on (which are much nicer looking when you look at the code...).
2- For many people, thinking in sets is not very natural because they are used to thinking in a more procedural manner. So when they want to do something in SQL, they may go for cursors, while loops etc. rather than say a recursive query that can do this much more elegantly and more important, more efficiently for the engine. Typical example I use for students is a calendar table, something that is easy and can be implemented in a number of ways but for which a recursive query can be much better.
The funny thing is that with all those new things, hadoop, spark etc. the first thing that people do is slap an SQL-like interface to interact with the data (Hive, etc.). I have nothing against this but I find it amusing that every time somebody tells me that SQL is dead or some stupid comment like this, I can refer to those new things and tell them to shut up. It's still relevant. It does not mean that it's properly used but it is still relevant (for what it's worth, Stackoverflow's developer survey has included SQL as one of the top languages for a number of years).
Personally, I really like SQL. My experience with ORMs has been relatively mixed. I find that it has shifted some of the burden on the programming side but it hides some of the inefficiencies that the engine makes and can force a certain data model on the software side to obtain query patterns over others. It's aptly been referred to as the Vietnam of computer science, to me it's tough to write something that works for everybody like hibernate etc. ;-) http://blogs.tedneward.com/post/the-vietnam-of-computer-science/ [tedneward.com]
(Score: 3, Interesting) by DannyB on Thursday May 04 2017, @02:50PM
Item number 2, thinking in sets instead of procedural thinking hit the nail right on the head. That is exactly my own personal experience years ago. I could write simple queries. Then as the need for more complex queries arose, my thinking naturally tended towards how to solve the problem with loops and procedural code. I did not want to become too deeply tied to Microsoft SQL dialect, so I resisted that. Another idea was to query individual tables with the appropriate ordering, and then put it all together with procedural logic in the application server. But that seemed rather ugly to me so I didn't do it.
I thought more and more about how to solve each problem. Each problem was a new puzzle to solve. But I recognized patterns that I was using. Sub queries to generate single columns in the output. Sub queries that get a table name and are JOINed to the main tables. UNIONed queries. Generating preliminary results into temp tables scopped to the current overall query, and then using those results in subsequent queries that formed the final result.
In every case, I ended up with pages of neatly formatted code that accepted parameters and produced a single resulting table for the application server. I could make the application server spit out this entire query to the server, or I could store it in a stored procedure.
It basically dawned on me how to think in sets and joins and exclusions and inclusions. Filtering things out. Filtering things in. How to write WHERE clauses so the database could take advantages of indexes.
Once I had the Ah Ha! moment, it all seemed so simple going forward.
I don't consider myself a SQL advocate. But I recognize that it is suitable for so many problems. It's not the only tool. And not always the right tool. But it really is appropriate for many problems, especially business problems.
I've looked at recursive queries. But I have never needed one yet.
As for performance, I can throw a several page long SQL query at the server (not a stored procedure) and in 10 milliseconds get back a firehose of rows from tables with tens of thousands of rows. Reports are extremely fast. Even reports that go to hundreds of pages. The query takes a few seconds. Putting the results together through the report engine (JasperReports) into nice formatted pages take many times (still seconds) that of the query. The report filters, which ultimately affect WHERE clauses are on columns of many different tables.
If you eat an entire cake without cutting it, you technically only had one piece.
(Score: 3, Funny) by DeathMonkey on Thursday May 04 2017, @05:36PM
All I can say to that is;
3: TETSUOOOOOOO!!!!!!!
(Score: 0) by Anonymous Coward on Thursday May 04 2017, @10:13PM
Before SQL hit big, I used procedural query languages (or at least semi-procedural) and it was hard switching to SQL for non-trivial queries. With the procedural way, you had to manually decide what index to use or make a new temp index if that's a better option. But this also gave you a sense of the performance. When you let the RDBMS optimizer pick the query strategy and indexes, it's hard to know what it's going to do ahead of time. It mattered even more in the early days of RDBMS when the optimizers were not very good.
And, I still encounter a fair amount of problems that would be simple and quick to implement in procedural query languages such that the SQL is say 5x or more code. Maybe if I knew SQL or the dialect well enough I could simplify it, but I don't. My procedural app coding skills can transfer to procedural query languages, but NOT to SQL very well (and functional-ish (FP) languages).
Thus, the FP/set nature of SQL is not necessarily "bad" per se, but it doesn't leverage one's typical procedural skills, making some things difficult for non-specializing query writers. I have to confess that I often miss some pre-SQL query languages.
(Score: 0) by Anonymous Coward on Thursday May 04 2017, @02:12PM
PeopleSoft does machine-generated SQL.
I find myself quoting Marlon Brando every time someone hands that off to me.
...and not just Apocalypse Now "the horror... the horror..." I have to get shit done, so out of necessity it often veers to "Get The Butter."
(Score: 4, Informative) by Grishnakh on Thursday May 04 2017, @04:16PM (10 children)
They use all caps
I see this all the time though, in blogs about SQL, in the actual documentation, etc. I can see why so many people do it: it's because so many other people do it, so they think it's the standard.
It also does help separate the SQL keywords from variable names, table names, etc. I guess if you were writing an actual blog (rather than a StackOverflow response) you could use different colors to highlight the SQL keywords instead, and some text editors probably do this too, but most venues don't support this. Also, if you're writing queries that are embedded in another language (like C++), the auto-highlighting thing probably isn't going to work.
(Score: 2) by Nerdfest on Thursday May 04 2017, @04:38PM (7 children)
"That's the way we've always done it" is one of the most dangerous things ever uttered. I think the whole upper case thing came from syntax diagrams in manuals that showed keywords in all caps, and people thought you had to. I don 't care about the reason though, it makes it quite unreadable. Keywords are one of the things you care *least* about. Proper names, and lower/camelCase make SQL readable. It's time to stop making excuses.
(Score: 3, Insightful) by Grishnakh on Thursday May 04 2017, @04:48PM (3 children)
You can't expect people to do things differently just because *you* think they should be different, when the actual manuals and documentation show something different.
(Score: 3, Touché) by Nerdfest on Thursday May 04 2017, @05:41PM
Duh ... of course I can.
(Score: 1) by Ethanol-fueled on Thursday May 04 2017, @06:16PM (1 child)
What that boils down to in my experience is that doing things a different way is usually doing things a better way, but implementing that new way costs monies in the short-term and coincidentally managers will bend over backwards to avoid spending money and pad their short-term profits.
What results is band-aid fix on top of band-aid fix, and they have to be dragged into modernization kicking and screaming -- and usually when it's too late, like when something irreplaceable breaks or there's a massive data loss that causes operations to grind to a screeching halt.
(Score: 2) by Grishnakh on Thursday May 04 2017, @08:12PM
Using upper-case SQL keywords isn't going to make anything break; it's purely cosmetic. It's even less consequential than the old tabs-vs-spaces argument, or camelCase vs. under_score, etc. And this has nothing to do with managers anyway, this is something purely down to developers and their habits. My argument is just that it's basically monkey-see-monkey-do; people see it done this way *so much* that they just go along with it, because they're probably not writing that much SQL anyway (just some queries that are embedded into other code), and they really don't care that much, and assume that it's done that way for some valid reason and they're not going to bother questioning it because they know that while technically any modern SQL database isn't case-sensitive with those keywords, that it's usually better to just go with the flow, just like they do with any multi-person programming project where you have to follow the common coding style guidelines instead of just doing your own thing.
(Score: 3, Informative) by Thexalon on Thursday May 04 2017, @05:27PM (2 children)
On the contrary, keywords are what I care about the most! I for one want to be able to tell immediately whether what I'm looking at starts with the word "delete", for instance, because that matters more than exactly what table(s) I'm going to be looking at. What you seem to be describing is the equivalent of a syntax highlighter that highlights everything that's not syntax, which makes not much sense.
ALLCAPS keywords in SQL is part of every single style guide I've read. You see it everywhere because the other developers are following a standard that has tested by time and thousands of people and found to work reasonably well. Trying to argue "I'm right and everybody else is wrong" is not likely to be a winner though.
The only thing that stops a bad guy with a compiler is a good guy with a compiler.
(Score: 2) by Nerdfest on Thursday May 04 2017, @05:44PM
You don't have to agree with me. I can't force you to be right.
More seriously, the keywords stand out better using indentation, without being distracting, I think.
(Score: 0) by Anonymous Coward on Friday May 05 2017, @08:08AM
Meanwhile, everyone else knows that allcaps is mostly unreadable. Heck, lawyers use it for the important clauses they really don't want you to read because if you do you would never sign anything.
(Score: 3, Informative) by digitalaudiorock on Thursday May 04 2017, @07:12PM (1 child)
It also makes the SQL stand out when it's embedded in other code. I've frankly always liked that about using upper case. I'm apparently in a minority based on what I read here.
(Score: 2) by Nerdfest on Friday May 05 2017, @12:50AM
Yes, it does stand out ... but you can't read or maintain it easily.
(Score: 0) by Anonymous Coward on Thursday May 04 2017, @02:05PM
I it where not for that stupid kid we could have gotten rid of these dinosaurs ages ago, BUT WE HAVE TO KEEP RESTORING FROM TAPE
(Score: 3, Interesting) by bootsy on Thursday May 04 2017, @04:45PM (4 children)
Relational theory uses set theory and boolean predicate logic. This is very, very powerful especially for ad hoc queries. Try doing that in a hierachical object data store.
SQL then takes this powerful framework and cripples it. The common use of NULL forces a half implemented usage of tri-value logic that causes a lot of confusion. If the value is not applicable or simply not known yet then we should have values that tell you that state or better yet normalise so the misising information is in a second table that doesn't have a row at all.
If you've ever seen Tutorial D by Chirs Date and Hugh Darwin you begin to see what a database query language could have been. Being able to pass sets around and manipulate them using set operators easily is sadly not what SQL gives us.
On the plus side, in SQL you say what you want and not how to do it and the query engine works out the best way to do it. ( Except it often doesn't and you end up having to index and partition to improve queries but at least modern SQL Database warn when the query plan is going to be poor ).
(Score: 2) by kaszz on Thursday May 04 2017, @11:50PM
What would "Tutorial D" enable me to do that SQL would not allow?
(Score: 0) by Anonymous Coward on Friday May 05 2017, @05:06AM (2 children)
"Null" is a hotly debating topic. While it's possible to design tables without ever using it, it can create what most would consider a mess of "slim" tables.
I don't think they can practically be removed, BUT how they are handled by common operators could use a review. For example, if you concatenate 3 strings and any one of them is Null, the ENTIRE expression is null", a poison pill. Null strings should be treated as zero-length strings in concatenation in my opinion.
How they are handled in comparison operators is also suspect. For example if I have the clause: WHERE NOT x = 3, it should still return rows where x is Null in my opinion.
(Score: 0) by Anonymous Coward on Friday May 05 2017, @08:16AM (1 child)
Why do your strings allow null (Unless they were the result of an outer join)?
While having string fields allow null can make sense in some cases, every single time a colleague has wanted a string field to allow nulls, I ask them "what's the difference - in this specific field - between null and an empty string" - not once have I gotten an answer indicating that there is a valid reason to allow a string to be null.
(Score: 0) by Anonymous Coward on Sunday May 07 2017, @07:33AM
One cannot always control who puts what in the data. The data user is not necessarily the data-writing app developer. This is a common issue in bigger shops.
(Score: 3, Informative) by digitalaudiorock on Thursday May 04 2017, @07:17PM (2 children)
One of the things that I'd say really caused confusing SQL syntax was the long period of time where Oracle (and possibly others) required the use of WHERE to join tables. Things are so much more clear when the JOIN is used to join multiple tables based on their logical relationship, and WHERE is used only for express filtering of the resulting structure. I've encountered people who still code that way and I find it all but unreadable.
(Score: 1) by bibendumsn on Thursday May 04 2017, @08:11PM
(Score: 0) by Anonymous Coward on Thursday May 04 2017, @09:55PM
I find the JOIN clause limiting when using lots of outer joins. In the old style in Oracle, using the "(+)" modifier in the WHERE clause to get multiple outer joins works as expected. But trying the same using a JOIN clause causes missing records higher up in the list to "short circuit" joins lower in the list, which is often not what one wants. A missing record in one sub-join shouldn't impact other sub-joins. Perhaps there's a work-around, but I haven't found to get outer join independence.
(Score: 0) by Anonymous Coward on Friday May 05 2017, @04:56AM
It looks like somebody mis-summarized the article. Here's the original:
"SQL and relational database management systems or RDBMS were both invented in the early 1970s. Edgar F. Codd invented the RDBMS while Donald D. Chamberlin and Raymond F. Boyce developed SQL."
Dr. Codd was not directly involved in the development of SQL, although it was likely influenced by Codd's work. His version of a relational query language was much more "mathy" (for good or bad).