Found 4 comments on HN
dizzystar · 2017-01-17 · Original thread
Not online, but SQL Antipatterns is the book that had the largest impact on my thinking:

https://www.amazon.com/SQL-Antipatterns-Programming-Pragmati...

But as you said, you haven't actively learned SQL, so probably need to find some free data sets to work with.

You can probably start with Data is Plural. That will, at least, give you some raw data sets so you can get started on learning how to build up a database from unorganized data first:

https://tinyletter.com/data-is-plural

Edit to add: First and foremost, you have to learn normalization. Without that, you aren't doing any SQL.

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]).

[1] http://www.amazon.com/SQL-Antipatterns-Programming-Pragmatic...

[2] http://www.amazon.com/Introduction-Database-Systems-8th/dp/0...

swah · 2015-10-02 · Original thread
I'd do the same. I think this book is still relevant: http://www.amazon.com/SQL-Antipatterns-Programming-Pragmatic...

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