Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!


Forgot your password?
Databases Education Books

Ask Slashdot: Learning DB the Right Way; Books, Tutorials, or What? 106

An anonymous reader writes "I have deep experience programming in many languages, and I've some exposure to SQL through PostgreSQL. My math goes so far as trig and algebra, with a little statistics. So far, I've learned enough to be dangerous: mostly via other people's code, experimenting, the PostgreSQL docs, etc. I've been successful using the DB in various ways, but I know I am missing a great deal (and probably doing it wrong, at that.) When DB articles come up on Slashdot, I don't recognize a good deal of the terminology. What is the best way for a technical person to learn SQL/DB work using PostgreSQL? Books? Tutorials? I should mention I don't have local access to a university or people with DB knowledge; have to do this on my own, so books or the Internet are pretty much my options."
This discussion has been archived. No new comments can be posted.

Ask Slashdot: Learning DB the Right Way; Books, Tutorials, or What?

Comments Filter:
  • by rwa2 ( 4391 ) * on Saturday July 13, 2013 @12:22PM (#44270031) Homepage Journal

    Oh well, goes along with the theme:

    http://geekandpoke.typepad.com/geekandpoke/2011/01/nosql.html [typepad.com]

    • by gl4ss ( 559668 ) on Saturday July 13, 2013 @12:27PM (#44270069) Homepage Journal

      once he has put on a db here's a handy reference http://howfuckedismydatabase.com/ [howfuckedi...tabase.com]

      • Thanks for that site, awesome.

      • by rk ( 6314 )

        Also, thanks for that. As an ex Slony user, I appreciate that reference!

  • by Tim Ward ( 514198 ) on Saturday July 13, 2013 @12:28PM (#44270077) Homepage

    Date, An Introduction to Database Systems

    • by K. S. Kyosuke ( 729550 ) on Saturday July 13, 2013 @12:42PM (#44270171)
      Amen to that, brother. Although Date has recently published a few "less hardcore" books mostly for working professionals: O'Reilly's SQL and Relational Theory might be more palatable for some. And since most people will be forced to work with SQL anyway (as opposed to D)...
    • by Anonymous Coward

      As a dba for over 40 years and having worked on almost all the major db systems around (and some that are no longer with us) I can totally recommend the Date/Codd books on db theory. They have it all. What they don't have about some specific system you can get from the vendor documentation or via online searching. I still have my original 1971 edition of Date & Codd's book on db systems.

    • by dbc ( 135354 ) on Saturday July 13, 2013 @01:35PM (#44270441)

      Yup. Date is the One True Source.

      That said, when I found myself in a similar situation to the OP, here is what I did and found: 1) Read Date. 2) Make some toy databases. 3) Go back to 1 for a few iterations. At the point where I needed to deploy a database at work, I was able to do two things: a) convice my boss to hire a database expert, and b) have a strawman design for a database to go along with a spec when the expert came on board.

      I learned that database experts learn to be very good at diplomacy :) I learned a huge amount from her as she showed me how to work up a better design and show me why it was better. Of course, that is why I hired her.

      After reading Date and making toy databases I had the fundamental concepts, but lacked the practical experience to make good choices in how to normalize the database. How you normalize impacts performance, maintainability, and ease of maintaining data integrity. So bottom line is I found that self-teaching database design got me to something useable, but like many other things in software, the fastest way to learn is to make friends with a smart cube neighbor.

    • $170! Holy Cow that is an expensive book

      • by Anonymous Coward

        It's an upper-division textbook. On the other hand, if you want to know WHY you should probably be using an RDBMS for most of your application problems, this is the book to get.

        I have the 8th edition, and although the book could do without some of his more opinionated footnotes, the entire text from front to back is absolutely rock-solid relational database theory.

      • by rk ( 6314 )

        If your career will involve databases for any length of time, it will pay for itself many times over.

    • by plopez ( 54068 )

      And Gray, "Transaction Processing: Concepts and Techniques".

    • That's the one I learnt from in 1987. Relational databases haven't changed that radically since then and the knowledge is applicable to any implementation of them.

  • by dejanc ( 1528235 ) on Saturday July 13, 2013 @12:33PM (#44270101)
    When Stanford first offered free online courses, I took a couple including Intro to DB. It's an online course and it was very informative and I learned a lot through it. I'm not sure when it starts next (and if you can just enroll whenever to see material), but here it is: https://class2go.stanford.edu/db/Winter2013/preview/ [stanford.edu]

    Keep in mind though: this is a full fledged college class, not some sort of YouTube tutorial or anything like that. If you want to follow it properly, be prepared to spend some time a week doing homework and following lectures.
    • Re: (Score:3, Informative)

      by Anonymous Coward

      The class isn't in session but you can still work through all of the coursework on Coursera. https://www.coursera.org/course/db

    • Great advice and its free and web-based. I also took this Stanford course when it was first offered in 2011. The professor has added additional course topics since the course was first developed. While it is a self contained course, I strongly suggest you obtain one of the 4 referenced textbooks - any of which can further expand on the topics covered and offer additional underlying theory. A side benefit will of the course (for me) was an exposure to some of the shortcomings/lack of capabilities of some
  • by tbg58 ( 942837 ) on Saturday July 13, 2013 @12:33PM (#44270107)
    Before you develop any bad habits it would be excellent to get a good handle on how to organize data. _Database Design for Mere Mortals_ by Michael Hernandez is an excellent source for this and you will be able to breeze through it with your programming knowledge. You already know data types, but this book, which does not contain a single line of code, is a good primer on data organization and techniques for making relational databases function efficiently.
    • by Jawnn ( 445279 )
      An enthusiastic second to this suggestion. This book is the place to start when trying to learn relational database design. Yes, it is far from a complete treatise on the subject, but what it does offer is eminently approachable and immediately useful; something that can not be said of most of the other texts covering the subject. Dear gawd, I wish that more "developers" had read this book before building anything that used a relational database to store and manipulate information. Once you get the normaliz
  • by Anonymous Coward

    A little of everything, with emphasis on hands on experimenting. Or a lot of everything, with big emphasis on hands on experimenting.

    You won't learn all you need to know in a week, despite the pitches made by the books and boot camp courses.

  • by girlintraining ( 1395911 ) on Saturday July 13, 2013 @12:35PM (#44270129)

    There is no One True Way to learn a language, a piece of technology, etc. It depends on your learning style. One thing a lot of people who come into IT are shocked to discover is the sheer amount of stuff to learn, and the lack of tutorials, classes, etc., that effectively cover it. Many leave for just this reason. The first thing you need to learn in this field is how to teach yourself something, and that means knowing what works best for you. Some people need to write it down. Some people need to hear people talking about it. Some people can just absorb it by osmosis. Some people are global thinkers, others are detail-oriented. Personalities run the gamut in this field, but the one thing everyone who succeeds in this field has in common is that they can learn new information quickly, and on their own.

    A lot of people will suggest books here, and that's fine. It may work well for them, and possibly for you. But you need to know what your own learning style is first, before you go much farther, especially if you're branching out into a new field or subfield. The time spent teaching yourself how to learn, and finding your own learning style, will pay for itself far, far more than any book suggested here -- your whole career will benefit.

    • girlintraining is absolutely right. Heed her advice: know thyself. With that said, I'm going to give you what works for me and some gotchas I've found in the field.

      Some people think they need just a specific answer so they learn by googling for everything and never learn outside of a narrow box. Personally, I find they often don't make good programmers or DBAs. I think a disciplined approach to learning a language or database is a must. The PostgreSQL documentation [postgresql.org] is excellent in that regard. It star

      • by Anonymous Coward
        Regarding the name thing. Everyone has a name if they ever want to be called/referred to by someone else. If you live amongst people eventually someone will give you a name whether you like it or not ;).

        But as globally unique identifiers they are useless. Where possible I prefer to let people choose what name and title they prefer to use in correspondence with them.
  • by parbot ( 629557 ) on Saturday July 13, 2013 @12:37PM (#44270137)
    On Coursera you can find the Stanford course "Introduction to Databases" by Jennifer Widom. https://www.coursera.org/course/db [coursera.org] . It is free and covers a very broad range of database topics.
    • by Anonymous Coward

      ANnd Jennifer Widom is the wife of Michael Stonebraker, who is a hard core database dude and also happened to be the one who started the Ingres project, on which PostgreSQL is based.

    • by Anonymous Coward

      Subject says all. Not for me.

  • by Nutria ( 679911 ) on Saturday July 13, 2013 @12:41PM (#44270163)

    Are the databases preexisting, and you'll be "just" querying and modifying (inserts and deletes count as modifications)? In which case SQL is "all" (note the quotes) that you need to know.

    Or do you also need to design systems? Then you need to know UML, data normalization, access strategies and a dozen other things.

    • by nurb432 ( 527695 )

      No matter what you are doing with a DB i would say understanding normalization is the important thing.

    • Then you need to know UML

      No, he won't. He'll need a brain, though.

      • I agree; normalized databases come naturally. You have to work at it to have an non-normalized database.
        • What? Keeping total on invoice is non-normalized (redundant data, violates 3rd). You supposed to total up line item every time you want invoice total. Fanatics will say lineitem shouldn't even have price, it should just join to pricing history.

          • by cc1984_ ( 1096355 ) on Saturday July 13, 2013 @04:39PM (#44271473)

            Someone once told me "Normalize until it hurts, then denormalize until it works."

          • Fanatics will say lineitem shouldn't even have price, it should just join to pricing history.

            That's basically impossible once you hit the "Amazon" level of item count and algorithmic price adjustment.

            Even in simpler cases, it makes sense to store what you charged that customer at that time for that item. Normalizing that sort of data makes sense, though, so you have an "Invoice" table with a key (like the invoice number) and a "InvoiceLines" table with each line referencing an invoice. That kind of normalization makes it easy to answer questions like "how much did we charge for that item (on aver

          • What should it link to for a manual override entered directly onto the invoice?

            • A discount % is what the fanatics will say. I'm not one of them, but they are everywhere. I agree with the sib, lineitem should record price charged and discount given. Invoice should record price schedule used. By the magic of definitions it's not redundant data.

              This is just to be 3rd NF.

        • Re: (Score:2, Insightful)

          by Anonymous Coward

          normalized databases come naturally

          Not sure about that. I keep on thinking database design is easy (having worked with them for over ten years). Its just a case of working out if entities have a one to many or many to many relationship usually.

          Then I get asked to "take a look" at some PhD students design, and realise how unnatural it is to some people.

          • This is a true point. If you have a good feel for organizing things in a way that makes sense, then your database will probably make sense. You'll have to learn things like query optimization, and how to add indexes to things, but overall it's a matter of organizational skill.

            On the other hand, some things that seem simple and obvious (version your database, make backups) seem to be like rocket science to some people. I'm not sure why.
          • I've met more than one very good developer who didn't grok database design.

            One subcontracted me to teach his girlfriend who needed it for a course she was doing. Basically, it involved us all going to the pub and talking about movies and music while she scribbled furiously. It's a good teaching example because it involves natural/surrogate keys (how do you deal with movies/bands/artists with the same name, or movies with more than one title?), multiple relationships (an actor might also direct, a musician

  • by Anonymous Coward

    To the extent that set theory is important, I would recommend reading Applied Mathematics for Database Professionals (which I'm reading right now). It very carefully builds the ideas of set theory which seem necessary to work with relational DB's, one step at a time. Some of these same concepts also appear necessary if you ever want to work with graphs/lattices/big data, etc. If you've ever done a truth table, you're already mildly familiar with it.

    From the book ...

    It is a common misconception that the w

    • by plopez ( 54068 )

      But remember that SQL queries are bag operations rather than set operations. You have to hack the scripts to ensure set operations.

  • by Animats ( 122034 ) on Saturday July 13, 2013 @01:13PM (#44270329) Homepage

    It's not that complicated.

    In the SQL world, data is stored in "tables". Each table consists of "rows" of "records". Each record has "fields". Each field has a "field name" and a fixed "type", like TEXT, INTEGER, or DATE. Tables are created with the CREATE statement, where all the field names and types have to be specified. So that's what SQL data looks like. That part is fairly simple.

    Tables start out empty. Data is added to a table using the INSERT statement. Existing records can be changed with the UPDATE statement. The SELECT statement is used for searching.

    What makes SQL useful is that searching is very powerful. One SELECT statement can look things up in more than one table, find matching items, sort, summarize, and extract specific fields. The key to understanding SQL is learning what SELECT can do. On the other hand, if all you need to do is find one row of a table based on one key, the SELECT statement for that is very simple.

    Tables have "indexes". If you use a SELECT statement with a search request for which there is no helpful index, the entire table will be linearly searched. This is slow. So you specify which fields need an INDEX to speed things up. This is usually done when the table is created with CREATE, but it can be done later. When looking things up with SELECT, you usually don't have to mention indexes; which index to use and how to use it is figured out by the database system.

    SQL databases scale up well. Gigabyte-sized tables are normal. Terabyte-sized tables are not unusual. You can have many queries and updates running on the same table at the same time. The database system handles all the locking for you. Some database systems can be run on clusters of machines, and some support multiple redundant copies. You can do a lot of things while a database is running that you wouldn't think of as being possible. You can add a new index, or even a new field, to an existing table while the database is in use. There's a lot of heavy machinery behind the scenes to make all this work.

    All the major databases try hard to maintain data integrity. A machine crash and restart will not damage any serious modern database. Program crashes are handled, too. A group of SELECT, INSERT, and UPDATE statements can be blocked together as a "transaction". The database doesn't change until a COMMIT statement is executed, and then all the changes take effect at the same time. If something goes wrong, like the program crashing or even the machine crashing before the COMMIT, the database is unchanged. If your program detects an error and needs to abort the transaction in progress, it does a ROLLBACK and the database is as it was before the transaction started. There's a lot of heavy machinery behind the scenes to make all this work.

    There are security features. Access to tables can be restricted, in some cases down to the field level. Databases have user accounts, which are not necessarily tied to operating system login accounts. You can have accounts which can only read some tables, not update or delete them, or accounts which can't see some fields of some tables. This is valuable in web applications.

    Database programs have libraries which allow them to be called from various programming languages. Programs in different programming languages can talk to the same database at the same time. So you're not locked to a specific programming language.

    Those are the basics. Go install some SQL database on your desktop machine and play with it. MySQL, MariaDB, and Postgres are all free and will work on Linux or Windows desktops.

    • That and normalisation based on keys to design out duplication of data and remove years of developer pain!

    • by sphealey ( 2855 )

      - - - - - Tables have "indexes". If you use a SELECT statement with a search request for which there is no helpful index, the entire table will be linearly searched. This is slow. - - - - -

      Some tables have indexes. Some don't. Sometimes it is faster to access rows via an index, and sometimes a full table scan is faster (and in the cases where a full table scan is faster, it will typically be 100x faster than index-to-table access).

      I agree with you that getting started is not that hard (you can also down

    • Actually. It is complicated. You don't know enough to know that and that makes you dangerous if you were a DBA.
      Schemas, OLAP, speed, how to write queries so you actually get the results you were expecting and not some subset.......

      Anyone that voted you up either did not think about it or is equally as dangerous.


    • Go install some SQL database on your desktop machine and play with it. MySQL, MariaDB, and Postgres are all free and will work on Linux or Windows desktops.

      Or, experiment with SQLite [sqlite.org]. You can download a self-contained standalone precompiled binary that you run as an ordinary command-line program. (ex: "sqlite3 mynewdatabase.db") In fact, sqlite3 is already installed by default on your Mac and probably also on your Linux desktop, so you might not need to install anything at all. There are no servers to set up and maintain and no access permissions and user accounts and passwords to configure. And the database you create is just an ordinary disk file that

    • Actually, it is more complicated to do it well. Creating a good database begins with the design, not a SQL statement. If terms like E-R model, normalization, decomposition, * normal form, etc are not familiar terms - they should be (or at least their concepts). If you just want to kick the tires and write some code, that's great. Just don't confuse a proficiency in SQL programming with proficiency in database design.
  • A breif intro (Score:5, Informative)

    by plopez ( 54068 ) on Saturday July 13, 2013 @01:19PM (#44270357) Journal

    1) SQL is not a relational database, it is an interface to a relational database management systems, e.g. Postgresql. The "NoSQL" crowd lost me in the first 10 minutes when they showed me they did not know the difference. From that point forward I had a tough time taking them seriously.

    2) Date is good but a bit hard to slog through sometimes. Realize that RDBMs are based on actual Math theory. But you don't have to derive the theory so don't be afraid.

    3) Normalization is import. Honestly, people talk about the "Object/Relational impedance" and I have never seen it. I have found that if you define your objects properly up front you get your DB normalization almost for free. And if you understand your data properly and do a good job at normalization you get your objects almost for free.

    4) Know your database engine. RTM and try various scenarios. Have fun but only on a test instance on a test machine.

    5) Know your hardware/VM system. I have found many people blame the DB engine for poor performance when poor hardware configuration is the fault. Learn how to profile.

    6) Learn how to profile software as well. Everybody blames the DB engine when performance is poor when most of the time it is their crappy code.

    7) Some best practices: http://c2.com/cgi/wiki?DatabaseBestPractices [c2.com]

    • 1) SQL is not a relational database, it is an interface to a relational database management systems, e.g. Postgresql. The "NoSQL" crowd lost me in the first 10 minutes when they showed me they did not know the difference. From that point forward I had a tough time taking them seriously.
      If you want to nitpick then do it right. SQL is not an interface. It is a query language: Standard Query Language, well the standard also contains DDL ...

      I guess you simply are not smart enough to grasp what NoSQL is about or

      • SQL is not an interface. It is a query language: Standard Query Language, well the standard also contains DDL

        Structured Query Language [wikipedia.org], actually.

        If you want to nitpick then do it right.

        Words to live by.

        • True :D it is meanwhile "Structured" ... I think when it was first introduced it was still named "Standard" and I keep mixing this up, lucky this was not an exame ;D

      • Re:A breif intro (Score:4, Informative)

        by plopez ( 54068 ) on Saturday July 13, 2013 @06:24PM (#44271993) Journal

        normalization is mainly used for space reduction, in our days that is far less important than at the time when it was "invented".

        Wrong again. Normalization is about data consistency, space saving is secondary (and given the overhead of keys, constraints, indices etc. possibly not true). But the NoSQL crowd also lost me on this point as well. "Eventual consistency?" What does that mean? How about "you will eventually get paid" or "your medical records will eventually show your drug allergies" or "your credit rating will be eventually correct".

        But you're right, I was in a hurry I should have said: "SQL is a scripting language used to access an API of a RDBMS".

        • "Eventual consistency?" means that in the end the data will be consistent :D pretty simple.

          However it is not ment in the way we know it from traditional databases as we are not talking about schema consistency here.

          Consistency in huge data means, if you query, regardless which part of the cluster answers your query the answer will be the same.

          The background is: lets say you have 100 nodes. And you write data to your cluster. You define in the write "transaction" you accept it as written if 10 nodes have per

          • by plopez ( 54068 )

            How do you know you are accessing the correct 10 nodes?

            • You don't know. That is the point. You accept that for a while your data is "inconsistent".

              E.g. you look at my facebook site and your friend does at the same time. For quite a while, perhaps half an hour, your views might be different, one of you missing my latest status. But who cares? Tomorrow you will both see the same data.

      • by rk ( 6314 )

        Normalization has almost nothing to do with space reduction. Normalization is there to help ensure correctness of your information.

        • Normalization is good because otherwise when one of your users gets married and wants to change her surname you realise that every entry in every table that relates to the user has their surname recorded and you have to update millions of rows in twenty different tables and none of it is documented and if you miss updating it any of the tables you might break something important. In a normalised database you change it one place and you are done.

          • by rk ( 6314 )

            You know this. I know this. I'm not confident the GP knows this. :-)

  • Practical PostgreSQL: http://www.commandprompt.com/ppbook/ [commandprompt.com]
    Learn SQL The Hard Way: http://sql.learncodethehardway.org/ [learncodethehardway.org]
    Use The Index, Luke!: A Guide To SQL Database Performance: http://use-the-index-luke.com/ [use-the-index-luke.com] (my own site)
    Source: http://stackoverflow.com/questions/194812/list-of-freely-available-programming-books [stackoverflow.com]
    • "Practical PostgreSQL" is from 2002. There are so many things in PostgreSQL that have changed since then, you'd be better off reading a generic database introduction instead of that one now.

  • I'm not sure it is possible, today. From about 1995-2005 forward a large amount of database work, and development of applications against databases, was done by people who didn't really have a good grasp of the fundamentals of the concept, the history of its implementation, or a very thorough knowledge of the available technology. The result is that various self-taught paradigms became embedded in an entire generation of developers, and those paradigms have now been picked up and embedded in technology by

  • http://sql.learncodethehardway.org/book/

  • I read the headline and thought,"I still have lots of dBase III books in a box somewhere.
  • LDAP? (Score:5, Funny)

    by Blaskowicz ( 634489 ) on Saturday July 13, 2013 @02:03PM (#44270563)

    Here's a stupid question.
    Why not put all data into the ldap, next to all the login information etc.
    Then you can learn to be a bad ass sysadmin who allows you to login from everywhere AND learn a database at the same time! Many apps like mail clients, server daemons can integrate with ldap! You can do cloud computing : sync your phone contacts to it.
    If you're working in a company, tell the boss you now only need the Windows AD domain controller. It's awesome consolidation and cost savings. Also, it's a mature, market leading NoSQL implementation.

    • by sphealey ( 2855 )

      I hope someone has some Funny points left to give your post.

      Then again, given what I've seen over the years I'm sure this has been done... More than once.


    • by Anonymous Coward

      Not so much a stupid question as a criminally insane suggestion. Much like how LDAP retains its horror-inducing properties while actually proving true to its "lightweight" claim... compared to X.500.

      There really ought to be a middle way between LDAP and NIS. Something combining the simplicity of the latter with the "one question, one answer" architecture of the former.

      Anyway, this has exactly nothing to do with learning about postgresql, SQL or relational databases in general.

    • I've always thought LDAP was great to work with for the type of people who also like to do their own dental work.
  • google.
  • by the eric conspiracy ( 20178 ) on Saturday July 13, 2013 @02:17PM (#44270649)

    The most useful way I have found of thinking in a relatively simple yet robust mathematical way about SQL and relational databases is in terms of set theory.

    For example a standard join can be considered as finding the intersection of two sets.

    This this level of abstraction should be usable by someone with your level of mathematical training.

  • by WOOFYGOOFY ( 1334993 ) on Saturday July 13, 2013 @03:38PM (#44271137)

    Chris date has the clearest understanding of databases out there and while most of what he's written is not vendor or even SQL specific (although some of it is too..) his thoroughness, precision and ability to go meta on every aspect of databases is without parallel. Sure, it's not "how to use postgres" but studying him will pay off many many times over during your career when you're "stuck" because a lot of being 'stuck" in this field is not understanding the actual relational model at the conceptual level and when I say "actual relational model" I don't mean SQL, which is one just so-so implementation of the relational model. It's the places where SQL departs from the relational model and the practices that have developed in the community to compensate for that departure - without people even being aware that that's what they're doing - which create the worst and hardest problems.

  • The Manga Guide to Databases [amzn.com] is the best introduction to (relational) databases I've come across. It provides an entertaining and thorough overview of database terminology and concepts. I've used this book for years with junior engineers and interns who have all loved it, and the DBAs I've loaned it to were impressed by how much ground the book covers.
  • Data is nothing but a collection of information. The information itself is unimportant. What is important is how that information will be used. The way information is used is the predicate for its organization.

    After you grok that then you can start to learn how electronic systems store and retrieve information.

    One of the things that has never let me down is the fundamental understanding of how computers work. Remember that no matter what whiz bang shite you read about, computers do exactly two things:

  • by ph43thon ( 619990 ) on Saturday July 13, 2013 @09:36PM (#44272911) Journal

    Read Yoshinori Matsunobu's blog:

    http://yoshinorimatsunobu.blogspot.com/ [blogspot.com]

    At least, read his first post and view the slide deck:

    http://yoshinorimatsunobu.blogspot.com/2009/04/mastering-art-of-indexing-slides.html [blogspot.com]

  • Let's see - proper RDBMS considerations:
    Proper normalization of data
    Efficient keying for relating data. Compound keys can be difficult to work with.
    Use of simplest possible recordset type for working with data.
    Understanding of boolean logic and sets. Needful for creating efficient SQL queries.
    Understanding of a particular RDBMS's optimization techniques/order of operations.
    Data validation to prevent GIGO.
    Record locking schemes to prevent inconsistent updates - transactions should be used to minimize impac

  • Are you trying to learn the concepts (normalization, cardinality, keys, constraints etc) or the hands-on specifics for a specific DBMS?

"The Avis WIZARD decides if you get to drive a car. Your head won't touch the pillow of a Sheraton unless their computer says it's okay." -- Arthur Miller