Found 6 comments on HN
abraae · 2019-01-22 · Original thread
This is so fundamental (and has many years/decades still left) that I would go back to one of the sources e.g.
gshulegaard · 2016-05-12 · Original thread
This is interesting, but I admit I am a bit confused.

Having read "An Introduction to Database Systems" by C.J. Date (, I have a tremendous appreciation for Relational Algebra and Theory which allows for the closed functional nature/syntax of SQL which holds true across the various normal forms (1st-5th).

Perhaps due to my own lack of understanding, I always assumed that without an underlaying relational model SQL loses its closure. So for me, I always thought the distinction between SQL and NoSQL was whether or not the underlying database model was relational.

Sure for many of the queries against a non-relational model you could adopt a SQL-like syntax (which many languages seek to do), but it would no longer be operating in the closed Relational Algebra space.

Could you comment on this and help me understand the finer points/where I went wrong?

crdb · 2016-05-02 · Original thread
The relational model, by being based directly on set theory and first order logic, is the most robust method for managing data today.

Yes, SQL is not the best implementation; theoretically we could try out Tutorial D/D4/whatever, but it's good enough especially in the Postgres flavour which is built on decades of academic and commercial research. PostgreSQL is almost entirely declarative (the RM is declarative) - how do you propose to improve on that?

As a quick reminder, these are the things you have to build manually into your application if you're not using a relational DBMS (or check are included in your new black box solution for managing data):

- data being shared (concurrent access, writes, etc.);

- avoiding redundancy, inconsistency (which you get for free by centralising the data into a single copy instead of having one copy per thread/program/user);

- transaction (= logical unit of work) atomicity (all or nothing) - say you want to transfer money from A to B, decrease A, then increase B; what if "increase B" fails? A relational database will ensure your transaction does not half go through;

- integrity - impossible things are avoided by constraints, anything from "an employee logging 400 hours of work this week" to parsing different date formats (because the date is stored as string because it's an Entity Attribute Value antipattern because "the schema has to be flexible");

- easily enforced security ("nobody but finance accesses payroll tables");

- and obviously data independence, such as freedom from having to specify the physical representation of data and access techniques in your application code. (OK, this is one place where SQL is not perfect; but it's pretty good)

(*thanks to C. J. Date for the list)

The sad thing is that this stuff does not seem to be taught anymore; I get a lot of business from the fact that most frameworks encourage antipatterns by design (Bill Karwin's book on the subject [1] is a great, easy read for those who can't stomach C. J. Date's 1000 page "Introduction" [2]).



ScottWhigham · 2013-07-31 · Original thread
That's an absurd line of thinking. First, Course has no SQL courses [1]. Second, just because "x" sells cheaply somewhere (or is given away) does not automatically make all other content creators fall in line. You obviously are not familiar with Chris Date's work. His book sells for $150 still [2] so I'm actually surprised to see his video courses sell for less than $500. And I know I'm not alone in chuckling at your "the era of Coursera" comment haha. Idealism at its finest!



1331 · 2010-10-27 · Original thread
If you would like to learn database theory, then I recommend the following book:

_An Introduction to Database Systems_ (8th Ed.) By C. J. Date

Get dozens of book recommendations delivered straight to your inbox every Thursday.