SQL Fundamentals 233
| SQL Fundamentals | |
| author | John Patrick |
| pages | 800 |
| publisher | Pearson Education |
| rating | 7 |
| reviewer | Rob ("robo") Oostendorp |
| ISBN | 0130669474 |
| summary | Truly a beginner friendly book for anyone needing a crash course in the basics of SQL; of limited but real use to those who already are familiar with SQL. |
This beginner book takes a traditional look at the ever-popular Structured Query Language. Never bothered to learn SQL? Here's your chance. SQL Fundamentals, by John Patrick, takes the first layer of SQL in Access and Oracle [robo, I find this a confusing phrase, not sure how best to recast, but somehow] and sums it up in this 834-page manual. Read more for SQL Fundamental's strengths, weaknesses and everything in-between.
The Basics
SQL Fundamentals discusses the practical realities of extracting information from a database. Patrick shows the reader how to use SQL in both Oracle and Access. The book starts with a brief overview of the roots of SQL and relational databases; after this introduction, the book covers select statements and the basics of a query. Each chapter builds on the next, and the book follows a simple progression, adding complexity as it goes along.This book is a very easy read -- it flows much better than a textbook, yet still conveys the information it promises. However, it's definitely for newcomers to SQL. So, if you have any experience in SQL this would not be the best choice. (Chapter 1 explains the concepts of a cell, row, column, and table, which might be enough to let you decide if this book is at the right level for you.) Throughout the book, the author relies on applying each newly introduced concept to a single relational database example. This hypothetical database (a table of employees trying to calculate their meal credits) makes the book feel consistent, and helps eliminate confusion about where the example information comes from, but it's also limiting for readers who want a broader range of examples.
One of the greatest strengths of this book is its wealth of code examples and accompanying tables. In contrast to many other manuals, this book illustrates queries along with their effects on the tables. Other SQL books (ones I consider going up to "layer 2" SQL) have many example queries, but some of them fail to show any sort of results from their example tables. Also, much of the code in SQL Fundamentals is well documented, with footnotes explaining any changes that occurred.
Caution: Beginner Book
The book is called SQL Fundamentals. However, in this case, the fundamentals are only as they apply to the Oracle and Access databases. It mentions the existence of other distributions at the beginning of the book: "Oracle, Access, DB2, MS SQL, Informix, SQL Windows, Sybase, SAS sql procedure, FoxPro, dBase, Tandem SQL, MySQL, SQLBase, Cold Fusion, SAP, Business Objects, ODBC, Ingres, Ocelot SQL, OsloData, PostgreSQL, Rapid SQL, XDB, SQL/DS, Mini SQL, Empress, Interbase, Progress, Supra, SQL Report Writer, Paradox, Delphi, VAX SQL, Essbase, Beagle SQL, GNU SQL Server, Just Logic/SQL, PrimeBase, Altera SQL Server, DataScope, and PowerBuilder." However, Patrick never speaks of them again; perhaps he should re-title this book SQL Fundamentals: Applied to Oracle and Access? Readers considering this book should keep this in mind. The book explains things well, but the book's overall logic is geared toward those using one of those databases, and the examples are relevant only in that context.I primarily use MySQL and Progress, so a book explaining SQL fundamentals applied to Access and Oracle isn't going to help me unless I specifically take on projects which use these particular databases. Also, The book often goes into unneeded repetition of subjects: for instance, the first 150 pages are all about select statements. I've never seen so many select statements picking apart one table. I personally think it would benefit from being trimmed down, and leaving further study to the reader.
The Plug
I would recommend this book to a newcomer to SQL. It covers the fundamentals just like it claims. After finishing this book, you will have a grasp on things ranging from the most basic select statements to unions, self joins, & cross-joins.Something to consider might be what SQL database you will be working with. If you'll be working with either Oracle or Access this book will be helpful. If not, I suggest looking at things like Managing Using MySQL by O'Reilly.
Finally, from the text comes this concise answer to the question "Who Should Read This Book?"
Everyone with an interest in getting information from a database can read this book. It can be a first book about databases for people who are new to the subject. You do not need to be a computer programmer. The discussion begins at the beginning and it does not assume any prior knowledge about databases.
That seems like a fair summary; with the caveats already mentioned, I can recommend it for newcomers to SQL looking for a thorough but not patronizing introduction.
You can purchase SQL Fundamentals from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Anyone Know? (Score:3, Funny)
Sounds like a good read. (Score:1)
Re:Sounds like a good read. (Score:2)
sPh
834 pages?! (Score:4, Insightful)
Re:834 pages?! (Score:5, Insightful)
You could list and explain all of the syntax for C++ in just a few pages, but I wouldn't call you a C++ programmer after reading it.
Database lunacy driven by clients! (Score:2)
I recently completed an app to handle load allocations for a haulage company. A weeks worth of deliveries are emailed over every Saturday, the app sucks it in and populates the db, then makes descisions based upon vehicle availability, capacity etc etc. This was all well and good UNTIL the supplier started reusing distribution point IDs as they changed! So one week we would have ID 65536 holding details for Fred Bloggs, the next, ID 65536 would be Joe Smith. This brilliant idea of reusing IDs was never mentioned, and only appeared after 2 months had passed and problems arose with deliveries appearing at the wrong addresses!
When asked why they did this, the reply was "we just do it that way"?! Needless to say, since the distributor IDs were the foreign key for orders, which were in turn linked to delivery items, and also to the vehicles used for delivery, this lead to some "creative" changes in the db (now delivery points have the id plus another "version" id which doesn't help efficiency all that much, and must look ridiculous to anyone else viewing the code).
Then there was the fact the haulage company wanted to be able to "squeeze" extra items into a vehicle after specifying its maximum capacity - and then asking me why the app wouldn't allow it - oh and also they often wanted to be able to route large vehicles to locations marked as "inaccesible" for that vehicle - which kind of screwed up the routing logic... In fact, just thinking about that project brings tears to my eyes
Underestimating the complexity of SQL? (Score:3, Insightful)
SQL is a powerful tool, but solving many problems with SQL can be very daunting at times, especially when you're dealing with vendor specific nuances.
Re:Underestimating the complexity of SQL? (Score:2)
>>Right, that's why I use C++ or Java to solve those problems.
I'm not advocating awkward SQL implementations. All I'm saying is: I understand that many times, the awkward SQL implementation is the best choice.
Re:834 pages?! (Score:2, Funny)
Re:834 pages?! (Score:3, Informative)
Re:834 pages?! (Score:2)
Re:834 pages?! (Score:2)
Re:834 pages?! (Score:5, Insightful)
Don't get me wrong - you can do useful work in SQL with 20-30 hours of practice. But if you think that SQL can be taught in 30 pages you do not understand it.
sPh
Re:834 pages?! (Score:3, Insightful)
SQL is a tool to interrogate RDBMS. For most IT people it takes a couple of hours to get to grips with basics of select, update etc Joins, sub queries come next.
You can do useful work in one hour of tuition. We have users using SQL after maybe two hours. 20-30 hours of practice, what the hell are you trying to do?
Re:834 pages?! (Score:2, Insightful)
For most IT people it takes a couple of hours to get to grips with basics of select, update etc
This coincides with the sphealey's "1 hour to learn"
Joins, sub queries come next.
This seems to fit with "8-12 hours to figure out how to play".
The "5000 hours to determine whether or not you actually understand it" may be an exaggeration, but the point is that the nuances take a long time to master.
"you can do useful work in SQL with 20-30 hours of practice" sounds like a ballpark figure to me, but seems reasonable. "useful work" might be a bad choice of words, but I think the point is valid.
In my opinion, it's like the difference between someone who knows how to follow a recipe and someone who knows how to cook: after a couple of hours, one could be trained to follow recipes -- but it takes longer than that (and a lot of hands-on experience) in order to be a good cook.
834 pages? it's just a beginning (Score:2)
Year, right. Next after 5000 hours. Even professional SQL programmers keep doing serious mistakes in sub-queries. Not only in performance optimization area (waiting for results forever), but also in consistency are (getting unexpected result sets).
When you have 2-3 tables with 1-2 foreign keys than you may learn sub-queries in 12 hours. But when you do a very specific data mining work, combining several huge historical journals, several classification graphs, lots of assotiation maps and many lots of lookup tables, then you might realize that you still have to learn SQL even after 5000 hours of using it. If you don't think so, then you've never done any serious data mining by yourself. I spoke with many SQL programmers who worked with ERP, CRM and Supply-Chain applications and they had the same opinion.
The age old question... (Score:4, Interesting)
To me it is Postgres-Q-L and My-S-Q-L, but I think the Microsofties call it Microsoft Sequel Server...
Maybe good for a
Re:The age old question... (Score:3, Informative)
Re:The age old question... (Score:5, Interesting)
It is properly S-Q-L because Sequel is something different (Structured English Query Language, an IBM project that never went anywhere). But the term "sequel" for SQL has come into common use, so it's the de facto pronounciation.
Microsoft people just call the product "SQL Server" which IMHO is like calling Windows "Operating System" but it comes from the old days when Sybase and Microsoft cooperated (circa MSSQL 4-6/Sybase 10). Sybase's product was called "Sybase SQL Server", but people just call it "Sybase" (akin to calling Windows "Microsoft"). When they split, MS kept the rest of the name.
You can easily spot a hardcore elite database guru by the fact that these people pronounce it "squirrel".
Re:The age old question... (Score:2)
Squeel (Score:2)
I'm gonna make this server squeel like a pig.
Re:The age old question... (Score:2)
Heh, Windows is called Windows, as in "Windowing System" - not much better than "Operating System" if you ask me.
Re:The age old question... (Score:2)
Re:The age old question... (Score:2)
sPh
Re:The age old question... (Score:2)
I think it started happening before then. I was doing SQL stuff back in the 1990 timeframe (even interviewed at Ingres and Sybase) and everyone I knew was saying sequel even back then. It might have been a Bay Area thing though, or maybe even specific to the "upstart" db's, don't know what the IBM or Oracle camp was calling it.
Re:The age old question... (Score:2)
Hey, I was kidding .... (Score:2)
Re:The age old question... (Score:4, Funny)
Todd
Squeal (Score:2)
Or what about... (Score:2, Funny)
I here you. I always get confused with 'C'. Is it pronounced "See"? Or as I like to refer to it: "C".
My coworkers like to read the "Fack" when they need help. If people ask me, I just tell them to consult the "Fa" "Q".
Re:The age old question... (Score:2)
So, it's correct to refer to Microsoft "Sequel", as long as you understand that you're talking about the product, and not the language.
Re:The age old question... (Score:2)
Re:The age old question... (Score:2)
I pronounce it "squirrel". I worked in a place where everyone said "sequel" and I hated that name. The strange thing is, I don't know why. I just did.
Re:The age old question... (Score:4, Funny)
Dear Slash-Dotters,
I can't believe how clueless you guys are. Everybody knows it's Structured QUERy Language, or
SQUERL, which is properly pronounced _SQUIRREL_.
Sincerely,
Steve
Learning Postgres Online (Score:5, Informative)
PostgreSQL: Introduction and Concepts [postgresql.org] by Bruce Momjian
Practical PostgreSQL, by Command Prompt, Inc. [commandprompt.com] written by John Worsley and Joshua Drake of Command Prompt, Inc.
Very practical definitions, examples, and procedures. I'm still scratching the surface of SQL, so I haven't found anything yet these sources can't handle.
I've also found the Usenet Posgres groups useful.
SQL (Score:5, Insightful)
I would suggest not, because you will learn bad habits, and they will be hard to shake once you start working on a real database (Oracle, Sybase, SAP-DB, etc). I have seen MySQL programmers do massively inefficient (and stupid) things like retrieve a list of keys from one table, store them in an in-memory array, then loop through the array executing a select for each key in another table - because they didn't know about subselects. I've seen them put all sorts of redundant validation crap in the middle tier because they didn't know about constraints and triggers. I could go on and on...
If you want to learn SQL, you first need a solid general foundation like this [amazon.co.uk] (I have an earlier edition) then later study the extensions that each vendor provides (Oracle PL/SQL, Sybase T-SQL, etc).
Re:SQL (Score:3, Interesting)
Validation logic belongs in the middle tier. The storage tier is just that - storage. It shouldn't be smart, and it very definitely should do anything else than storing the data I tell it to store.
Triggers, constraints - bah. All very vendor specific and they lead to application logic being strewn all over the tiers. Application Logic should be in the middle tier, period.
-josh
Re:SQL (Score:5, Insightful)
Databases, especially "grown up" ones like Oracle and DB2 are designed and optimized to do a hell of a lot more than data storage. If you want storage, use flat files. You should maybe, I dunno... pick up a book. You can write entire applications in nothing but PL/SQL that perform several times better than a similar C++ or Java app.
In fact, so much development is done in the databases themselves, that Oracle has a certification just for that, called the Oracle Certified Application Developer. But alas, generally these days everyone is still running around screaming "middle tier! middle tier" while the real database gurus just sit back and laugh as projects implode.
SQL and OOP in conflict? (Score:2, Interesting)
It seems that many OO fans have a desire to create their own "database" from scratch via programming code, and treat the RDBMS as mere "persistence". They end up using array-like things to manage their own indexes for one-to-many and many-to-many relationships, for example.
This is a widely accepted practice in the OO community. I really don't want to maintain such code.
It seems many OO fans want "control". If you use the database for such things instead, then you are more dependent on the DB vendor and DBA's, and that bothers them.
I agree that DBA politics can be a bottleneck for developers at times (would make a great
(Note that I did *not* say that *all* OO fans avoid or mis-use databases. I am only saying that it is too common a practice. Thus, I am not really bashing OO here, but a bad practice often found in OO shops, for whatever reason.)
Re:SQL and OOP in conflict? (Score:2)
In good teams of developers (in which I've only gotten to work a few times), the developers and the DBA's work very closely together. The DBA creates the sandbox for the developer to work in, handles backups, helps with occasional optimizations, etc. In most shops, developers think that they understand databases if they can write simple SELECT statement. They just have no clue, whatsoever, as to what databases can do and what they can be used for.
I was lucky enough to learn the hard way... I was pushed straight into development with a very, very brutal Oracle DBA. He knew more than I've forgotten in my lifetime, so I learned the right way to write apps. Most programmers never get that opportunity, so you're right, they treat databases as nothing mroe than a data dump. Hell, most people have no idea as to the scope and size of just Oracle's product offerings that all work with their databases.
Re:SQL (Score:4, Informative)
The OP is completely correct: triggers and such are rubbish (except to enforce data integrity when the integral RDBMS mechanisms cannot). DBs are for storage, period. You claim that a DB is a great place to shoe horn logic, but that leads to problems.
1. The bloat is in a functional-programming layer (SQL) instead of a procedural/OO layer. Given a choice between lotsa logic down in a DB and lotsa logic in my app, I'll take the logic in my app any day of the week. SQL does not promote code reuse, whereas most procedural and OO languages do promote it to some degree.
2. The more code you put in a DB, the less portable your schema is -- and I'm not talking about platform portability, I'm talking about RDBMS portability. Nothing is worse than [IBM|MS|ORA] database lock-in.
3. The poor performance you site may be common in your experience, but code in the middle layer(s) is not the cause of that: bad design and poor testing are the causes. Don't confuse correlation with causation.
These points are backed with experience: I've been programming for 15 years, 7 years of that using databases heavily. The company I work for now has terabytes of data stored in the schemas I've developed for my apps, and no one has ever complained about maintenance or performance on one of my designs.
Re:SQL (Score:3, Insightful)
of course. brilliant observation.
tables thems selves contain application logic
not my tables, and not any tables from the developers on my team.
checking row types, etc.
this isn't application logic, it's data integrity.
"hey, you're using that querry quite a bit, how about we just compile it all up in the database for you and speed things up a bit, eh?".. bang, code reuse.
sorry, that's not code reuse at all, not even close. give me a [stored proc|view|table] that i can inherit from or subclass, and that would be reuse.
but those who spend 500,000$ for their RDBMS software package will keep it around for a tad.
and one of the reasons that they'll "keep it around" is because they paid so damn much for it. why lock in an implementation decision for so long? it doesn't promote agility, nor does it promote flexibility. quite the opposite, it encourages poor SQL coding (i.e., vendor-specific features). it's called the "Golden Hammer" Anit-Pattern. look into it.
most companies have terabytes of data stored in their schemas
um, no. gigabytes, maybe, but most companies have databases in the terabyte range? i don't think so.
you might find that if you take out all those i's and use lots of we's for the good of the compnay, you'll still get some credit
funny, it sounds as if you haven't read _The Mythical Man-Month_, wherein Brooks asserts that the best software systems come from a single mind. if you're a professional software developer (it's hard to tell from your post), i strongly suggest you read it.
as to credit, i'm not in it for that. rather, what motivates me is implementing solutions that help achieve the objectives of the company for which i work. see, i'm a stock holder as well as an employee, and i'm just as motivated by profit as the CEO.
on another point, maybe should note that a great sense of ownership leads to pride in work and higher quality. (to be sure, there are pitfalls associated with too great a sense of ownership, but experienced developers know when and how to cut the cord, so to speak)
Re:SQL (Score:2)
You can still have a business logic layer. It's just that in many projects, that logic is faster and more efficient running as PL/SQL or TSQL than it is in some compiled DLL.
and one of the reasons that they'll "keep it around" is because they paid so damn much for it. why lock in an implementation decision for so long? it doesn't promote agility, nor does it promote flexibility. quite the opposite, it encourages poor SQL coding (i.e., vendor-specific features). it's called the "Golden Hammer" Anit-Pattern. look into it.
If you're talking about a serious piece of software (as opposed, to say, a web app for a shopping cart or something similarly as silly), flexibility isn't an issue. You simply don't go around switching databases for say, a bank or a credit card company or a health care provider. Any IT guy that says "let's switch databases" mid-stream for no good reason is incompetent. Projects that use things like Oracle generally use it because the company is stable, the projects are stable, and the project is going to live largely intact for many years.
um, no. gigabytes, maybe, but most companies have databases in the terabyte range? i don't think so.
It sounds like you're used to working on smaller, perhaps not misson-critial projects for smaller companies. Terrabyte+ databases are very common in most Fortune 500 companies, gov't institutions, etc. Who do you think keeps Sun in business? You don't buy Sun hardware for a 100 gig database. You get a PC.
Your assumption that flexibility is always so very important is wrong. No reasonable company is gonna be switching databases like they change their pencil suppliers. It just doesn't happen. Hell, I know of many instances where companies stay with the same *version* of database for 5+ years.
Re:SQL (Score:2)
Flexibility is always an issue because requirements always change. To think and to code otherwise is folly and professional laziness. Anytime you get a set of requirements and code to them blindly without considering the ramifications on maintenance and future business objectives you invite disaster.
You simply don't go around switching databases for say, a bank or a credit card company or a health care provider.
Of course you cannot when they've been coded as you suggest. It's simply not practical, and maybe even not possible under your guidelines. If you code to SQL-92 whenever it can be done, switching databases becomes a real possibility.
Any IT guy that says "let's switch databases" mid-stream for no good reason is incompetent.
Straw man. Of course if there is "no good reason" it would indicate incompetence. However, there are often many good reasons to switch databases, such as constantly shifting licensing terms *cough*Oracle*cough*, ridiculous licensing fees *cough*Oracle*cough*, lack of standards *cough*Oracle*cough*, etc.
It sounds like you're used to working on smaller, perhaps not misson-critial projects for smaller companies. Terrabyte+ databases are very common in most Fortune 500 companies, gov't institutions, etc.
The original poster said "most companies", and "most companies" are not Fortune 500 or even Fortune 1000 companies. I thus stand by my statement that most companies do not have database systems in the terabyte range. And it sounds like instead of refuting my original points, you'd rather try to dismiss them by suggesting I don't have experience with mission critical systems. Fact is, the databases and applications I design, develop and deploy are carrier-class because they have to be.
Given your repeated mention of Oracle, it sounds like you're actually an Oracle developer as opposed to a SQL developer. That's okay, I suppose, as everyone needs to have a job.
Hell, I know of many instances where companies stay with the same *version* of database for 5+ years.
Uh-huh. And do the same companies have to maintain their code? How about extend it? Thought so.
Re:SQL (Score:2)
You don't want to (unless, say, your organization grows rapidly and you need to migrate to a database and platform you couldn't previously afford), but what kind of leverage do you think you'll have with the vendor when it becomes known that you can't?
Sure, many databases have crummy optimization and need to be coddled with proprietary query syntax, but failing to bundle a tested ANSI-conforming equivalent is negligent.
Re:SQL (Score:2, Informative)
I have found http://www.dbdebunk.com/ [dbdebunk.com] very informative. If you insist on cutting down trees, I would recommend any of the books that this site links to.
There are fundamental problems with SQL. You may well be forced to work with it but you should at least know what its limitations are.
Hopefully, once you truly understand the problems with SQL, you will see the light, rebel, tell Oracle et al to go screw, and help develop some nice good Open Source alternative to the crappy SQL language.
If you disagree, you are welcome to touch me lower.
Re:Blah! (Score:2)
Re:SQL (Score:2)
I've been reading that same statement for about 2 1/2 years. You can expect a subselects in MySQL at about the same time you'll see Duke Nukem Forever under your christmas tree -- in other words, "real soon now", for sufficiently ludicrous definitions of the word "soon."
Re:It works both ways (Score:2)
I was waiting for someone to point out that the given example of a subselect is really just a simple join. That's really just SQL 101. Now, there are cases for subselects, but they do get hairy.
btw - middle tier all the way - what do you do in sql when you want to say, check db value a, based on return of C function b? run home to mom that's what.
middle tier promotes code re-use, but it also promotes a _logical_ data schema over the _physical_ data schema which is exactly what putting logic in things like triggers and such in does not do.
Re:It works both ways (Score:2)
middle tier promotes code re-use, but it also promotes a _logical_ data schema over the _physical_ data schema which is exactly what putting logic in things like triggers and such in does not do.
Let's say you want to access the same group of tables from multiple places in your application, in different objects running on different hosts written by different people, and you don't have source to some of them. You've got 3 choices:
Option 1 is just silly - impossible to maintain for all but the most trivial cases. Option 2 adds an additional layer of indirection, hitting performance, it's another layer to test and another point of failure in production, and it's functionally the same as a trigger anyway. Or pick option 3, which has been refined over 2-3 decades in some of the toughest transactional processing apps in the world, keeps all you code in one place, and guarantees integrity even if you can't in your objects.
As an experienced system architect, one of the mistakes I see newbies make all the time is that they think because their tiers are logically distinct, they have to be physically distinct too. In a professional shop, your logical design will be done by a theoretician who doesn't even know or care what the eventual platform will look like, then the physical design is done by a hardcore, grey-haired DBA who's been there and done that on a dozen major projects. The programmers who actually implement it almost always don't see the big picture, because they're the specialists that focus on their own personal bits of the code.
Re:It works both ways (Score:2)
if I don't have the source to applications that are accessing my database, then I'm in pretty big trouble. not having the source means I don't trust the app, and at that point it's like having a wide open door to your db. Sure you could play catch up with some triggers and such, but really, you're already in a bit of a mess aren't you?
Let's assume a reasonable environment though, we're you're building an app, and have control over the source. So - if twenty apps update 5 tables, then which sounds better - leave the database wide open and assume they can be updating it any which way, biting your nails worrying about a data integrity problem (like - maybe application a updates column a in one way and application b does it in another) or put the update code in one place, such that all applications go through the same api.
Preferably this api is a middle ware api, but it could just be an object to, middle ware is easier to maintain, but perhaps has more up front infrastructure.
As far as performance goes, that's just total bullshit. If anything, moving the core integrity checking off to another host, and freeing you're database server to do record management only will speed things up. Further, if reads and writes are funneled through a correct api you only need to change one set of code once when you want to change database schemas, which you _will_ want to do. Business requirements change, tables need to be added.
btw - in you're description of what 'professionals' do, how do the programers ever know of the logical data model if they are hitting the physical data directly?
MySQL gains more users thanks to Apple (Score:3, Interesting)
Wider acceptance of MySQL and its related products/technologies is a good thing, and books such as this are only a good thing in my mind.
Re:MySQL gains more users thanks to Apple (Score:3, Interesting)
For the last few years, my career has largely been based on Oracle products, so I have as vested an interest as anyone (save maybe Uncle Larry) in seeing Oracle continue to be the #1 choice for corporate databases, but I've got to say, if you even can run your application on MySQL, you really shouldn't have bought Oracle in the first place, because you've completely wasted your money. Only buy a product like Oracle (or Sybase, DB2, etc) if you know that you need its capabilities. If your application doesn't need subselects, triggers, real transactions, etc, then you might as well use MySQL, or even CSV on the filesystem!
Oh, and the R in RDBMS means "relational". Correct me if I'm wrong, but MySQL needs a plugin to even do foreign keys - you should really say just DBMS.
Re:MySQL gains more users thanks to Apple (Score:3, Interesting)
But in the least case MySQL supports relations (tables) so it has, to some degree, a relational background. FK support is required according to Codd, but virtually all DBMS also break some of his other rules as well, so it depends on how deviant a product must be before it is declared non-relational.
Re:MySQL gains more users thanks to Apple (Score:3, Interesting)
Actually, I've heard some folks take issue with the "M", on the grounds that a system that does not ensure relational integrity and transactional atomicity is not providing database management. Considering that many mySQL supporters bracket their support by saying that it is strongest for read-mostly databases (placing it in a category with LDAP's slapd), I would feel comfortable calling mySQL a "database daemon".
(For my own reasons to choose PostgreSQL, and some links on the subject, see my Slashdot journal [slashdot.org] about my current work project.)
For what it's worth, I'm glad that the mySQL folks have largely quit telling untruths about relational databases. A few years ago, they were saying in the mySQL documentation that foreign key constraints are for lazy programmers, and that anything that can be done with transactions can be done just as reliably with application code. (Imagine here Jamie Lee Curtis saying "Those are all mistakes, Otto. I looked them up." [imdb.com])
Re:MySQL gains more users thanks to Apple (Score:2)
The problem comes if/when you scale up. It is a pain to overhaul applications to accept a stronger DB from a different vendor.
IMO, what OSS needs is a lite-duty DB and a heavier-duty one, but the smaller one is a clean subset of the bigger one. MySQL and Postgre have different conventions. It is not a matter of plug-and-play to switch. But, it *could* be if they coordinated efforts to make the language and features more consistent between them.
Or, even an OSS Oracle clone. It might benefit Oracle to do such because people would use the OSS to get started, and later if they need more power then purchase the commercial version.
The cost of incompatibility is often higher than the DB product cost itself. People want to be able to up-grade (and down-grade?) without overhaulling the application's SQL calls. Such a thing does not exist in OSS right now.
Uh yeah right! (Score:2)
Yes, the mindset of the fortune 500 lives or dies by what Apple does. "Hey I wouldn't buy any of their overpriced computers but if they think MySQL is great, it must be".
MySQL is pretty good though. Ah hee ah hee hee
Re:MySQL gains more users thanks to Apple (Score:2)
some thoughs (Score:2, Funny)
It mentions the existence of other distributions at the beginning of the book: "... and PowerBuilder."
I know I stopped using PowwerBuilder with the version 7, and the version 9 is out, but at that time, it was not a SQL database, only a client for SQL databases.
about SQL:
SQL is a langage with which it is really easy to obtain a result that is not what you intended.
Re:some thoughs (Score:2)
Does anybody know if this book talks about using Access by itself, or if it treats Access more in the context of accessing Oracle?
First time web "programmer" (Score:2)
Even though I layed out the database in access, I didn't touch access after the file was created. I then moved to personal web server (an all the security holes that creates) to manipulate the database through ASP.
I know there are many others that because of various reasons are unable to get their hands on other databases, if you get the fundementals of sql through access, you are able to understand the majority of sql statements having to deal with other databases. Even though,things do differ, you have somewhat of a foundation to understand sql.
Standard SQL? (Score:4, Interesting)
Re:Standard SQL? (Score:2)
I don't know what Access does now, but in the past it too basically just ignored the SQL standard. At least we can trust that the Microsoft programmers were aware of the existence of the standard while they ignored it.
If you want a decent, reasonably compliant SQL engine, you'll probably use Oracle, Microsoft SQL Server, or PostgreSQL. Of course, once you actually use any of those, you'll quickly discover the huuuuuge differences in implementation... It turns out that following the standard hardly matters as much as anyone thought...
Re:Standard SQL? (Score:2)
Yes, but most of the deliciously interesting features of Postgres (and other systems) is the proprietary stuff... mmmm, regular expressions...
O'Reilly? (Score:2)
PS: Amazon has it for $34.99 [amazon.com] [associate]
Re:O'Reilly? (Score:2)
Don't click on slashdot book link (Score:2, Funny)
Save some money
Re:Don't click on RedWolves2 book link (Score:2)
Internet Vs books (Score:2)
Step 2: go to google.com and enter:
+mysql +sample
Step 3: Spend some time reading, figure it out.
Standardized way (book) The advantages of a good book are mainly in the way of standardization and security. While I've seen books that were crap in reference to this, most do a much better job of providing code samples than the underinformed indivuals writing "samples." That being said, major sites like Zend.com and php.net still provide good examples etc, but in that case you need some fore-knowledge to know what to look for.
All IMHO of course. Many of us are "example learners" as opposed to "book learners".
For More Advanced... (Score:5, Informative)
If you want to make the developers/DBAs/bosses in your company think you are an absolute god, get a copy of Celko's SQL Puzzles and Answers [amazon.com].
Re:For More Advanced... (Score:2, Informative)
If one wants a fairly good book on SQL (though oriented towards T-SQL, and a lot towards Microsoft), Ken Henderson's "The Guru's Guide to Transact-SQL" is good. Ken also lists Celko as one of his major influences.
Re:For More Advanced... (Score:2)
- A Guide to SQL Standard [amazon.com], by Hugh Darwen (Contributor), Chris J. Date
- Foundation for Future Database Systems: The Third Manifesto [amazon.com], by C. J. Date, Hugh Darwen
First book is the only good book about SQL standard I found. You can learn lots yourself and you can teach (if you are a teacher or a project leader) other developers.The second one very well explains when and why "pure" SQL doesn't work [well] anymore.
By the way, Date is not less bizarre character than Celko, neither he is less productive author. Especially together with Darwen.
Learning SQL doesn't give you all the skills (Score:2, Interesting)
In order to fully comprehend, say, the works of E. F. Codd, one really needs a background in automata and in abstract algebra.
Off-topically on-topic. (Score:2)
If I wanted to learn the theory behind designing databases what would be a good book to read? I'm thinking more along the lines of learning from a text book v.s. learning from The Blithering Idiot's Guide to Database Design.
Definitely Off-Topic now. (Score:2)
I refuse to give money to companies that try and make me feel like an idiot.
Re:Definitely Off-Topic now. (Score:2)
Re:Definitely Off-Topic now. (Score:2)
How about:
"The Well-hung Guy's or Big Titted Girl's Guide to Database Design"?
Or "Database Design for Males with Large Penises and Slim, Large Breasted Females?
Access & Oracle? (Score:2)
Access is for small db's, usually personal ones or very small business databases. Oracle is a big enterprise database capable of storing huge amounts of data.
Isn't that kind of like writing a book teaching you an introduction to writing batch files and mastering C++ all at once?
Re:Access & Oracle? (Score:2)
Oracle too is used alot more than MS SQL, but Oracle's PL-SQL is a different beast from T-SQL. Hence, you get 'reasonable' coverage of the SQL spectrum...
In an age where there's entire sections of bookstores dedicated to "Dummies" it's great to see authors giving due credit to their reader's intellect by showing them not just 'where to begin' but 'how far up you can go'.
Re:Access & Oracle? (Score:2)
A Beginners Book? Not at 834 Pages! (Score:2, Interesting)
A beginners book should be concise. Take Kernighan's, The C Programming Language [amazon.com]. 272 Pages for learning one of the most important languages in computer science. Just you, the language, a few demonstrative exersices and that's it.
Newbies and SQL (Score:3, Interesting)
Oracle is NOT a good system to start of with SQL, I think MS Access nice start, but Access SQL is syntax slightly differenct than the standard SQL-92. Also, Access has the PIVOT keword which does not exists in T-SQL and doesn't do the same think in PL/SQL. PIVOT is great, but is not a standard. This book needs to also show common problems and how they are solved using standard SQL, not propietary.
One thing I think Access has that is better than any other enterprise database system is it's query creation tool. I know MS SQL has finally added such a tool, but it comes nowhere near as easy to use as MS Access. And for strength of SQL I think Oracle wins, hands down, but for administration, you can't beat MS SQL Server. For turning, you can make a career out of Oracle. Granted, I have used Informix, Sybase, and Approach as well as Access and SQL Server, so my comparisons are going to be with Oracle, SQL Server, and Access.
Newbies need to learn how to design databases, drill them into they are spouting normalization on the streets. Also, get the newbies to learn to use lookup tables, DO NOT USE CHARACTER FIELDS to index or do searches on, USE NUMERIC, INTEGER, FIELDS! All the training in SQL is not going to do a bit of good if it takes an hour to retrieve a dataset that could have taken a few minutes with the correct indexes.
Re:Newbies and SQL (Score:2)
That's not necessarily correct. With many database systems short char fields work just as well for indexing as integers, with negligible performance difference. And sometimes are a lot more useful, for example, people can work with 4 and 5 character alphanumeric barcodes fairly well, but not necessarily with their numerical counterparts.
Re:Newbies and SQL (Score:2)
That said, I strongly agree with you on the other stuff.
Re:Newbies and SQL (Score:2)
I'm sorry, but you're wrong. Yes, if you want to setup a simple frontend for access it is easy. But more complex databases demand a lot more than access is good at (and often even capable of) delivering
I've written A LOT of code in Delphi and VC++ to talk to access, sql server, mysql, oracle, and other databases. If you have used Delphi, then you clearly have never tried employing ADO and the data-aware fields (e.g., DBedit). Almost all the things that you take for granted in Access, you can do with just a _little_ extra effort (no code) in Delphi. In other words, you don't have to write your own sql queries dynamically: no selecting, no updating, no inserting, nothing. When and if you want to modify the logic, to do data validation or what have you on the client side, then you can easily do that too via events or drive it after a button press. If you think these are too complex, then you either have never done it and/or have no room to talk here about skill.
I'll grant you that even Delphi or Powerbuilder would be daunting to a newbie for writing a simple application, but it is:
A) Much easier in the long run when dealing with a moderatly complex application, almost regardless of skill level (those that lack the skill to do it in Delphi, aren't going to understand the limitations of Access well enough to make it work)
B) Faster and easier for an experienced developer that has used them before for all but the most simple of applications (as in something more than simple adding/deleting/modifying records from a couple tables). The moment you hit access's limitations you'll waste an inordinate amount of time on the kinds of problems that are trivial with the right tools under Delphi, VB, VC++, or even Powerbuilder.
Here's a Recomendation. (Score:2, Informative)
Well this is a first... (Score:2)
Wow! Oracle and Access mentioned in the same sentence without sarcasm or outright laughter. Someone please note the date and time.
Re:Well this is a first... (Score:2)
Life query (Score:2, Funny)
> Error, column SexLife does not exist in this table.
SQL is BAD (Score:2, Insightful)
I have found http://www.dbdebunk.com/ [dbdebunk.com] very informative. If you insist on cutting down trees, I would recommend any of the books that this site links to.
There are fundamental problems with SQL. You may well be forced to work with it but you should at least know what its limitations are.
Hopefully, once you truly understand the problems with SQL, you will see the light, rebel, tell Oracle et al to go screw, and help develop some nice good Open Source alternative to the crappy SQL language.
If you disagree, you are welcome to touch me lower.
834-pages ? (Score:2, Interesting)
Overhaul SQL (Score:2)
A functional syntax would also allow one to add extensions without worrying about ruining the parse tree. Thus, if Oracle had something that Sybase did not when you switched vendors, the DBA could write their own library function to match it. A shop can't add to SQL very easily on their own because of the complexity of the language. FP syntax is more modular.
The longer we wait, the more SQL will become entrenched, due to books like this.
Re:Overhaul SQL (Score:2)
I agree with you. Almost.
But which FP syntax do you mean? Lisp? ML? Or Haskell? Their syntaxes are quite different. How would you define FP syntax?
And why DB products with "ugly" SQL syntax are more popular than ""pure" FP DBMS FramerD [framerd.org]?
Re:Overhaul SQL (Score:2)
The only answer I can see myself is that most of limitations in "pure" ANSI SQL are compensated (somehow) by integration (embedding) SQL with conventional (mostly procedural) programming languages. I agree that the result of such integration is "dirty". However does anyone else (besides me and you) in the world understand it?
Actually, there other such people, but their ideas about post-SQL [amazon.com] are considered as crazy and no one commercial company wants to adopt it.
Perhaps open source can? How about functional programming extention to PostgreSQL? It's already got PL/* extension to integrate SQL with procedural languages. How about FL/*? It would be exciting to have FL/Haskell, FL/Lisp, FL/Scheme and FL/ML in PostgreSQL! Just remember, when I mean FL/Schema I don't mean pgsql *client* library linked to the guile or gauche interpreter. I mean that the scheme interpreter library will be added (embedded) to PostgreSQL *server* as a server-side FL/Scheme programming extension in a way similar how Python interpreter library is added (embedded) to PostgreSQL *server* as a PL/Python server-side language extension.
And why stop on FL? How about Logical and Function-Logical programming language extensions in PostgreSQL? LL/Prolog, FLL/Curry - you name it! :)
Now the question is who will do it and on what budget?
here's a shorter version (Score:2)
To select something
select columnname1, columnname2 from tablename where columnname1 = 'thevaluetogetby';
To add a line to the DB
insert into tablename (columnname1, columnname2) values('value1', 'value2');
To update a line
update tablename set columnname1 = 'value1', columname2 = 'value2' where columnname1 = 'thelinetoupdate'
THAT is a beginners guide. I don't know what the other 833 1/2 pages have... Sure some people consider all the different joins to be "beginner" but I'd call that stuff intermediate.
Travis
How does this help wanna-be DBDs? (Score:2)
Another great SQL book (Score:2)
Re:I don't get it! (Score:3, Funny)
Re:I don't get it! (Score:4, Funny)
CREATE VIEW girls AS SELECT * FROM slashdot WHERE sex = "F"
... returns an empty set iteself, so your subselect isn't going to do you any good, naturally.
Re:ANSI anyone? (Score:2)
ROTFL. Oh jesus... hang on, I gota wipe the tears from my eyes. Oh christ, that needs to be modded up to +5 ignorant/pathetic/funny.
Joins in Oracle don't work? You're saying, Oracle, the oldest database on the market, the most widely used, made by he second largest software company in the world, doesn't work. You have got to be off of your fucking rocker. I can't even begin to argue with a statement like that, because you can't argue with people who are so delusional, that they can't possibly see the truth. That's like when some crackpot on the street walks up to you and says, "The sky is red and filled with demons!". How do you argue with that other than "no it isn't"?
In the immortal words from Billy Madison:
"Mr. Madison, what you've just said is one of the most insanely idiotic things I have ever heard. At no point in your rambling, incoherent response were you even close to anything that could be considered a rational thought. Everyone in this room is now dumber for having listened to it. I award you no points, and may God have mercy on your soul."