HN Books @HNBooksMonth

This is so fundamental (and has many years/decades still left) that I would go back to one of the sources e.g. https://www.amazon.com/Introduction-Database-Systems-8th-Edi...

What I found from some quick googling. http://infolab.stanford.edu/~ullman/dscb.html

https://www.amazon.com/dp/0321197844

https://www.amazon.com/dp/1558605088

http://www.wiley.com/WileyCDA/WileyTitle/productCd-EHEP00071...

This is interesting, but I admit I am a bit confused.

Having read "An Introduction to Database Systems" by C.J. Date (http://www.amazon.com/Introduction-Database-Systems-8th/dp/0...), 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?

⬐ btilly

Syntax and being relational are orthogonal.

You can set up non-relational data structures in SQL. You can set up a relational data structure in virtually any programming language.

However what the NoSQL people are learning is that smart developers really want relational models. So they are offering the features that can be used to achieve that.

⬐ gshulegaard

That's where I think where most NoSQL proponents start to miss the value of relational models and the closed Relational Algebra it allows.

As I understood it, SQL was a language for describing the Relational Algebra which was a closed mathematical concept.

You can take the syntax, assign functions to produce output from a non-relational model, but it's no longer SQL...and it's underlying power (the closed Relational Algebra) is no longer present.

So in a sense syntax and being relational are orthogonal, but syntax isn't the defining characteristic of SQL (or why it's so powerful). I think a more insightful statement is: SQL (Relational Algebra) and being relational are codependent and relational and non-relational are orthogonal.

Which, if I am not mistaken (and again I am still trying to understand the finer points which is what motivated my original comment), NoSQL people fundamentally _cannot_ offer a query language similar to SQL based on the closed relational algebra.

They can mimic the syntax to make it more intuitive for new users coming from traditional RDMBS environments, but it's fundamentally _not_ SQL/relational algebra.

But again, I am just a cursory admirer/learner and I am still trying to iron out my own understanding of the underlying theory. So all additional information/clarifications welcome :)

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

Introduction to Databases course:

http://infolab.stanford.edu/~widom/cs145/ http://www.amazon.com/dp/0321197844/?tag=stackoverfl08-20

Install Sql Server 2008 Express for best .Net integration

http://www.microsoft.com/en-us/server-cloud/products/sql-ser...

or MySql if you're Linux-inclined

http://www.mysql.com/

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!

[1] https://www.coursera.org/courses?search=sql

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

⬐ mathattack

There is steady downwards pressure on all video based education. Saying SQL is not on Coursera today is like saying, "I can't find the complete works of Hemmingway on Amazon" in 1995. Chuckle if you want, but the trend is your friend.

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 http://www.amazon.com/Introduction-Database-Systems-8th/dp/0...