Slashdot Mirror


Head First SQL

Anita Kuno writes "On a Sunday, a fellow user-group member suggested I learn SQL. The next day, an opportunity to review Head First SQL arrived in my email. Who was I to question? Prior to opening the couriered package, I had no knowledge of SQL, I knew databases were important, and I had seen the Head First website once or twice. Now, I can design and create databases, use mySQL databases, and understand questions and accompanying code posted to forums. The credit goes to Head First SQL's style, which introduces small bits of information, supported through multiple channels (such as photos with humorous dialogue, stick-men and stick-women, and input from critical personalities whose photos and input pop up throughout the book) regular tests and exercises so the new bit of data can find a home and settle into your memory. The regularly tested pieces of information are now in my brain so I don't have to look up the basic stuff." Read below for the rest of Anita's review. Head First SQL: A Brain-Friendly Guide author Lynn Beighley pages xxxv & 571 publisher O'Reilly Media, Inc. rating 9 reviewer Anita Kuno ISBN 0-596-52684-9 summary A beginners foundation for SQL

Head First SQL is about RDBMS (databases) specifically mySQL (version 5.0 or newer) and includes features of other databases. The book defines a database, demonstrates how to navigate an existing database, and teaches how to create simple and complex databases, as well as how to let a database grow from simple to complex.

Foundational understanding of database construction and navigation is the focus. The target audience is those brand-new to the topic as well as those with an acquaintance with the subject and the need for a greater conceptual understanding of databases.

It focuses on the basics of databases, so the main information should remain pertinent until RMDBS get re-conceived. I think revisions, such as the reprint due out in December, will add to the strength of the book as typos and coding errors will be addressed.

The title accurately describes the contents and the subtitle "A Brain-Friendly Guide" describes the goal of the approach. The only requirements for working with the material are: a computer or access to one, the ability to identify your operating system, familiarity with downloading from the internet (links and instructions are provided in the book and the program mySQL community release is free (download instructions are given for Mac and Windows users, I believe that instructions for Linux are not included with the assumption Linux users can access the mySQL community release page and download the program without a play-by-play)), and the courage to learn a command line window user interface if you don't already know this.

Head First SQL is most useful to those who, like myself, have heard passing references to databases and other than knowing they are important have no grasp of what it is, means, or can do. Also, this will be a helpful tool for those who have some of the verbiage, enough to pass at a cocktail party, but who would feel the cold chill of horror if expected to design, construct, and implement a database in conjunction with any of their paid responsibilities.

This is the first book that I have read on the subject of databases and the first computer book that I have been able to finish. So much of the educational information about program x, language y, or application z, depends on a working knowledge of the other two variables. This is a great book for beginners. It talks about data types, it explains null, and then has null explain himself. It tells me the importance of the semicolon at the end. All basic stuff. All stuff that other books take for granted. Many times when I believed I wasn't absorbing anything, along came questions I could answer, a crossword I could complete and match-column-A-with-column-B exercises that demonstrated that I was actually learning much more than than I was giving myself credit for.

It includes illustrations, photos, clean layout, and bite sized pieces of information. All this comes from the goal of allowing both sides of the brain access to the information. It's exactly the kind of approach that I need to reinforce the terms and concepts as well as provide encouraging feedback to keep me progressing through the material. I'm also grateful that it entertains me and keeps me going back to finish the whole thing long after the first blush of excitement has worn away.

Links, to the mySQL program necessary to work with the material, are included in the book as well as a few other links in the appendices. The Head First website is a must in order to link to the forums, newsletter, blog and downloadable files to create various tables used in the book. Head First came out with a web app called Hands On SQL which I would encourage you to try. It won't work with all of the book's material but it is a good-looking tool.

You are welcome to read my submissions on the Head First SQL forum. My user name is anita. Also, the reprint that I mentioned above is due to be in stock as of December 3rd. I'm told by O'Reilly that it includes corrections for errata submitted thus far. Take a look at the Head First SQL homepage to download a sample chapter.

You can purchase Head First SQL from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

210 comments

  1. Strange by a_n_d_e_r_s · · Score: 3, Insightful

    why does this reads so much like an add for the book ?

    --
    Just saying it like it are.
    1. Re:Strange by Anonymous Coward · · Score: 2, Interesting

      why does this reads so much like an add for the book ?

      I don't think I've ever seen a harsh review here on Slashdot. Perhaps the editors are of the opinion that a book need not be mentioned unless the reviewer thinks it's good, and since the has already been established to be good, the reviewer can go all out with hyperbole in praising it. If you want to see more critical opinions on a book reviewed here, check out the Amazon listing, where among the bogus reviews that often appear immediately for tech books, there is a pretty good examination of the book's weaknesses.

    2. Re:Strange by mysqlrocks · · Score: 3, Informative

      I'd stick with O'reilly or some publisher that focuses on computers personally.

      The Head First series is published by O'Reilly. I think it's a great series of books - even for advanced users.

    3. Re:Strange by CodeBuster · · Score: 2, Informative

      I'd stick with O'reilly or some publisher that focuses on computers personally.

      Actually, Head First Labs, the label under which the Head First series is published, is a subsidiary of O'Reilly Media Inc so the Head First series is published by O'Reilly.

    4. Re:Strange by CodeBuster · · Score: 3, Insightful

      You beat me to the post by by a couple of minutes. I agree that even advanced users can get good stuff out of the Head First books, but it is important to remember that the bad jokes, stock characters, and corny vignettes presented in the books are not there as part of some misguided attempt to be cute, but rather as a research proven cognitive aid for helping us, the readers, absorb the most information possible into our brains in the least amount of time with the minimum amount of re-reading, backtracking, and resorts to external commentaries.

      Note for GP: Understand what you are buying when you pick up a Head First book and why or else the wealth of useful information which they contain will be lost upon you simply because you cannot get past a pre-conceived notion about the presentation.

    5. Re:Strange by chromatic · · Score: 2, Informative

      I don't think I've ever seen a harsh review here on Slashdot.

      I thought Inside XML needed editing, and I certainly don't recall giving it a numeric score. Timothy probably added one just before posting it.

    6. Re:Strange by Anonymous Coward · · Score: 0

      And if you look at the unbiased reviews at Amazon, they're pretty good.

    7. Re:Strange by aztracker1 · · Score: 2, Interesting

      Personally, I've been recommending the Head First HTML book for those starting out with X/HTML, simply because it is probably the best book for beginners I've seen... Not great for those who are already knowledgeable and able to hand-code HTML though. I have honestly been looking for a similar book to recommend for those looking into Javascript more... I like the JS Bible, but it's a bit cumbersome at this point, and should probably be broken down a little... Most of the O'Reily books are not best for instruction, but the Head First series really seems to be a break from that. May peruse this book just to know more about what is in it.

      --
      Michael J. Ryan - tracker1.info
    8. Re:Strange by Anonymous Coward · · Score: 0

      Search for Anita Kuno on google and you'll find she has posted same review on more than one site. Cheap.

    9. Re:Strange by NinjaTariq · · Score: 1

      Perhaps i should do an ask slashdot for a review of windows vista in the comments...

      I bet there will be a bad review then.

    10. Re:Strange by Xylene2301 · · Score: 1

      Tangentially, I found the SQL for Dummies book to be one of the best. I did have to rip the cover off so I could hide it among my nerdier tomes.

    11. Re:Strange by Bastard+of+Subhumani · · Score: 1

      Maybe there's a business opportunity selling slip-on fake covers...

      --
      Only three things are certain; death, taxes, and apocryphal quotations - Ben Franklin.
  2. I am by Anonymous Coward · · Score: 0

    I'll be cooking Simone. Would you like some?

  3. "head first" Sql... by Anonymous Coward · · Score: 0

    SQL, spread that sexy back-end.. yea.. I'm going in HEAD FIRST!!!!

    (think beavis)

  4. Just remember... by Anonymous Coward · · Score: 0

    Apostrophes are cheap! Use them liberally!

    1. Re:Just remember... by Random+BedHead+Ed · · Score: 1

      Whats wrong with using apostrophe's?

    2. Re:Just remember... by Anonymous Coward · · Score: 0

      When you're putting them in a plural and shouldn't?

  5. who benifits? by techpawn · · Score: 3, Insightful

    This sounds like a good intro book but nothing of use to a seasoned DBA. It reads as though you gain basic knowledge of the subject of SQL and some basic mySQL syntax but the day-to-day operations of a database are probably not covered since those are very version specific and generally done with odd T-SQL statements or GUI interface.

    It sounds like a learn SQL in 24 hours book more than a SQL cookbook type resource, may be good for a developer who is starting out in the relational database world but I don't think DBAs will get much. At least, not from what the reviewer says.

    --
    Ask not what you can do for your country. Ask what your country did to you
    1. Re:who benifits? by AlXtreme · · Score: 1

      It sounds like a learn SQL in 24 hours book more than a SQL cookbook type resource

      What would you expect from a book called "Head First SQL"?

      And a minor nitpick: a seasoned DBA should know it is MySQL, not mySQL. That will be all.
      --
      This sig is intentionally left blank
    2. Re:who benifits? by YrWrstNtmr · · Score: 2, Insightful

      This sounds like a good intro book but nothing of use to a seasoned DBA.

      And a book good for a seasoned DBA will be way over the head of a newbie. Not everyone is at the same level. Not every book should be written for 'everyone'.

      Having said that...reading one book in a couple of days does not a SQL developer make.

    3. Re:who benifits? by Anonymous Coward · · Score: 2, Insightful

      No, a seasoned DBA should have forgotten as much as possible of MySQL and moved on to Postgresql or some other *R*DBMS.

    4. Re:who benifits? by dHagger · · Score: 2, Informative

      My experience with the "Head First" series of books (I have read a few, not this one however) is that they are very good beginners books. Easy to read and easy to grasp the basic concepts of the subject they cover. Without loosing interest after a few pages (which in my experience is way too common with other books). And once you know the basics, you can go on and explore more advanced topics somewhere else.

      On the other hand, once you know something about the subject, they are, well... not that good. You just sit and wait for the book to get to the point, cursing it for repeating things you already know.

      Conclusion: if you already have some basic knowledge; go for something else. Otherwise, I think these books are a good way to get started.

    5. Re:who benifits? by Anonymous Coward · · Score: 0

      This is the stupidest post ever. Someone mod this shit down.

    6. Re:who benifits? by mysqlrocks · · Score: 1

      This sounds like a good intro book but nothing of use to a seasoned DBA.

      While there's certainly overlap, there is a difference between a DBA (administering the actual database server) and an SQL programmer. This book looks like it's about SQL programming, not database administration.

    7. Re:who benifits? by Taagehornet · · Score: 1

      The book [...] teaches how to create simple and complex databases, as well as how to let a database grow from simple to complex.

      Trust me, you don't need to read a book to make that happen ;-)

      But back onto the topic: Of course you're right, no book will suit everyone in the audience. But, does the world really need any more reviews of "Teach yourself <insert a dicipline it'll take you a life-time to master properly> in <insert a ridiculous short amount of time>", reviewed by absolute beginners? There's plenty of such books, finding them really isn't that hard. The difficult part is finding the real gems, those books that'll bring you further once you've gotten the basics right.

    8. Re:who benifits? by DragonWriter · · Score: 1

      But, does the world really need any more reviews of "Teach yourself in ", reviewed by absolute beginners?


      Reviews written by people that have read the book and are in the target audience seem like the most useful reviews possible.

      Admittedly, it'd be better if we could have the beginner read the beginner-focused book, go on to have a full career in the field, and then write a retrospective review of the influence of the book on their career and beam it back in time, but absent the time machine to make the last part possible, you are hardly going to get many of those reviews published in time to be of use to anyone (on tech books at least; reviews of, say, The Joy of Cooking written that way might still be somewhat useful though they would apply to editions of the book several iterations prior to the current one by the time they were published).

      There's plenty of such books, finding them really isn't that hard.


      Finding books for beginners is, indeed, easy.

      Finding good books for beginners is less easy, which is what reviews are designed to help people with: winnowing the wheat from the chaff.

      The difficult part is finding the real gems, those books that'll bring you further once you've gotten the basics right.


      I dunno about that. Personally, I find it easier to evaluate, just by skimming the book, a more advanced book on a topic where I know the basics than a beginners book in an area where I don't know the basics.
    9. Re:who benifits? by moro_666 · · Score: 2, Insightful

      Proper DBAs will just get a major headache from people who read a book and screw up their db servers thinking that now they have "god mode" on.

        People, unless you have more experience with databases than "my little php page with mysql", don't touch "real" databases. You will go in with a grand idea that was avoided before by real DBAs that knew where locks, indexes, replications, transactions. backups and failovers matter. Newbies come in, create a shiny little script that makes the rest of server cough blood and die in agony. If they are lucky, the annoying ignorant selfish DBA will come in and rescue the world or they'll just quit.

        And the parent comment is not trolling, he's still correct. MySQL is way behind PostgreSQL and other rdbms-es. It did a good jump forward with 5.x releases, but it's still not quite there, and since the old generation DBAs are not going to move to it, MySQL will have to wait until its users catch up to get all the features and fixes in place. DB world is not a place where things happen over night.

        Just knowing how to make a select or insert or left join makes you no king in real databases. It's experience, logic, control and flow that matters there.

      --

      I'd tell you the chances of this story being a dupe, but you wouldn't like it.
  6. Don't get in over your head... by Vellmont · · Score: 4, Insightful


    On a Sunday, a fellow user-group member suggested I learn SQL...

    Now, I can design and create databases


    Database design and creation isn't something you pick up over 3 days. Sure, you can make something that works very quickly, but that doesn't mean it's a good design and isn't flawed. Designing a good database structure takes experience with the tradeoffs between full normalazation and added complexity, forseeing future needs, etc.

    --
    AccountKiller
    1. Re:Don't get in over your head... by techpawn · · Score: 3, Insightful

      IMHO Creating a database is one thing, Designing is another entirely!

      Making DDL scripts to run in the database is easy once you learn the syntax. Knowing their interaction with each other using Foreign keys, Indexes, and planning their future growth is a completely different set of skills that's only gained with experience with your data.

      --
      Ask not what you can do for your country. Ask what your country did to you
    2. Re:Don't get in over your head... by magarity · · Score: 5, Funny

      Database design and creation isn't something you pick up over 3 days
       
      Dude, it's FAR more terrifying than that. From the forums on that site:
       
      anita Joined: 07 Oct 2007
      Posts: 23
      Posted: Sun Nov 04, 2007 1:30 am
      Post subject: CREATE a TABLE with a FOREIGN KEY
      I never noticed until this evening while building a database for a customer to use with her business, but I can't seem to find the place in the book where the code for creating multiple tables from two foreign keys exists
       
      WTF: from 'I don't know anything about databases' to 'building a database for a customer' what amount of time? We don't know when "sunday" was, but even so it seems rather abrupt given that 'anita' has only joined the forum in October and is now designing databases for (presumably) paying customers. This HOWTO book must kick serious ass.

    3. Re:Don't get in over your head... by Anonymous Coward · · Score: 1, Insightful

      Or, speaking as someone who has had to clean up after such a mess, she's giving them a terrible database.

    4. Re:Don't get in over your head... by Anonymous Coward · · Score: 0

      I've never found full normalization to improve on my first attempt. Some database topics are highly overrated. And you can learn all the SQL most people need in just a couple days is you've a logical mind. Where the trick comes in is designing the database so that the types of queries you will be running against it take the least time. That often requires extra tables, inventive indexes and a good knowledge of database engine types - things not taught in most of your typical college database courses.

    5. Re:Don't get in over your head... by Tim+Browse · · Score: 4, Funny

      WTF: from 'I don't know anything about databases' to 'building a database for a customer' what amount of time?

      Well, she did say:

      "On a Sunday, a fellow user-group member suggested I learn SQL [...]"

      Maybe it went like this:

      I never noticed until this evening while building a database for a customer to use with her business, but I can't seem to find the place in the book where the code for creating multiple tables from two foreign keys exists

      FFS, learn SQL!

      Just a guess. :-)

    6. Re:Don't get in over your head... by einhverfr · · Score: 1

      Where the trick comes in is designing the database so that the types of queries you will be running against it take the least time. There are times and places where you need to create a means to "run this specific query really fast" and in that case, good relational design is not a major issue. Nothing runs faster than a sequential scan over a summary table containing the exact results you want to obtain.

      However, when you do this, you prejudice all other queries. Many queries may take far longer to run, or may not be possible at all.

      IMO, good, highly normalized database design is a prerequisite for good long-term performance (unless you are running MySQL-- then the planner may choke on your queries ;-) ). You can then increase performance using various tricks (indexes, for example) to help specific queries spend less time filtering through unwanted information.
      --

      LedgerSMB: Open source Accounting/ERP
    7. Re:Don't get in over your head... by magarity · · Score: 3, Interesting

      Re:Don't get in over your head... (Score:3, Funny)
       
      It's not 'funny' dammit! It's 'customer getting taken for a ride'. The question is generated because she's using a joining table to solve a many to many between her customer and address tables and has named the constraints herself the same on each table instead of letting the system generate them. But WTF?? Address record goes to ONE customer record! If some other customer registers the same address just duplicate the %$#@ing 200 bytes of text but don't m-m it with the customer table!
       
      Frack! Now I'm going to have to follow adventures of Anita The HOWTO Book Data Architect on that forum in the way one can't help but watch a train wreck in progress.

    8. Re:Don't get in over your head... by tuomoks · · Score: 1

      Very insightful. IMHO this is the problem today, learn a little of one product dialect and you are the master of information management, yeah, great! Vellmont is absolutely right, database design is much more and corporate information management in those databases is even more. Even if a good start can be found in books it needs years, most often very specific industry knowledge and every day learning before you can master it. SQL dialects, structures, tables, even normalization are easy but really the future needs, capacity, performance, expandability, predicting changing business needs and technology, etc are totally another ballpark. And I'm not a DBA, just a person who has gone through all the pain designing and managing huge amounts corporate information over years from card sorters through direct access, structured files, relational algebra to modern(?) object databases and still learning. Nothing against the book, haven't read it but just the impression often given and bought by some corporations, the way to trouble which someone else then have to fix ( try to fix. )

    9. Re:Don't get in over your head... by Anonymous Coward · · Score: 1, Insightful

      Did it ever occur to you that the 'paying customer' could just as easily be the tiny local coffeeshop around the corner which just needs a small database so the coffeeshop owner can put a little news about the shop online? You directly assume she's designing for a multinational for a 6 figure fee. A local coffeeshop just doesn't have the money (and the need!) for a uberl33t person like you. Jane Doe just getting into databases doing it for 300-500 bucks is enough for them. That amount of money is probably the hourly rate for someone with your skills.

    10. Re:Don't get in over your head... by DeathElk · · Score: 1

      Thanks, and good luck with the project Anita ;)

    11. Re:Don't get in over your head... by ClosedSource · · Score: 1

      The problem is that today's approach of software integration over software development means that you have to know a lot of different technologies to accomplish your goals. If today's "developers" had to understand all the technologies they use to the same depth as you suggest for database design, nothing would ever get finished.

    12. Re:Don't get in over your head... by YrWrstNtmr · · Score: 1

      The coffee shop owner could get a better solution by going to his local university (or the local DeVry or ITT tech), and getting some random 2nd or 3rd year student to do it for cheap (or free).
      Jane Doe doing it for $300 (after a weekend with this book) has juuuuust enough knowledge to screw it up, and sour the coffee shop owner on future projects.

      This harkens back to the days of the late 90's, when anyone who knew the acronym HTML could get a paying gig.

    13. Re:Don't get in over your head... by magarity · · Score: 1

      Did it ever occur to you that the 'paying customer' could just as easily be the tiny local coffeeshop around the corner which just needs a small database
       
      Yes, it did, and that was my first suspicion. And the correct answer is: small shop needs an off the shelf package and not something custom made. The vendor of such can support them via call center when the occassional problem with their product comes up as well as send out regular patches. 'Anita' is going to spend ever increasing amounts of her time fixing and refixing this beast that she's making and end up frustrating the heck out of the owners of the small operation that's hired her - as if a small operation has plenty of extra time and money to wait and/or be the guinea pig while she learns? And nevermind just designing that database, how are reports to be generated and data entered? Even for a small business this is a big project to create all that from scratch (and then to maintain it) even if you were to use Access with its forms and reports wizards, nevermind MySQL.
       
      The professional approach to "could you please set up a database for my very small business" is "Let's look over packages x,y, and z and see which of them best fits your needs." One can legitimately milk that for a week or even two of consulting fees if you include requirements gathering, investigating the features of several packages (and the vendors' support track records), setup, installation, and maybe even some staff instruction on computer use. The professional answer is NOT "Ah, what an amazing coincidence - I just got a beginner's database HOWTO book in the mail yesterday!"
       
        That amount of money is probably the hourly rate for someone with your skills
       
      I'll pass on your kind recommendation but unfortunately you've overshot a fair amount. ;)

    14. Re:Don't get in over your head... by tuomoks · · Score: 1

      Yes, you are right. My gripe is that too often it is the integration without planning / design. It is not the developers / DBAs fault but how the management sees it and buys all the marketing hype "this product solves all your business problems"! Information management, what any database is supposed to be part of, is really not an easy thing but I still think there should be someone in company responsible of that. Nothing new, same with security, performance, development environment, etc. We still too often (IMHO) make things in vacuum, too specialized for one small part of the system, whatever. This actually can accelerate the development, pieces and parts can be built to common good, think for ex. SOA.

    15. Re:Don't get in over your head... by OECD · · Score: 1

      This harkens back to the days of the late 90's, when anyone who knew the acronym HTML could get a paying gig.

      In the late nineties, pretty much anyone who knew the acronym HTML could design a functional web page.

      --
      One man's -1 Flamebait is another man's +5 Funny.
    16. Re:Don't get in over your head... by CrazedWalrus · · Score: 1

      I wonder if her name was Anita Bean? Brillant!

    17. Re:Don't get in over your head... by sootman · · Score: 1
      Reminds me of the old joke: "Last week I couldn't even spell 'engineer', now I are one."

      Who needs books? You can learn as much as you need to know for basic web apps from Philip G. (That's a great online book, and there's another here.) And he, too, is entertaining. Here's a bit comparing flat files and databases:

      What's wrong with a file system (and also what's right)

      Despite its unobtrusiveness, the file system on a Macintosh, Unix, or Windows machine is capable of storing any data that may be represented in digital form. For example, suppose that you are storing a mailing list in a file system file. If you accept the limitation that no e-mail address or person's name can contain a newline character, you can store one entry per line. Then you could decide that no e-mail address or name may contain a vertical bar. That lets you separate e-mail address and name fields with the vertical bar character. ... [When inserting two addresses at once, ] Depending on how you wrote your program, the particular kind of file system that you have, and luck, you could get any of the following behaviors:

      Both inserts succeed.
      One of the inserts is lost.
      Information from the two inserts is mixed together so that both are corrupted. ...

      So what? Emacs may be ancient but it is still the best text editor in the world. You love using it so you might as well spend your weekends and evenings manually fixing up your flat file databases with Emacs. Who needs concurrency control?

      It all depends on what kind of stove you have.

      Yes, that's right, your stove. Suppose that you buy a $268,500 condo in Harvard Square. You think to yourself, "Now my friends will really be impressed with me" and invite them over for brunch. Not because you like them, but just to make them envious of your large lifestyle. Imagine your horror when all they can say is "What's this old range doing here? Don't you have a Viking stove?"

      A Viking stove?!? They cost $5000. The only way you are going to come up with this kind of cash is to join the growing ranks of on-line entrepreneurs. So you open an Internet bank. An experienced Perl script/flat-file wizard by now, you confidently build a system in which all the checking account balances are stored in one file, checking.text, and all the savings balances are stored in another file, savings.text.

      A few days later, an unlucky combination of events occurs. Joe User is transferring $10,000 from his savings to his checking account. Judy User is simultaneously depositing $5 into her savings account. One of your Perl scripts successfully writes the checking account flat file with Joe's new, $10,000 higher, balance. It also writes the savings account file with Joe's new, $10,000 lower, savings balance. However, the script that is processing Judy's deposit started at about the same time and began with the version of the savings file that had Joe's original balance. It eventually finishes and writes Judy's $5 higher balance but also overwrites Joe's new lower balance with the old high balance. Where does that leave you? $10,000 poorer, cooking on an old GE range, and wishing you had Concurrency Control.
      --
      Dear Slashdot: next time you want to mess with the site, add a rich-text editor for comments.
    18. Re:Don't get in over your head... by Tablizer · · Score: 2, Interesting

      Database design and creation isn't something you pick up over 3 days. Sure, you can make something that works very quickly, but that doesn't mean it's a good design and isn't flawed. Designing a good database structure takes experience...

      Agreed. Some of my best DB knowledge comes about from observing what didn't work, especially as changes were accumulated over the years.

      Even something as simple as an Address table (or Contact table) can have gajillion different ways to do it, and gajillion different ways to mess it up. For example, do you have a slot for each information type such as phone number, fax number, pager number, email, etc? Or do you create a second table (many possible rows per Address row) that creates a row for each additional item along with a "contact_type" indicator?

      The second is more flexible because you can have say 8 different email addresses in there, whereas the first one can only have one (per address). But it is also more complicated. Having too many tables can complicate a system just as not having enough. The decision may depend heavily on the nature of the business and it takes experience to know what is the best fit.

      (One should probably at least have a free-form "addtional_contact_info" text column for extras that don't fit in given slots.)

      -Tablizer

    19. Re:Don't get in over your head... by einhverfr · · Score: 1

      M-M in customers/addresses can make a lot of sense in many cases. In general, I would M-M them unless I had good reason not to do so. However, I have also seen people do this sort of thing badly and hence one has to understand that this is is something which is more difficult than just duplicating the information (actually I would probably decompose addresses into several other tables-- city, country, etc but that is another matter). Also it usually isn;t as simple as a M-M mapping. Instead you have a customer, which maps to an address along with a bunch of metadata.

      This isnt about saving space. It is about ensuring that as much data as possible is centrally managed so we know exactly what it means at any given time. And it also maximizes your flexibility later on. For example you can ask which customers have shipped orders to a specific address much more quickly and robustly than you an if the address information is duplicated.

      --

      LedgerSMB: Open source Accounting/ERP
    20. Re:Don't get in over your head... by Kjella · · Score: 1

      Designing a good database structure takes experience with the tradeoffs between full normalazation and added complexity, forseeing future needs, etc. In my experience (I may have a bad one) good database design doesn't happen. I work with a huge product now owned by a huge company, but the little backstory I've heard said they bought up quite a few bits during the dotcom era. The result is that the database looks like it was designed by a lobotomized monkey on acid. I've worked with it for quite some time now, and the fact is that database changes for the most part don't happen, or only if there's some really new functionality being written. All the old junk, insane joins like you have one user id, one resource id, one resource code, all unique with different joins to different tables and different column names or different content with the same name - id in one table isn't id in the other table. If you draw a design map it'd look like puke with different colored dots all over. And don't get me started on the tables where all the column names start with "pr" for some reason.
      --
      Live today, because you never know what tomorrow brings
    21. Re:Don't get in over your head... by Bastard+of+Subhumani · · Score: 1

      However, when you do this, you prejudice all other queries. Many queries may take far longer to run, or may not be possible at all.
      And what about updating - both from a performance and a complexity pont of view.
      --
      Only three things are certain; death, taxes, and apocryphal quotations - Ben Franklin.
    22. Re:Don't get in over your head... by rasilon · · Score: 1

      It depends on what you're doing. If you're doing support for companies with multiple sites, and users who hot-desk between them them an M-M relationship is sensible.

    23. Re:Don't get in over your head... by einhverfr · · Score: 1

      I would think that inserts, updates, and deletes would qualify as the other queries one prejudices against.

      In general, when I have to do this, I tend to use a hybrid approach (and only where inserts/updates/deletes on a set of records is forbidden) and that is to essentially store what I call "checkpoint summaries." For example "last time you closed your books, your AR account had a balance of $53,123.31" Then reports can start at the checkpoint summaries and build forward. Again, this is only possible in a subset of applications (mostly those where business rules are well established and forbid inserting data into the range specified). Even there, the complexity can be a problem, but it is a lot better than dealing with live summaries.

      --

      LedgerSMB: Open source Accounting/ERP
    24. Re:Don't get in over your head... by einhverfr · · Score: 1

      A better question is why one would design a database which arbitrarily excludes the possibility you mention.

      --

      LedgerSMB: Open source Accounting/ERP
    25. Re:Don't get in over your head... by einhverfr · · Score: 1

      That is a fair point. So it requires a different way of looking at db design so that db experts can design databases that programmers can use. The current generation of solutions (including ORMs) tend to give a lot of the worst elements of both worlds.

      My solution for OOP integration is to design databases on two levels: good, semantic and mathematical relational design with appropriate triggers, etc. on the bottom level, and discoverable stored procedures on the top level. "Discoverable" means that the stored procedures are stored and cataloged in such a way that applications can either discover appropriate stored procedures themselves or, once they know a name, provide a semantic and consistent matching to their own internal data structures without additional programmer interference. This is sort of like taking the ideas behind SOAP and applying them to stored procs. I call this approach Service Oriented Database Architecture, or SODA. SODA can be done fairly easily in PostgreSQL by using consistent naming conventions of both stored procedures and arguments. This provides a lot of other benefits to the organization using the software as well, including the fact that business logic is applied consistently across applications even if those applications are written in different languages. (SAP does something similar with web services in the middleware layer, but I am talking about putting the SOA piece in the db itself.)

      --

      LedgerSMB: Open source Accounting/ERP
    26. Re:Don't get in over your head... by einhverfr · · Score: 1

      You might find my latest journal entry interesting. I have started building databases with an SOA layer built into the db so that programmers can write integration code once and not have to worry about relational layout (i.e. we map procedure to procedure rather than data structure to data structure).

      I call this approach Service Oriented Database Architecture or SODA.

      --

      LedgerSMB: Open source Accounting/ERP
    27. Re:Don't get in over your head... by Bastard+of+Subhumani · · Score: 1

      When I say a 'query' I mean reading only (and yes, I know that SQL includes updates and I know what the Q in SQL stands for (except it doesn't really anyway )).

      --
      Only three things are certain; death, taxes, and apocryphal quotations - Ben Franklin.
  7. Hmmmm... by Anonymous Coward · · Score: 4, Funny

    "This is the first book that I have read on the subject of databases and the first computer book that I have been able to finish."

    Sounds like your aversage Slashdotter, doesn't it?

    1. Re:Hmmmm... by Anonymous Coward · · Score: 0

      I have an IQ of 139 so am pretty intelligent. However I have a hell of a time reading computer books of any kind. Yes I have finished reading some cover to cover. But not many. I can also pull info out of many when used for reference. But by and large I find most computer related books to be incredibly *(*#$&# dull, flat, boring. Most are way too long. Why does every computer book have to be 700 to a thousand pages long. Get to the point already. If I read every book cover to cover I wouldn't have time to do anything. Congrats to those of you who can read this stuff all the way through. I think the head first series is an interesting concept. I will grant that it is a bit too far over the top. I'd like to see something between the style of these books and the 'classic' computer literature. I'd also like to see most of the computer books get to point, speak in plain everyday language instead of oft seen techno-babble (many times you see a sentence that could be simplified to everyday language instead of mixtures of technical double speak and acronyms), and be edited by savage editors to keep them a reasonable length.

    2. Re:Hmmmm... by Unnngh! · · Score: 1

      Can't agree more. Learning Perl was the only one I finished all the way through, and I have a small mountain of other books lying around that I've read greater or lesser pieces of. The Perl book was written with a narrative style, and read smoothly from cover to cover - and kept me engaged. I have never even used Perl in a professional capacity, I picked up the languages I use on a daily basis through reading the basic syntax sections of the books dedicated to them, through the publisher's documentation, and via the web.

      Am currently reading the Art of Assembly Language Programming, which is also written in an engaging fashion and has kept me going through several hundred pages of chip architecture and design. Maybe I'll even finish this one, that would make #2...

  8. Head on! by Deltaspectre · · Score: 0, Troll

    Apply directly to forehead!
    Apply directly to forehead!

    --
    My UID is prime... is yours?
    1. Re:Head on! by Apiakun · · Score: 1

      Thank you for providing me with the first laugh of the day!

  9. I have a question by stoolpigeon · · Score: 4, Interesting

    How does one go about just getting technical books mailed to their home for review?

    --
    It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
    1. Re:I have a question by MythMoth · · Score: 2, Insightful

      Write some reviews, then ask nicely. Or know/be an author.

      --
      --- These are not words: wierd, genious, rediculous
    2. Re:I have a question by subwayrat · · Score: 1
      Work for AllBookReviews.com

      You will find Allbooks Reviews on several book covers, book jackets, and included in the promo packages of many up and coming authors. We work with a number of publishers providing good honest reviews for covers, promo packages and advertising. A good review from Allbooks will help you sell your book.

      Our ALLBOOKS reviewers: Anita Kuno, writer- Anita lives her tree-hugger, granola lifestyle with requisite dog, a Border Collie/ German Shepard cross-breed, in small town Ontario. Anita's enjoys reading voraciously and writing when the muse deigns to stop by for tea. Anita's reading interests include fiction, fantasy, biography, reference, and metaphysical. When writing, she just hovers over the keyboard (like a diviner) and waits to see what results - usually poetry, short stories, a short play, and occasionally, a film script.
    3. Re:I have a question by icepick72 · · Score: 1

      Dude, if you "be" an author you don't need to mail it to yourself.

    4. Re:I have a question by MythMoth · · Score: 1

      Oh, the earth shattering wit.

      In general publishers like authors to review their (other) books because they know the author is likely to have a bias in their favour. Plus they can, like, write.

      --
      --- These are not words: wierd, genious, rediculous
    5. Re:I have a question by stoolpigeon · · Score: 1

      If this is the same person - and this took place because the publisher paid for this review - then that would be worth noting somewhere in the review.

      --
      It's hard to believe that's how Micronians are made. Why don't we see it right now by having you both kiss one another?
  10. Yeah by geekoid · · Score: 4, Funny

    another person that learned database work from a book. Just what we needed.

    --
    The Kruger Dunning explains most post on /. http://en.wikipedia.org/wiki/Dunning%E2%80%93Kruger_effect
    1. Re:Yeah by yakumo.unr · · Score: 1

      The RIGHT book('s) would be fine, but they should be preaching normalization right from the get go to make damn sure the reader covers it, and is at least aware that if they don't normalize their data they will absolutely suffer. (yes sometimes you need weigh things up as another poster has mentioned, but that's part of it, and you damn well have to know about it in depth to make those judgements effectively)

      This review doesn't so much as mention normalization once, so the only conclusion can be the book is utterly rubbish, and the review is merely undeserving product placement on slashdot once again.

    2. Re:Yeah by iluvcapra · · Score: 1

      I'm about to google it, but what's database normalization?

      --
      Don't blame me, I voted for Baltar.
    3. Re:Yeah by Ndiin · · Score: 1

      And I'm going to go out on a limb and guess that this fascinating book doesn't even begin to mention things like ER diagrams, or relational algebra.

      All too often these days where even long-time DBAs don't know what relational algebra is. So sad, really.

    4. Re:Yeah by afidel · · Score: 1

      Yeah that was my thought too. Just enough knowledge to be really dangerous. Instead of using the enterprise servers costing tons of $ and maintained by highly paid, very knowledgeable professionals you get someone who's an amature that wastes tons of not quite as valuable time doing it themselves. And in the end the database(s) created by the amatures end up needing to be unraveled by highly paid developers and the same DBA's that should have handled it in the first place at the cost of many times what it would have cost to do right the first time. Obviously this doesn't apply if you're learning for the enjoyment of it or to power your own personal website, but too many times I've seen the MS Access affect in action and it costs many times more to clean up the mess than it would have to do it right from the getgo.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    5. Re:Yeah by Waffle+Iron · · Score: 1

      another person that learned database work from a book. Just what we needed.

      Well, at least it's better than learning database work from a point-n-click wizard.

    6. Re:Yeah by DragonWriter · · Score: 1

      And I'm going to go out on a limb and guess that this fascinating book doesn't even begin to mention things like ER diagrams, or relational algebra.


      But should it? I mean, sure, a database designer, administrator, or developer ought to know about relational database theory, design methodologies, normalization, etc. But is it necessary for a book on SQL to cover all that?

      The best book on database design (in terms of covering lots of ground effectively and succinctly) I've seen doesn't cover much SQL (only enough to use it to illustrate the concepts, and I'm not sure the SQL it uses is usable without modification on any real database; SQL isn't its job.)

      Why shouldn't the reverse be true? It would be one thing if the book was "Head First Database Design, Development, and Administration" and it didn't cover those things, of course.

    7. Re:Yeah by Anonymous Coward · · Score: 0

      Or, if you actually bothered to look at the book's website, you might find this blurb:

      "We all know 'Data is Power' - but we'll show you how to have 'Power over your Data'. Expect to have fun, expect to learn, and expect to be querying, normalizing, and joining your data like a pro by the time you're finished reading!"

      So much for your uninformed grousing about normalization being omitted. As an introductory book on SQL, it doesn't sound too bad. You can't reasonably expect that type of book to make you an instant expert.

    8. Re:Yeah by yakumo.unr · · Score: 1

      My post was based on the fact that even should it mention it, it clearly was not with enough impact to have caused even the slightest murmur of a mention from the reviewer, which to me, is not a good demonstration of the effectiveness of the book.

    9. Re:Yeah by nuzak · · Score: 1

      Databases don't implement the relational algebra anyway, otherwise you'd be slinging around CREATE RELATION just for starters. No one uses ER diagrams with those separate boxes for entities and relations, those went out with System R. These days you're more likely to see schema diagrams, which look more like a stripped down UML, and they're perfectly sufficient to the task.

      The book is most likely crap, but not for those reasons. DBAs incidentally are not theorists, they are sysadmins.

      --
      Done with slashdot, done with nerds, getting a life.
    10. Re:Yeah by Anonymous Coward · · Score: 0

      Take a break, it must be tiring being such a cunt all the time.

    11. Re:Yeah by Hognoxious · · Score: 1

      That might be down to her being as thick as two short planks. You know, lead a horse to water and all that.

      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    12. Re:Yeah by Anonymous Coward · · Score: 0

      it must be tiring being such a cunt all the time
      Only when I have a penis inside me... then I can squeeze my muscles and wring out every last drop of jiz...

      Oh, sorry, I just realized: you must be a fucktard Brit that's enough of a moron to use that word to describe male human beings that don't strike your fancy.

      Shut up and drink your tea like a good Limey.
    13. Re:Yeah by Anonymous Coward · · Score: 0

      Apparently you know a limited subset of DBAs. There are plenty of DBAs who mainly work on database design, not sysadmin tasks. That's what the sysadmins for the systems are for.

    14. Re:Yeah by julesh · · Score: 1

      another person that learned database work from a book. Just what we needed.

      I take exception to that. I learned databases from a book, and have never had much trouble because of it. Of course, the book in question was The Relational Model for Data Base Management by E F Codd, but still...

    15. Re:Yeah by einhverfr · · Score: 1

      I saw that in the ToC. However, I saw no reason to assume that there was actually good information about normalization in the book.

      For example, what *is* third normal form? How is it defined? You can't reasonably approach this subject without assuming that you can discuss at least basic algebra (and preferably relational algebra) with your readers. I hence got the impression that this was the non-mathematic approach to normalization which doesn't work (it is like non-math-applied physics).

      Yes, it advocates normalization (good) but I have yet to see many good beginners books that cover normalization well enough to make it understandable.

      --

      LedgerSMB: Open source Accounting/ERP
    16. Re:Yeah by nuzak · · Score: 1

      Any good DBA does database design, but I also guarantee they don't go thinking about normalization and whatnot in terms of relational algebra. They may know about it, they may have studied it, but it's still largely a system optimization problem, not unlike engineering a server or a SAN.

      I'm not saying theory is inimical to DBA work, but if you think on what the 'A' stands for, it's not a really theory-heavy job. That's the job for people who write DBMS's in the first place.

      --
      Done with slashdot, done with nerds, getting a life.
    17. Re:Yeah by einhverfr · · Score: 1

      SQL is an imperfect attempt at implementing (and demotic progression of) relational algebra. A table *is* a relation for relational math purposes. Relations can also be synthetic (result of various operations on one or more relations) and so forth. Also while some aspects of SQL allow you to break the relational model, SQL itself also implements everything you need to follow it.

      Do you need to know relational algebra to design simple database queries? No. Do you need to understand relational theory to design robust databases? Absolutely. While SQL is not perfect in its attempts at implementing relational math,

      --

      LedgerSMB: Open source Accounting/ERP
  11. overnight experts, sigh by magarity · · Score: 3, Interesting

    Prior to opening the couriered package, I had no knowledge of SQL ... Now, I can design and create databases
     
    As a database designer/developer who occasionally does DBA duties as well I initially found this quote terrifying in the extreme. But as long as this experimenting about is done on your own PC for at least the next few months, it's great that you're getting a start on a new (to you) class of software tools. Way too many people plough on using spreadsheets where they should be using at least Access. I encourage anyone with accountant or small business owning friends to pass on this review.

    1. Re:overnight experts, sigh by LurkerXXX · · Score: 2, Funny

      Basically she's just saying she's another regular MySQL user. That's already terrified me for a long time.

    2. Re:overnight experts, sigh by jayp00001 · · Score: 2, Insightful

      Can we get an AMEN here? How many of us have seen these ridiculously complicated spreadsheets users are sharing across the network that should be some flavor of database instead.

    3. Re:overnight experts, sigh by Luke+Dawson · · Score: 1

      I'm with you. It's both frightening and insulting that people think they can pick something like this up over a weekend. I don't understand why people have this idea that you can pick stuff like this up so quickly...I mean, would you call yourself a doctor just because you read a few medical books?

    4. Re:overnight experts, sigh by GameboyRMH · · Score: 1

      Way too many people plough on using spreadsheets where they should be using at least Access. I encourage anyone with accountant or small business owning friends to pass on this review.
      The problem is that people don't know how to use queries. They'd rather have a million messy spreadsheets where they can do calculations easily and have to do all kinds of copy-and-pasting, find-and-replacing nonsense than to set up a database with a few queries. And then when you finally get them onto a database, they want to use reports (or extra tables) where they should use queries :(
      --
      "When information is power, privacy is freedom" - Jah-Wren Ryel
  12. Head First Apostrope's by m1sha · · Score: 0

    >> who's photo's

    Whose idea was it not to proofread this?

    1. Re:Head First Apostrope's by Critical+Facilities · · Score: 1

      Maybe the same guy who left out the H in apostrophe? Just pointing out the irony ;-)

    2. Re:Head First Apostrope's by Anonymous Coward · · Score: 0

      Whose idea was it not?
      Not my idea, that's for sure.

      I'm more curious whose idea it was to not proofread your post.

  13. Couldn't finish the review... by MilSF1 · · Score: 3, Informative

    [pedantic mode: on]
    Had a hard time with the blurb for that matter. if you are going to mention the name of a product several times, please learn how it's written!

    MySQL
    Not mySQL. For that matter, not mySQL, MYSQL, MY-SQL, or mSQL (that's another program actually)

    It's all over their website. Something that simple will help keep you from sounding amateurish as a reviewer.
    [pedantic mode: off]

    1. Re:Couldn't finish the review... by Anita+Kuno · · Score: 1
      Thank you, MilSF1, for taking the time to point out my syntax error.

      I am grateful,
      Anita.

  14. Read the article by Anonymous Coward · · Score: 0

    The reviewer clearly states numerous times that this is a good book for an absolute beginner. Nowhere does she state that the book is to be used as a reference for a DBA.

    Me, knowing nothing of databases, would probably benefit tremendously from this book.

    Apparently all of you, would not. This book wasn't written for you. It was written for me.

    1. Re:Read the article by einhverfr · · Score: 1

      The problem is that relational databases are built around a very specific mathematical model. If you don't understand the principles of RDBMS's and at least have a basic clue about the math behind them, you will never be able to use them effectively.

      Most of the time, a lot of us end up having to clean up databases designed by programmers. A lot of the time, the programmers don't really grasp the problems inherent in ignoring the O-R Impedance Mismatch issues and so we have a lot of horrid databases out there.

      Having said this, one does have to start somewhere. All I would ask from a beginner book is at least to provide notes about the advanced topics so that people know where to look. Yet this book seems extremely light on theory (no real discussion of what the normal forms actually mean from a relational math perspective).

      Yes, you should have a reasonable grasp of at least algebra to design databases. Yes, authors should be unafraid to use terms like "functional dependency" and "transitive functional dependency." Let is stop pretending that RDBMS's are anything other than math engines.

      --

      LedgerSMB: Open source Accounting/ERP
  15. Only on slashdot by Anonymous Coward · · Score: 0

    Advertising for a vaguely sex act describing book? ('Head first', c'mon!). Slashdot is dangerously close to being spam.

  16. Re:Humorous Stick Figures!!! by megaditto · · Score: 0, Offtopic

    They got both Female AND male ones!

    --
    Obama likes poor people so much, he wants to make more of them.
  17. Because it is. by Anonymous Coward · · Score: 1, Insightful

    It's a Slashvertisement.

  18. Normalization? Keys? by Foofoobar · · Score: 3, Insightful
    Databases are a bit more than just queries. I find that most people new to databases start screwing up because thy don't understand that everything can't be stored as a varchar or that it's amazingly stupid to have every column in a table set as a key. Normalization is another big thing to knock into newbie database developer brains as well as naming conventions.

    Personally, I stand by 'Database Systems' by Connolly and Begg. Not simple, not for newbies but it coveres everything you need to know including doing ER diagrams for your structure... something every DB admin needs to do more of.

    --
    This is my sig. There are many like it but this one is mine.
    1. Re:Normalization? Keys? by ErikZ · · Score: 1

      I can see how some of those other problems could happen...but not normalizing?

      Normalization is as integral to databases as SQL. If you're not normalizing your databases, you might as well not have them.

      --
      Democrats or Republicans. They are both taking us to the same place and they are not afraid of us anymore.
    2. Re:Normalization? Keys? by Anonymous Coward · · Score: 0

      Integral to relational databases. If its not a relational database it may not be necessary.

    3. Re:Normalization? Keys? by Foofoobar · · Score: 1

      I couldn't agree more but I have seen it in every shop I have gone to; tables all over the place in second and first normal form. I consider myself lucky if 50% are in 3rd normal form.

      --
      This is my sig. There are many like it but this one is mine.
    4. Re:Normalization? Keys? by Foofoobar · · Score: 1

      Yes but maybe only 1% of shops actually use a heirarchical database... a leftover from the 1970's. Otherwise it is a flatfile system or a spreadsheet which is NOT a database. Honestly, 99% of database systems on the market and in use are relational so I don't see your point or why you are even stating this aside from a need to troll.

      --
      This is my sig. There are many like it but this one is mine.
    5. Re:Normalization? Keys? by einhverfr · · Score: 1

      That is OK....
      When we forked LedgerSMB, maybe half of the tables were in 3NF, and several tables weren't even in 1NF (as a few didn;t even have candidate keys).

      --

      LedgerSMB: Open source Accounting/ERP
    6. Re:Normalization? Keys? by suggsjc · · Score: 1

      Agree and disagree.

      I would be preaching to the choir if I tried to explain the benefits of normalization. It is vitally important and if you don't at least understand the basic concepts of what it is, then you should not go near a database (and I mean that in the nicest way possible).

      However, there are definitely times that normalization isn't necessary (but then again that can depend on your overall idea/definition of normalization). For instance having foreign keys placed in their referencing tables can speed up queries (however, you should still use triggers, etc to maintain referential integrity).

      So I was probably just nitpickng about what you really meant, as even though my case against normalization still required the foresight to understand the underlying concepts of data structures, etc.

      Just as a disclaimer. I don't support moving lookup keys as it adds complexity to the data structures, which IMHO is truly needed should be expressed by views. As always, your mileage may vary depending on your exact setup, but the performance penalty is justified by the ease of maintenance in the long run.

      --
      When I have a kid, I want to put him in one of those strollers for twins and then run around the mall looking frantic.
    7. Re:Normalization? Keys? by Foofoobar · · Score: 1
      Not really. As any DBA will tell you, by not having stuff in third normal form, you create duplication in your database. Basically, you are saying that you are perfectly fine with duplicating data rather than having relationships to that data.

      Granted in rare cases, you DO want duplication but generally this is not the case.

      And for the record, if you don't have keys, you pretty much aren't a database then; you are a spreadsheet program. Hence the name 'Ledger' SMB.

      --
      This is my sig. There are many like it but this one is mine.
    8. Re:Normalization? Keys? by einhverfr · · Score: 1

      1NF only has two conditions and only one possibly causes issues in RDBMS design. The only two reqirements are that you have a fixed number of tuple elements *and* that you have candidate keys. (I generally suggest that people consider an additional requirement which states that every tuple element is semantically atomic but technically that is not part of 1NF.)

      When you dont have candidate keys, you lose the ability to manage your data because you cannot refer to any row uniquely and this undermines any basic attempt at data management. This is not like a spread sheet (at least there you have row numbers).

      LedgerSMB 1.2 has every table meeting at least 1NF, and eventually, I expect we will get everything into good shape in the next few major releases.

      --

      LedgerSMB: Open source Accounting/ERP
    9. Re:Normalization? Keys? by einhverfr · · Score: 1

      I disagree.

      If you don't understand normalization, you can go near a database. You don't really need to understand the principle to use DML effectively (insert, select, update, delete). I would even suggest that things like VIEWS could be safely created by someone who doesn't understand good relational design provided that you know enough to know what a candidate key is and why they are important.

      However, if you don't understand normalization, you shouldn't go anywhere near database design in terms of tables and so forth.

      --

      LedgerSMB: Open source Accounting/ERP
    10. Re:Normalization? Keys? by Foofoobar · · Score: 1
      Well yes. There are times when you don't need to normalize but you need to know when you NEED to normalize so that you then know when you don't need to; normalization is the norm and the exceptions are not the norm. However your database is geared toward your business logic and the application so (for speed and scalability), you need to determine when to normalize on when not to on a case by case basis.

      And agin, in order to determine this, you first need to have an good understanding of normalization and why we normalize data.

      --
      This is my sig. There are many like it but this one is mine.
  19. I noticed the lack of theory in the ToC by einhverfr · · Score: 1

    Basically, it covers some basics of normalization, but no real background about the concepts or RDBMS's. IMO, one needs to cover, at very least, the fundamental concepts of relational math, and the mathematical definitions of SVD, FD's, MVD's, and the normal forms. Otherwise the book is actually teaching people to use RDBMS's wrong (MySQL is great at doing this too, so it is no surprise).

    --

    LedgerSMB: Open source Accounting/ERP
    1. Re:I noticed the lack of theory in the ToC by theshowmecanuck · · Score: 1

      They want to drive the car, not build it.

      --
      -- I ignore anonymous replies to my comments and postings.
    2. Re:I noticed the lack of theory in the ToC by einhverfr · · Score: 1

      In that case, if you want to drive a database, not build it, leave out the bit about DDL (create table and such). Stick with SELECT, INSERT, UPDATE, and DELETE operations (the DML statements). Include a sample database that people can practice with.

      If you want to cover the DDL, then you are teaching people how to build it and theory is therefore a good thing!

      --

      LedgerSMB: Open source Accounting/ERP
    3. Re:I noticed the lack of theory in the ToC by DragonWriter · · Score: 1

      They want to drive the car, not build it.


      I think it would be more accurate to say they are teaching how to (among other things) build it, but not how to design it.
    4. Re:I noticed the lack of theory in the ToC by Anonymous Coward · · Score: 0

      I think in an ideal world you are absolutely right. No Question. However in the real world of software projects, we live in a world of good enough. Getting something perfect or even excellent is asymptotic. You have to spend ever increasing amounts of time (ergo money) the closer you get to perfect. Since you are making no money from your product while you are designing and building it you need to reduce this time period. So instead you design something that is pretty good instead of excellent and can release it to begin bringing in revenue. Doing it this way you can start making money within the 80 of the 80/20 rule as applied to the excellent design. That is you will be making money while the excellent design still finishing the 'easey' stages and gets bogged down in the last 20% of the project that takes 80% of the time. Eventually you will be enjoying your profits while the excellent product causes the company to go bankrupt. So in this regard, you only need people who can design databases pretty good as long as it is done quickly. These people are more numerous besides, and cost less money than those who have advanced math degrees in set theory etc. On the rare occasion there might be a project that requires the database to be designed absolutely perfectly to begin with, is completely normalized, and the parts that aren't are really de-normalized... meaning they actually were normalized to begin with and performance concerns were considered. But in many years experience in real projects I personally have yet to see this. Meanwhile I have seen many projects fail because they wanted to be excellent before releasing the software. In software as in many areas of modern life, it is better to start making some money and keep your company profitable by releasing a good enough product than bankrupting them shooting to make something perfect. You may hate this example, but there is a reason Microsoft releases crap and fixes a lot of it with the first couple service packs. It keeps them in business. Granted there are exceptions to the rule like software for aviation or medical applications. But in the vast world of software these are the exceptions not the rule.

    5. Re:I noticed the lack of theory in the ToC by einhverfr · · Score: 3, Insightful

      IMO that sort of thinking is a mistake. It actually comes from the desire to cut down on planning time because management sees it as dead weight. And worse, people designing databases who have no clue what they are doing mathematically speaking.

      In general, I have found that every hour of planning time spent tends to eliminate up to 10 hours of coding, and often as much as 100 hours of pre- and post-release re-engineering and bug fixing.

      The goal ought to be to optimize time and expenses across the entire software lifecycle rather than cutting down on the most important places where time gets spent (on the design). This generally means spending more time on design, less on buzzword-compliance, and less on actual coding. If you do it right, testing and debugging effort go *down* as well.

      Instead people end up with bloated monstrosities when better-designed products could have been built with less time an money.

      --

      LedgerSMB: Open source Accounting/ERP
    6. Re:I noticed the lack of theory in the ToC by jadavis · · Score: 1

      The goal ought to be to optimize time and expenses across the entire software lifecycle rather than cutting down on the most important places where time gets spent (on the design).

      Agreed 100%.

      I'd like to add that the data the application is generating is often very valuable to the business. The costs of a bad database design are not apparent until you actually try to read the data and decipher some kind of meaning from the data as a whole. Often, the database design is so bad that the information is simply never extracted, because the data is too meaningless.

      There's a natural tug-of-war between those who want to get the release out the door, and those who want to be able to make use of the data it generates later on. It's much easier to simply insert whatever data the application is given rather than to detect that it is wrong, throw and error, and allow the user to correct it. But that's exactly what should be done with data in order to effectively report on it later.

      --
      Social scientists are inspired by theories; scientists are humbled by facts.
    7. Re:I noticed the lack of theory in the ToC by einhverfr · · Score: 1

      There is a second point too that I suppose I should have addressed. That is that often organizations have trouble designing software because personal preferences get in the way of solid engineering. How many times do you hear "we have to use XML!" or some other technology solely because it is hot and not because it is useful? Consequently a lot of design time ends up being poorly used because engineers are trying to add things to placate management rather than remove things to make the design more maintainable.

      BTW, one of my latest approaches is a methodology I call SODA (Service Oriented Database Architecture), which suggests that the object model of the application and the relational database should be designed as a loosely coupled system, connected discoverable stored procedures which can be semantically integrated into the object models. This way your relational design is only loosely coupled to your object structures, but the data manipulation logic is re-usable with other applications, and so forth. Think of an ORM which does procedureprocedure rather than data structure mapping. It also ensures only a loose coupling between logical and physical programming structures. (Of course as with all tools, it is not to be used everywhere-- it is only useful in solving the O-R Impedance Mismatch.) However, I am still developing best practices for this approach....

      However, an approach like SODA allows you to forget about the needs of the application temporarily and focus on good DB design, and then later create a robust business logic interface between the application and the db which can be re-used in other applications (even if they are in other languages). It also allows for easier app development because the object interface largely becomes a lighter-weight automation mechanism.

      --

      LedgerSMB: Open source Accounting/ERP
    8. Re:I noticed the lack of theory in the ToC by jadavis · · Score: 1

      BTW, one of my latest approaches is a methodology I call SODA (Service Oriented Database Architecture), which suggests that the object model of the application and the relational database should be designed as a loosely coupled system,

      That is effectively moving the entire "model" part of MVC into the database. That's not a bad approach, and there are a lot of reasons I like it. I think you still need to offer a way to write arbitrary read-only SQL queries in the application; that's just too valuable to give up.

      What you gain from SODA can usually also be gained by defining tables and their constraints well, and just leaving the model in the application.

      --
      Social scientists are inspired by theories; scientists are humbled by facts.
    9. Re:I noticed the lack of theory in the ToC by theshowmecanuck · · Score: 1

      I think that is where theory and reality come into conflict. You may have designed something really nice, but if the company goes broke because you have spent so much time designing and not delivering product, what's the point? Nothing gets released. So yes, I believe a good design saves time later, but at what cost? You may not have to worry about paying the bills, but the evil people in management do. If they spend all the money on paying the people to design, there won't be any left to code, test, and bug fix, and then re-design when the business decides they want it to do something slightly different. And that will happen as surely as water flows downhill. :)

      After working on enough enterprise projects I have also become convinced that there is more than a little insight and truth when it comes to agile design techniques. I really do hate buzz word laden 'speak'. But I have seen requirements ebb and flow and change as 'the business' realizes what they asked for at the beginning of a 2 to 5 year project is different than what they need, or that they need more than what they asked for. And this only happens when they see the software in action, so the sooner that happens the faster the requirements are resolved. I have worked all areas of the project from the back back end to dealing with upper management. This is from the school of hard knocks from which I speak. I do believe that at each stage there has to be a good design. I do believe requirements and high level design are required (right down to the interfaces and data models), and they need to be actually documented (unlike agile design principles where documentation is the code and a few jpg's of white board design sessions). But I no longer believe we should take it to the n'th degree.

      --
      -- I ignore anonymous replies to my comments and postings.
  20. Talk about rewarding!!!! by syousef · · Score: 0, Offtopic

    If we got head first before writing SQL, maybe the quality would increase. No on second thoughts scratch that. Who'd give a shit about coding SQL if they just gotten head.

    --
    These posts express my own personal views, not those of my employer
  21. You've not done real database work by tttonyyy · · Score: 1

    ...until your carefully crafted union of two huge tables fails, taking down a mysql server common to over 400 sites and incurring the wrath of your previously friendly hosting company.

    Mental note - test locally first.

    --
    biopowered.co.uk - catalytically cracking triglycerides for home automotive use since 2008. Just say no to big oil!
    1. Re:You've not done real database work by afidel · · Score: 1

      If you were doing real database work on a well run DB you wouldn't have been able to take the DB down =) Real DB's have resource limiters that allow the DBA to insure that no one user can exhaust resources to the point of taking the DB down. We even limit the percentage of system resources a user can take just to make sure that one bad report doesn't slow down OLTP processing. I'm not the DBA but I know enough to know that there are toys and then there are real business tools.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    2. Re:You've not done real database work by tttonyyy · · Score: 1

      If you were doing real database work on a well run DB you wouldn't have been able to take the DB down =) Real DB's have resource limiters that allow the DBA to insure that no one user can exhaust resources to the point of taking the DB down. We even limit the percentage of system resources a user can take just to make sure that one bad report doesn't slow down OLTP processing. I'm not the DBA but I know enough to know that there are toys and then there are real business tools. Indeed. This was a mysql database that I had previously tested long queries on. I was monitoring the progress of the query when the server went unresponsive. All hell broke out from there.

      --
      biopowered.co.uk - catalytically cracking triglycerides for home automotive use since 2008. Just say no to big oil!
    3. Re:You've not done real database work by einhverfr · · Score: 1

      You don't do real database work on MySQL.
      You haven't done real database work until you report an original bug in PostgreSQL.

      --

      LedgerSMB: Open source Accounting/ERP
    4. Re:You've not done real database work by einhverfr · · Score: 1

      BTW, the one original bug I reported in PostgreSQL was back in 7.x, and involved ways of building tables so that they were write-only (i.e. the db server couldn't read them). Had to do with handling tuples as attributes in tables.

      --

      LedgerSMB: Open source Accounting/ERP
    5. Re:You've not done real database work by Monkey · · Score: 1

      You don't do real database work on MySQL. Tell that to the guys who run Slashdot.
    6. Re:You've not done real database work by einhverfr · · Score: 1

      Light-weight CMS is not "real database work" regardless of traffic volume. Heavy-weight CMS could be (i.e. tracking legally mandated approval processes for engineering designs for, say, a hydroelectric dam) but it is hardly the same thing.

      For "real database work" you need at least moderate volume and at least a moderate degree of semantic complexity. Lightweight CMS does not provide the latter.

      Real database work is building an accounting database for a 150+ employee organization.

      --

      LedgerSMB: Open source Accounting/ERP
    7. Re:You've not done real database work by GooberToo · · Score: 1

      Didn't they convert to DB2 years and years and years ago?

    8. Re:You've not done real database work by Monkey · · Score: 1

      They allude to using MySQL in The History of Slashdot Part 2".

    9. Re:You've not done real database work by GooberToo · · Score: 1

      If memory serves, I believe they converted to DB2 on their backend. I believe SF was converted too. Of course, my belief doesn't make it so.

  22. I've used that book by Elenthalion · · Score: 1, Informative

    Boy, that review sure does sound like a shameless o'reilly sponsored plug for the book. And all the negative banter is so very /.. If it's directed towards beginners, /. will roast it. All that aside, I've actually read and enjoyed this book.

    I took some DB classes in college and used SQL quite a bit (albeit nothing that complex) in my work for a few years afterwards at a software company. I wasn't a dev or a dba or anything like that so my rudimentary skills were good enough for the job. Several months ago I decided that I wanted to firm-up on the SQL fundamentals that had grown rusty since college before I tackled a more intense book/online learning method. I'd had great experience with another book in the HeadFirst series so I picked this one up too.

    Let me tell you, this book is gold. Though as other posters have said, it isn't anywhere near a comprehensive book that a DBA or SQL coder would be even remotely interested in, but that's not the point. The point of the book is to help newbies (or rusty-people) (re)establish their SQL fundamentals so that they can move on to more complex/cooler stuff. This book does that job very, very well. The examples are fun and they way they engage the reader keeps even the most un-techy person involved while at the same time not insulting the intelligence of any who does consider themselves tech saavy, just SQL ignorant. Granted, anyone who thinks they're a SQL master after reading this book really has no idea what they're talking about and probably has never really looked at a production DB and the code behind it.

    If you or anyone you know is looking for a good entry level SQL book, then this would be a great place to start.

    1. Re:I've used that book by einhverfr · · Score: 1

      First, a lot of the negative banter comes from those of us who do database engineering and understand how technical of a field it is. Of course, if it is limited to MySQL, this is not a big issue because you can't do proper db design on MySQL anyway.

      I guess my feeling is that it would be great if beginner books at least discussed theory, at least in appendix. I.e. "Here is the basis of how this works, and here is where you can go to get more information" or "Here are a few known challenges you may run into. Here is where you can go to get more information."

      However the fact is that no beginner books do this, which means that those of us who do the engineering end up doing a lot of unnecessary cleanup. We all know you have to start somewhere, but it would be nice to have somewhere *good* to start.

      --

      LedgerSMB: Open source Accounting/ERP
    2. Re:I've used that book by Elenthalion · · Score: 0

      Absolutely agreed. If I were a DB engineer I'd have the same frustrations.

    3. Re:I've used that book by DragonWriter · · Score: 1

      I guess my feeling is that it would be great if beginner books at least discussed theory, at least in appendix.


      IME, there are beginner's books that discuss theory, etc., but they are, surprisingly enough, beginner's books on theory rather (e.g., Relational Database Design Clearly Explained) rather than beginner's books on SQL, or particular software stacks (like the various MySQL/Apache/PHP or similar intro books.)

  23. I would add by einhverfr · · Score: 1

    So far, I have almost always found heavily normalized designs are almost always a technical win when looking at future needs etc.

    Note I am talking about normalization as a mathematical process based on data domains, functional dependencies, etc. This means building a database which is mathematically and semantically solid rather than working on program requirements (i.e. the structure of the data in the db should *not* be based on the program's data structures but rather on the inherent internal structure of the information).

    --

    LedgerSMB: Open source Accounting/ERP
    1. Re:I would add by Ed+Avis · · Score: 1

      Agreed, and never mind future needs, just for current ones having a normalized schema is the way to go. There isn't really any tradeoff between normalization and complexity. So far, every schema I've seen that was designed by some cluebie who decided to duplicate data 'to make it run faster' has ended up making code much more complex, because the same data is in several places and you have to remember to update all of them and what do you do if it gets out of sync (as it will)?

      Granted, if you have at least five years' beard growth and experience with serious-sized databases (not a just few thousand records here and there) then you can denormalize it. Normally just for one thing, in one or two tables, and if there's a clear performance need you must meet.

      --
      -- Ed Avis ed@membled.com
    2. Re:I would add by einhverfr · · Score: 1

      Also, I am not sure that summary data always means denormalization. Normalization definitions in relational algebra doesn't seem to address questions of values which could be calculated from other values in a set (except where functional dependency is an issue) though obviously good engineering practices would keep these at a minimum.

      For example, suppose we have an accounting application which accepts hundreds of thousands of invoices per year. After 10 years, we want to go find the balance of one business checking account. Processing an aggregate over ten years and millions of invoices is likely to be inadequate to the business need.

      In that case, my proposed solution is to have summary data at checkpoints. I.e. "last time you closed your books, the balance was $x." Now we still have to run an aggregate but it is only an average of six months data, and most of that is probably clustered together on disk. This is an atomic fact, it does not overly complicate data management, and it is a heck of a lot better than trying to keep a summary table up to date.

      --

      LedgerSMB: Open source Accounting/ERP
    3. Re:I would add by Ed+Avis · · Score: 1

      That's a good plan but it should be possible, whenever you want, to delete everything in the summary balance table and have it recalculated the next time it's wanted. Otherwise when you correct an error in an older journal the summary would then be incorrect.

      I'm not saying that you really would delete all summaries, just that this is a good criterion for robustness of the system and shows it is always able to get back in sync.

      --
      -- Ed Avis ed@membled.com
    4. Re:I would add by Hognoxious · · Score: 1

      Otherwise when you correct an error in an older journal the summary would then be incorrect.
      IANAA, but I don't think you should be doing that anyway.
      --
      Confucius say, "Find worm in apple - bad. Find half a worm - worse."
    5. Re:I would add by Ed+Avis · · Score: 1

      It depends - accountants have odd requirements and often want to correct older things, except when they don't. After all, data entry errors do happen, and if you spot a mistake a week later, what are you going to do about it? Either you fix the original journal so you now have a correct picture of your finances, or you must resort to some bizarre workaround.

      --
      -- Ed Avis ed@membled.com
    6. Re:I would add by einhverfr · · Score: 1

      IANAA either, but I have to know how these things are supposed to be done. Hence I have discussed this issue with CPA's in order to ensure I understand how adjustments to closed periods are supposed to work.

      You have a point that one should be aware that people sometimes do things wrong and guard against that (for example, by using custom triggers/check constraints to ensure that inserts don't occur in closed periods, nor do updates/deletes *ever* occur outside of a few specific issues such as voucher approval/deletion).

      However, here is how the correction process is supposed to work: The correction is supposed to be posted to the first open date in the books. Note that this does not affect income tax requirements (and you could have to go back and restate earnings) but for the purposes of financial accounting, unless a systematic error is made, adjustments are made to an open period. If a systematic error is made, it is going to be invasive to fix anyway so having to go in and rebuild the summary data when you are done is not a bad thing.

      There is one other case that causes a problem. Suppose you have an open voucher (i.e. recorded transaction which has not been fully posted to the books) which remains open for several years (I have seen this happen). In these cases, one would also need a flag to show that a transaction had been used in the summary. Such vouchers pose other issues for financial accounting and I think that this is a bad practice but some businesses do have strange requirements of this sort.

      So it is more complex that one would think, but it is still doable.

      --

      LedgerSMB: Open source Accounting/ERP
  24. People like this keep my billable hours up by VampireByte · · Score: 1

    I hope it never ends! Keep those "database expert in 24 hours" books coming, they're the locomotive to my gravy train.

    --

    Run and catch, run and catch, the lamb is caught in the blackberry patch.

    1. Re:People like this keep my billable hours up by B3ryllium · · Score: 1

      Well-said. Now if only I could find a few local freelance contracts to clean up those messes :)

      Also, I wish I could do a quick :%s/mySQL/MySQL/g on this entire page. :)

    2. Re:People like this keep my billable hours up by psyclone · · Score: 1

      And I wish I could do a quick: s/MySQL/PostgreSQL/ig on this entire page.

    3. Re:People like this keep my billable hours up by Anonymous Coward · · Score: 0

      Then people would be saying horrible things about PostgreSQL instead of MySQL. Only they wouldn't be true, horrible things anymore.

      Is that what you really want?

    4. Re:People like this keep my billable hours up by cerberusss · · Score: 1

      *laughs* Let the flame war begin

      --
      8 of 13 people found this answer helpful. Did you?
  25. Well, you have to start somewhere by einhverfr · · Score: 1

    We learn by doing but we can't do unless we understand the syntax.

    Additionally, I would highly recommend Codd's Papers, and CJ Date's books on the subject. These will help to provide a theoretical framework for understanding what an RDBMS is all about.

    --

    LedgerSMB: Open source Accounting/ERP
    1. Re:Well, you have to start somewhere by ClosedSource · · Score: 1

      Given that most commercial RDBMS weren't designed to follow the relational model, I don't think it's accurate to say that it provides a framework for understanding what a RDMBS is. It's a bit like saying that you can't perform simple arithmetic without a deep understanding of number theory.

    2. Re:Well, you have to start somewhere by einhverfr · · Score: 1

      Actually, I think that Codd made a few mistakes as well in the relational model. While these seem like minor mistakes and should be put in the perspective of the fact that Codd founded the field (so of course there were going to be some oversights that need to be addressed later), they haunt the industry to this day. Chief among them is the definition of NULL which introduces semantic ambiguity into databases.

      For the most part, SQL is an imperfect approach at writing relational algebra in plain English. So just because the databases of today are not perfect implementations of relational math doesn't mean that they don't follow the relational model.

      --

      LedgerSMB: Open source Accounting/ERP
  26. Head first in general by marqs · · Score: 1

    I personaly loved Head first Java when first starting with java programming. These books are not "The in depth" kind of books nore are they any good as reference literature. But stil they push the information through in an humorous way. Meaning you learn not knowing that you are learning!

    1. Re:Head first in general by DragonWriter · · Score: 1

      These books are not "The in depth" kind of books nore are they any good as reference literature. But stil they push the information through in an humorous way. Meaning you learn not knowing that you are learning!


      If I'm going to shell out money for a book to learn something, why would I object to knowing that I'm learning?

      And, if I'm going to shell out money for a book to learn something, why would I not prefer something that is either in depth, useful for reference, or both, especially given that the Head First books often aren't substantially cheaper than books covering the same topics which meet at least one of those two criteria?
    2. Re:Head first in general by C0rinthian · · Score: 1

      Perhaps because the more in-depth book provides information overload to the reader, or is so dry, they lose interest? Perhaps a book like this is good to get a basic grasp on the material, making those in-depth books more useful to the reader?

      I don't have coding experience, but I DO have education experience. There is most definitely a place for books like this, as long as the reader is aware that it is not a end-all source of information about a subject.

  27. Head First books are a good introduction by satori101 · · Score: 1

    As an introduction to a given topic, I've been pretty satisfied with the quality of O'Reilly's 'Head First' series. They're not meant to be an exhaustive reference for seasoned pro's, but they do a good job of conveying the fundamentals. If this book is on par in quality with the rest of the series, it's probably not a bad place to start if you're approaching it with zero background in databases.

  28. Not the most imformative review by ChrisA90278 · · Score: 1

    I wonder if this book covers what's really importent. How to design systems that use databases. I've seen way to many system designs where the DBMS is grossly abused. For example to self-educated programer did not know about "joins" so he searches one table, holds the value in a variable andthen looks it up in a related table. Of corce he also does not think about locks, deadlocaks and transactions. You be surprized to see how common this is. I've seen tables design be people who must have never read about "normalization".

    What I wonder what I see a review done by some one who knows nothing of the subject is if the reviewer knows what he does not know. Would be know that a book as just teaching surface level syntax and avoiding the more importent issues?

    1. Re:Not the most imformative review by einhverfr · · Score: 1

      Take a look at the SQL-Ledger schema sometimes.

      No normalization (some tables are not 1NF).
      No RI enforcement.
      No NOT NULL enforcement in critical areas (chart_id is NULL. Where did the money go? UNKNOWN!)
      Ambiguous foreign keys (as in a foreign key that references any of a number of possible tables)
      Dangerous abuse of data types (double precision floats for storing money)
      Using custom triggers where ON DELETE/ON UPDATE events and foreign keys would be better

      --

      LedgerSMB: Open source Accounting/ERP
  29. Perfect for a certain group by Hashi+Lebwohl · · Score: 2, Interesting
    I'm reading a lot of negative comments about this book, maybe that's to be expected due to the technical nature of /. readership.

    However, as a DBA and DB dev myself, I know one person that I am personally going to buy this book for, maybe as a Christmas present.

    My boss, of course! I spend hours per week trying to explain to him why I do things certain ways. This is because he has a slight technical background in SAP, and has just enough knowledge to be dangerous. I would love for him to read this book, it may save me some agro.

    --
    I'm in to sadism, bestiality and necrophilia. Am I flogging a dead horse?
  30. No, THIS is an ad for the book: by spun · · Score: 5, Funny

    Head First! Apply directly to the SQL!

    Head First! Apply directly to the SQL!

    HEAD FIRST! APPLY DIRECTLY TO THE SQL!


    Okay, I didn't say it was a good ad for the book...

    --
    - None can love freedom heartily, but good men; the rest love not freedom, but license. -- John Milton
    1. Re:No, THIS is an ad for the book: by jcuervo · · Score: 1
      --
      Assume I was drunk when I posted this.
  31. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  32. I'm not a fan of the Head First series by LorenzoV · · Score: 1

    JMHO.

    I bought Head First Design Patterns a while ago as my introduction to design patterns. It must be me by I thought the writing a bit condescending. It seemed to presume I had a learning disability of some sort that they had to take extraordinary steps to over come. I found it difficult to get by the verbosity and reiterative style. I've browsed others in the series with the same impression.

    After giving up on Head First Design Patterns, I acquired Gamma, et al, "Design Patterns ...". This suited me better. Direct, to the point.

    Do others perceive the Head First books as I did? Am I over reacting to the authors' intent to address different learning styles?

    1. Re:I'm not a fan of the Head First series by ravenlock · · Score: 1

      I had the same experience with the same book. It's not that I dislike the content, it's just that this particular method of delivery bores me to tears. I can see how it *might* suit somebody else, but I think that's going to be the last Head First book I'm buying for myself.

  33. Head first! by gringer · · Score: 1

    Apply directly to the forehead!

    --
    Ask me about repetitive DNA
  34. I really hate these kind of books by Splab · · Score: 1

    Yes people will be able to use a database quickly, but do we want them to?

    Most people I have seen using a database have not had any understanding of what they where doing and it was basically and advanced filepointer. I have seen a lot of people using MySQL with MyISAM and happily thinking they got a consistent dataset. I have seen people using databases for communication between servers and using stuff like a time stamp for identifying a row (time stamp generated on local server).

    Leave databases to people who understands them!

    1. Re:I really hate these kind of books by DragonWriter · · Score: 1

      Yes people will be able to use a database quickly, but do we want them to?


      Yes. Because you don't get to real understanding until you can start using them.

      The problem, of course, is people developing databases that you have to later work with before they've gotten enough understanding, but that's going to keep happening in any case. In fact, there will be more of it if you narrow the field of people with even a basic understanding of the field. (If its not bad databases, per se, that get built this way, it'll be people abusing other technologies to do what should be done in a database, which will be just as bad, if not worse, when you run into it.)

      As long as there is something that lots of people need done, and a few people understand really well and are paid well in good jobs to do, there will also be people who understand it less well, and are scrabbling by doing it for as a side part of another job, for a smaller employer, as a lower-priced contractor, etc. And, yeah, they'll be doing lower quality work. Some of them will go on to be experts. Some of them won't.
    2. Re:I really hate these kind of books by Splab · · Score: 1

      I don't mind people with less experience working on them, in fact I find it appalling that only people with 100 years of experience should touch it - I do however expect people to have at least a basic understanding what computing is and why ACID is very important.

    3. Re:I really hate these kind of books by jc42 · · Score: 1

      ... I find it appalling that only people with 100 years of experience should touch [SQL] ...

      Well, on a number of projects, I've often wished that they'd restricted the DB part to people who had 100 years of experience with it. That would have solved the DB problems we had quite handily.

      I do however expect people to have at least a basic understanding what computing is and why ACID is very important.

      Most of us who survived the 60s understand this. Timothy Leary taught us well.

      --
      Those who do study history are doomed to stand helplessly by while everyone else repeats it.
    4. Re:I really hate these kind of books by einhverfr · · Score: 1

      I think that one of the problems is that you can't approach database design like programming in terms of logical structures. This is especially true when trying to do OO programming against RDBMS's. Hence if you don;t teach people theory, they build bad databases because they approach relations like classes (which they clearly are *not*).

      Yes, theory is extremely important. If you don't have good theory both in the DML and DDL side, you are going to run into problems. But these are not extremely difficult concepts-- they are just not taught.

      I used to provide tech support for MS Access at Microsoft. I could tell you some stories....

      --

      LedgerSMB: Open source Accounting/ERP
    5. Re:I really hate these kind of books by einhverfr · · Score: 1

      Most of us who survived the 60s understand this. Timothy Leary taught us well. And a few of us have experience cleaning up db's which are ACID-compliant in this way.....
      --

      LedgerSMB: Open source Accounting/ERP
  35. MOD PARENT.... by toadlife · · Score: 1

    ....troll/insightful/informative/flamebait

    AKA, 'trollsiformabait'

    --
    I don't always use unix-like operating systems; but when I do, I prefer FreeBSD.
  36. buy me... by Anonymous Coward · · Score: 0

    seriously, buy me now. you know you want to. c'mon. do it or you will never be what you want to be. buy me.

  37. Re:Don't get in over who's job... by Anonymous Coward · · Score: 0

    just because you didn't "pick it up" in 3 days doesn't disqualify everyone else.

    as long as keep those bloated dbs running you'll have a job, just don''t tell anyone, just say what they don't know won[t hurt them as long as they have you and you'll be the "magic dba" that drives in your porsche at 2 p.m.

    do you guys have offices with a window yet? i bet you do. ;)

  38. empowering by bugs2squash · · Score: 2, Insightful

    I saw this book a Borders and have recommended it to the Network Support Technicians at my company. These guys run our helpdesk and often refer basic questions about network performance to me. I've created a bunch of systems that store data for reports in mysql (current status, roundtrip response time, throughput, usage etc.). People are often amazed that I'm able to produce ad-hoc charts and tables about all sorts of aspects of the network's well-being. All I'm doing is simple queries on simple data and if this book helps others in my organization to query the data in even the most basic way, it will have been well worthwhile.

    I find that more rigorous books sit on the shelf and never get read. These guys don't want to be DBAs or to design a database, they just want to be able to find out simple information.

    I want to encourage them to at least start into this field, not just because it's career-expanding for them, but also because the more these tools get accepted, the less grief I'll get from management for implementing in-house the things we needed in the first place.

    --
    Nullius in verba
    1. Re:empowering by steogede · · Score: 1

      I find that more rigorous books sit on the shelf and never get read. These guys don't want to be DBAs or to design a database, they just want to be able to find out simple information. I want to encourage them to at least start into this field, not just because it's career-expanding for them, but also because the more these tools get accepted, the less grief I'll get from management for implementing in-house the things we needed in the first place. I can empathise with that. I doubt Head First SQL will make anyone a DBA (I haven't read it so I can't say for certain). However, if (as you say) it can give someone enough knowledge to understand how useful an SQL database can be, especially compared a spreadsheet, that has to be a good thing. After all, SQL was intended for 'regular business people' (albeit at a time when user-friendliness was an unknown concept). I will definitely give it a read (assuming it is available on Safari). I can definitely think of some people who could benefit from it, and I know that they wouldn't ever think of attempting to read 'Database Systems'. Just going off on a tangent, the biggest problem with SQL (IMHO) is it's attempt to use a natural English-like syntax rather than a logical, sensible syntax. I reckon the inefficient woolly overly verbose syntax of SQL is the number one reasons why so many computer scientists have such a poor understanding of relational database theory (as is often/usually the case) - they take one look at SQL and decide that anything that to do with RDBMs should be avoided like the plague and start coding their own flatfile data structures using C.

  39. Depends on what the Db Is For by Anonymous Coward · · Score: 0

    Well Normalization is fine for OLTP DB's but if is more OLAP style then Normalization is less of an issue in the design.

    As someone who has been thrown in at the deep end of DB design in the past Normalization only becomes an issue when you have to build something big and complex from scratch - small stuff ( a few K's worth of records ) aren't an issue; you can rebuild, you have the technology. Adding to something already exisitng you should tend to follow the conventions of the system - even if they are awful.

    Expecting a newbie to be perfect from reading a 'intro' book is daft. Yes they can build and design databases , but they never said they would be future proofed or perfect .

    They do give someone the confidence thats its not beyond them and with time and experience they'll be on here banging on about normalization , keys ,RMDB design and all the other stuff with the rest of the herd.

    1. Re:Depends on what the Db Is For by einhverfr · · Score: 1

      Maybe but not always. It is true that people often denormalize OLAP systems because they are trying to get specific answers out fast so summary tables/materialized views make sense. Ask a new question nobody has built summary tables for and expect to wait....

      However, this is not always the case. If you look at a lot of OLAP setups on BizgressMPP or Terradata, there isn;t a lot of denormalization necessary because you can address the issues via parallelism rather than summary storage. This is important because it means your OLAP solution is able to answer a far wider range of questions quickly.

      --

      LedgerSMB: Open source Accounting/ERP
  40. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  41. Head First Books... by bozone · · Score: 1

    ...are generally aimed at those new to { insert book's technology topic } and not seasoned programmers / developers / architects.

    Many of the comments so far are negative, doubting how someone can become a data architect / DBA from the book... which is not the target audience... IMHO

    As one who has seen quite a few programmers use unstructured text files, excel spreadsheets and access (as if it were a spreadsheet) for data storage, I welcome a resource that offers a painless introduction to the "magic" of using a database and the various features it offers. This introduction to the "proper" way to manage data may be the stepping stone to spur further learning...

    --
    "Hatred is the coward's revenge for being intimidated" ...George Bernard Shaw
  42. Comment removed by account_deleted · · Score: 1

    Comment removed based on user account deletion

  43. Ass-First DB design by Tablizer · · Score: 1

    IMHO Creating a database is one thing, Designing is another entirely! Making DDL scripts to run in the database is easy once you learn the syntax. Knowing their interaction...and planning their future growth is a completely different set of skills that's only gained with experience with your data.

    I'm thinking of creating the Ass First series of books. Motto: When you need to fake it really fast!

  44. Re:Humorous Stick Figures!!! by Tablizer · · Score: 1

    [stick figures] They got both Female AND male ones!

    Don't laugh, there's also Lego porn. (Hmmm. My Lego set never had that long part.)

  45. ORM by Anonymous Coward · · Score: 0

    Why work with SQL when you can work directly with objects?

    1. Re:ORM by einhverfr · · Score: 1

      Because ORM's suck and generally promote bad db design.

      You may find my posts about SODA interesting. It is a different concept to fill the same need but allows you to build *good* relational databases without the complexity of maintaining a lot of SQL code in your object classes.

      --

      LedgerSMB: Open source Accounting/ERP
  46. Extreme Programming by Anonymous Coward · · Score: 0

    When writing, she just hovers over the keyboard (like a diviner) and waits to see what results - usually poetry, short stories, a short play, and occasionally, a film script.

    And the occasional high quality, commercial grade database I presume.

    Man, isn't this way *beyond* rapid app dev? This chick is far out! Or working at IBM on Notes?

  47. Please include reviewer's background by GreggBert · · Score: 2, Interesting

    It would be helpful to include your own background when doing a review. While I know not everyone works with SQL every day, it might help to put the review into context if we knew what level of technical or development experience the reviewer had. It would make it easier to possibly recommend the book to others if we knew what background the reviewer had in relation to those we might possibly recommend the book to.

    --


    If you don't understand anything I post, please accept that I ate paste as a small boy...
  48. UPDATE by Anita+Kuno · · Score: 1

    USE slashdot;
    SELECT string FROM head_first_sql_book_review
    WHERE string = 'databases';
    START TRANSACTION;
    UPDATE head_first_sql_book_review
    SET string = 'an instance of a database using the MySQL CREATE DATABASE command'
    WHERE string = 'databases';
    COMMIT;

  49. Make sure you study ALL the normal forms by HornWumpus · · Score: 1

    Especially the ones above third, they are very, very useful and are all vital to a good database design.

    Note: This post might contain sarcasm, you decide.

    --
    John McAfee 'It was like that time I hired that Bangkok prostitute; to do my taxes, while I fucked my accountant'
    1. Re:Make sure you study ALL the normal forms by einhverfr · · Score: 1

      I find 4NF to be largely useless for actual work but it is extremely important for understanding normalization.

      I would argue that the 2 most important normal forms are BCNF and 5NF. Both of them are above 3NF.

      --

      LedgerSMB: Open source Accounting/ERP
  50. SQL Exercises by Anonymous Coward · · Score: 0

    What about learning SQL online?

  51. i sure by wholecake · · Score: 0

    wish they had a head first python book, that would help.

  52. SQL's easy; DBA's much harder by billstewart · · Score: 1
    It's easy to learn basic SQL, at least if you've got a reasonable computer background. About 15 years ago we needed a database for a project, and somebody in the department had a copy of Informix around so I picked up the manual and was able to build a schema for my project and do reasonable queries within a day. I tried the same with Sybase, which one of the projects we'd be interconnecting with used, and it was a total swamp, with a stack of manuals as big as VMS's, and never was able to get anything useful built in the time I had available.


    Of course, my department decided that they were too cheap to pay $5K for another Informix license for my project, much less the $10K or $20K that Sybase cost, so I ended up rebuilding the project out of the old Unix join, sort, and look commands.

    --

    Bill Stewart
    New Fast-Compression-only CPR http://preview.tinyurl.com/dy575ks
  53. Good point by einhverfr · · Score: 1

    If the goal is to make people competent consumers of database applications, and users of predesigned databases, the book cannot do any harm and will certainly do some good.

    "I read one book and now I can design databases for paying customers" is a very different issue.

    --

    LedgerSMB: Open source Accounting/ERP
  54. Out of curiosity by einhverfr · · Score: 1

    Why are you starting a transaction for a single update statement? Normally transactions are required for grouping multiple insert/update/deletes so that they succeed/fail as a unit or for grouping SELECT ... FOR UPDATE; with the related update so you know your information is current.

    Also, I would *highly* suggest getting a good book on db design. Chris Date's "An Introduction to Database Systems" may be too heavy for you, so I would start with some reading on relational algebra and the mathematical (rather than dictionary) definitions of the normal forms.

    --

    LedgerSMB: Open source Accounting/ERP
    1. Re:Out of curiosity by Anita+Kuno · · Score: 1

      Are you genuinely curious? Or is this another opportunity for condescension?

      You seem able to be generous, astute, and helpful judging from your posts on this forum and others.
      If that is your motivation, I would be grateful to benefit from your superior knowledge of this subject. Thank you.

      You also seem to have the ability to be malicious and confrontational.
      If that is your motivation, organize the group, there seem to be a lot of you,
      though they seem to lack for a leader at present, and design your logo.
      I'll be speaking with the people who have something useful to share.

      Which behaviour would you like to direct towards me?

      I'm curious,
      Anita.

    2. Re:Out of curiosity by einhverfr · · Score: 1

      Ok, I will admit to be a bit confrontational/argumentative in the parent post. The major motivation is to try to get some idea for how well you understand transactions after reading the book, i.e. if there is a conscious choice here involved, or just a rule that all writes should occur inside transactions (which they do anyway). I am not being malicious but sometimes people are better able to show their knowledge in a confrontational environment.

      BTW, I guess the question I would have for you is where you want to take your db knowledge. Assuming you want to do db design, and are familiar with application development, I would suggest getting some good books in that area first, or at least get on appropriate email lists where you can challenge your knowledge and expand upon it. If you don't learn well from books, I would suggest either getting some sort of on-line training or finding on-line forums where you can get some support in developing these skills.

      Also, I am going to suggest that you take some time, to the extent that you can, and learn PostgreSQL. MySQL has a lot of pitfalls once you start to do serious work on it (the planner doesn't handle large numbers of joins well, which limits normalization of some databases, and there are a number of other issues I can point to). PostgreSQL is a very good RDBMS, and it is far more programmable than MySQL.

      Long-run I hope that the industry can move away from the emphasis on having programmers code SQL. This trend is responsible for a heck of a lot of problems in the industry. I have seen db structures which are so bad that they defy belief even for beginners (an event booking system which had one *table* per customer to store attendance). Hence my large gripe has to do with people starting to design databases before knowing anything about what they are doing. This again isn't your fault so much as it is an issue with most beginning SQL literature at the moment.

      Finally I am working on creating a book on PostgreSQL which you might find interesting. It will assume some SQL knowledge, but if you are interested in providing some feedback on what is accessible and what is not, I would be happy to forward you a copy of each chapter as I get it done.

      --

      LedgerSMB: Open source Accounting/ERP
    3. Re:Out of curiosity by Anita+Kuno · · Score: 1

      I'm grateful for your choice.

      I've been reading what you and the others have to say and also reading some of your work online since the comments have been very informative for me. I'm grateful for the calibre of the information which I'm able to access via this experience. Thank you.

      You are asking some interesting questions. To be honest I haven't thought about where I want to take my db knowledge since my review is to serious database design is what editing home movies on a computer is to unionized film production. I've been evaluating a book on mathematical philosophy online for most of this morning and it is introducing me to concepts that are making a whole lot of sense to me. It's been filling in a lot of blanks in terms of understanding programming languages and applications that that have been making me crazy.

      If you are willing to suggest a book or two or perhaps a tutorial or mailing list, I will evaluate your suggestions and act accordingly. If it is inappropriate to do so in this venue, you may email me personally.

      I appreciate your evaluation of PostgreSQL. Since I just learned SQL, I'm not attached to it in any way and am willing to look at other options of RDBMS (or is it RDBMS's?). Again a link or suggestion will be accepted and evaluated on the terms with which it is presented.

      It certainly sounds like there is a huge gap between those who design and maintain databases as a career and the respect they receive from those for/with whom they work. I can certainly understand how that feels and it must be the cause of large amounts of frustration judging from the comments I have read.

      Kudos for working on a solution to the problem you perceive. I'd be grateful to help in anyway that I am able. My return feedback for submitted chapters will depend on what else is happening in my schedule. Perhaps we could work towards a turn around time of a chapter a week based upon the length of the chapter and the accessibility of the content. And how would you like to receive feedback? I've done this before through email using HTML mark up for comments (like using a different font and colour (I'm Canadian so some of my words will have an extra u though I won't expect your book to include a u in color if the word is in the manuscript)). I'm wondering though if something from 37 signals would do I better job (being able to work on a piece at a time or discuss a paragraph without flipping the whole chapter back and forth). What are your thoughts?

      Again if this is venue inappropriate you may email me personally,

      Anita.

    4. Re:Out of curiosity by einhverfr · · Score: 1



      To be honest, most applications behind small public web sites have needs for databases so simple that they are reasonable areas for beginners. My first real attempt at db design was for a CRM program which was not terribly well done. I made lots of stupid mistakes which more or less doomed the project. Most of these were due in part to a lack of understanding relating to the function of the RDBMS and also a lack of understanding the semantics of the data I was working with. The first would have been solved by reading more, but the second was a matter of inexperience (not really understanding where functional dependencies were, which makes normalization impossible anyway).

      As for PostgreSQL vs MySQL, MySQL was really built for light-weight content management applications. It does these things admirably but doesn't really allow you to use an RDBMS to its real potential. Hence it is a good choice for some applications. However, for line of business tools, or wherever money is tracked in the db, you can run into problems. (Strict mode can be turned off by applications, an a lot of checks don't work if the table was accidently created as MyISAM.)

      You need to understand that an RDBMS can be used to mathematically define valid data for the application. These constraints can be used to avoid whole classes of bugs in application code (where subtle data validation cases are missed, or are missed in some program execution branches). In fact, defining data validation orthogonally to program flow has a number of very great advantages in terms of time spent debugging, etc. Although it is not possible currently to do all data validation in the db using only relational constraints, a little time spent there is well worth it. MySQL does not allow for strict validation which cannot be disabled. PostgreSQL does.

      In fact, RDBMS's are basically big math engines. A few other open source ones to take a look at are Firebird (has a few odd issues with NULLs that I find scary), Ingress II (a distant cousin to PostgreSQL), and Derby. The three big proprietary RDBMS's are MS SQL Server, DB2, and Oracle.

      A few areas of PostgreSQL that are especially powerful are:
      1) Stored procedures in multiple languages (Perl, PHP, Java, R, TCL, SQL with or without procedural extensions)
      2) Table inheritance which can be useful in partitioning large tables (but can also be abused).
      3) User defined types, and a very large number of built in types (for example CIDR and MAC address types)
      4) The PostGIS add-on for geographic information systems.

      I will be happy to send you chapters for review as they are completed. If you have time to respond great. If not, that is OK too.

      Best Wishes,
      Chris Travers

      --

      LedgerSMB: Open source Accounting/ERP
    5. Re:Out of curiosity by Anita+Kuno · · Score: 1

      Thank you, Chris! I could tell from your posts you are a wealth of useful information. I appreciate you taking the time to share with me points which obviously as a beginner I would not be privy to and would not otherwise know was missing from my knowledge of the subject. I'm very appreciative!

      My interest in db use falls, I believe, under the category 'small public websites'. I don't know if I have that great a desire to spend time with accounts to understand the nuances of financial tracking necessary to do the kind of work that you and your company engage in. I know a few accounts and thank goodness they do what they do but I also enjoy a little more variety in my work day than the area provides. I guess it's a personal choice.

      Thank you for sharing your personal experience with me and your insight into possible causes of program failure. Sometimes I find I learn the best lessons from my mistakes though when a lot of people are depending on me, dealing with the subsequent disappointment involved can be really difficult. I take quality very seriously which is why I am learning what I am learning. I want to create a website to sell digital downloads of mp3's I create at home. When I began (some well meaning soul advised me to learn a little HTML and CSS and I would have no problem) I took a look at what I needed to depend on to keep my site running such as the web host company and the payment gateway company and started asking questions of the respective help desks to feel out who I could depend on when I needed them. Turns out I can depend upon me and that's it!! The (no)help desks were very informative about how much I (and my customers through me) could depend on them for timely efficient service. So I realized that I was going to have to do this myself. And the journey continues to be beneficial and educational. I've met a lot of really great, helpful, knowledgeable (and busy!) people who, like yourself, have pointed out a resource and shared a timely tidbit of information when I really needed it and was ready to absorb it. And I'm grateful to all of them. And my work is beginning to pay off. I still have a ways to go before I can build what I want but at least now I know what I need to learn and why it will be helpful whereas while in the disappointment phase, I didn't even have a clue what I needed to learn and know.

      You have a point about understanding the mathematical basis for a structure in order to better use the structure. In the past few days I have looked at some of the resources that you and others have mentioned in the comments. Not all are accessible to me at this time but I did find one on mathematical philosophy which I want to spend more time with when my schedule allows. I feel it will shed light not only on databases but also the programming language and application which I am working on understanding. I'm glad to have access to that resource.

      I like your points about the benefits of PostgreSQL and am interested in exploring more information about stored procedures, table inheritance and user defined types. I'm not sure if my needs include taking advantage of the PostGIS add-on but, as I'm sure you can tell, I do like to keep all my options open since I never know what the future holds for me and I like to know where my resources are that I may call on them should the need arise.

      I think at this point I think we call talk about book details off this forum, if that is okay with you.

      Thank you for the generous response, Chris,
      Anita.

  55. My grandmother knew all about microwaves by einhverfr · · Score: 1

    And x-rays, and radio waves, and element formation in stars. Her name was G. R. Caughlin and she worked with nobel laureates in areas relating to astrophysics.

    And she could probably program Fortran better than you could :-)

    --

    LedgerSMB: Open source Accounting/ERP
  56. Killer example by einhverfr · · Score: 1

    SQL-Ledger used the brilliant process of fetching (sometimes thousands) of rows from the db in order to generate aggregates in Perl, in the CGI app....

    --

    LedgerSMB: Open source Accounting/ERP
  57. Parse as SQL ;-) by einhverfr · · Score: 1

    There is a parse error here. Maybe he meant:

    who || 's photo' || s
    Or maybe something else....

    Never forget your concatenation operators....

    --

    LedgerSMB: Open source Accounting/ERP
  58. This sounds like a good intro book but nothing of use to a seasoned DBA.
    There's not much in it for an aircraft pilot or a pastry chef either.
    --
    Only three things are certain; death, taxes, and apocryphal quotations - Ben Franklin.
  59. every book gets 9? by Anonymous Coward · · Score: 0

    It seems like every book reviewed gets an 8 or a 9. Why?

    1. Re:every book gets 9? by Anonymous Coward · · Score: 0

      Maybe it's because only a tiny number of reviews are accepted for publication by /. and they are generally excellent books. This one is.

  60. fgbnfgfgb by nrahul123 · · Score: 1

    ghnghnghnghnghn