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

 



Forgot your password?
typodupeerror
×
Book Reviews Books Media

MySQL Stored Procedure Programming 206

Michael J. Ross writes "MySQL may be the most popular open source relational database management system (RDBMS) in the world, but during the first decade of its existence, it lacked support for stored programs, i.e., store procedures, functions, and triggers. The major commercial RDBMS vendors — including Oracle, IBM, and Microsoft — could point to this deficiency as reason enough to choose their proprietary systems over MySQL or any other open source system, such as PostgreSQL. But with the release of MySQL version 5.0, in October 2005, the "little database engine that could" dramatically improved its position against the competition. The most comprehensive discussion of these new capabilities is in the book MySQL Stored Procedure Programming." Read below for the rest of Michael's review
MySQL Stored Procedure Programming
author Guy Harrison and Steven Feuerstein
pages 636
publisher O'Reilly Media
rating 9
reviewer Michael J. Ross
ISBN 0596100892
summary A comprehensive guide to developing MySQL stored procedures, functions, and triggers.


Written by Guy Harrison and Steven Feuerstein, and published by O'Reilly Media in March 2006 under the ISBNs 0596100892 and 978-0596100896, this book is the first one to offer database programmers a full discussion of the syntax, usage, and optimization of MySQL stored procedures, stored functions, and triggers — which the authors wisely refer to collectively as "stored programs," to simplify the manuscript. Even a year after the introduction of these new capabilities in MySQL, they have received remarkably little coverage by book publishers. Admittedly, there are three such chapters in MySQL Administrator's Guide and Language Reference (2nd Edition), written by some of the developers of MySQL, and published by MySQL Press. Yet this latter book — even though published a month after O'Reilly's — devotes fewer than 50 pages to stored programs, and the material is not in the printed book itself, but in the "MySQL Language Reference" part, on the accompanying CD. That material, in conjunction with the online reference documentation, may be sufficient for the more simple stored program development needs. But for any MySQL developer who wishes to understand in-depth how to make the most of this new functionality in version 5.0, they will likely need a much more substantial treatment — and that's exactly what Harrison and Feuerstein have created.

The authors are generous in both the technical information and development advice that they offer. The book's material spans 636 pages, organized into 23 chapters, grouped into four parts, followed by an index. The first part, "Stored Programming Fundamentals," provides an introduction and then a tutorial, both taking a broad view of MySQL stored programs. The remaining four chapters cover language fundamentals; blocks, conditional statements, and iterative programming; SQL; and error handling. The book's second part, "Stored Program Construction," may be considered the heart of the book, because its five chapters present the details of creating stored programs in general, using transaction management, using MySQL's built-in functions, and creating one's own stored functions, as well as triggers. The third part, "Using MySQL Stored Programs and Applications," explains some of the advantages and disadvantages of stored programs, and then illustrates how to call those stored programs from source code written in any one of five different programming languages: PHP, Java, Perl, Python, and Microsoft.NET. In the fourth and final part, "Optimizing Stored Programs," the authors focus on the security and tuning of stored programs, tuning SQL, optimizing the code, and optimizing the development process itself.

This is a substantial book, encompassing a great deal of technical as well as advisory information. Consequently, no review such as this can hope to describe or critically comment upon every section of every chapter of every part. Yet the overall quality and utility of the manuscript can be discerned simply by choosing just one of the aforesaid Web programming languages, and writing some code in that language to call some MySQL stored procedures and functions, to get results from a test database — and developing all of this code while relying solely upon the book under review. Creating some simple stored procedures, and calling them from some PHP and Perl scripts, demonstrated to me that MySQL Stored Procedure Programming contains more than enough coverage of the topics to be an invaluable guide in developing the most common functionality that a programmer would need to implement.

The book appears to have very few aspects or specific sections in need of improvement. The discussion of variable scoping, in Chapter 4, is too cursory (no database pun intended). In terms of the book's sample code, I found countless cases of inconsistency of formatting — specifically, operators such as "||" and "=" being jammed up against their adjacent elements, without any whitespace to improve readability. These minor flaws could be easily remedied in the next edition. Some programming books make similar mistakes, but throughout their text, which is even worse. Fortunately, most of the code in this book is neatly formatted, and the variable and program names are generally descriptive enough.

Some of the book's material could have been left out without great loss — thereby reducing the book's size, weight, and presumably price. The two chapters on basic and advanced SQL tuning contain techniques and recommendations covered with equal skill in other MySQL books, and were not needed in this one. On the other hand, sloppy developers who churn out lamentable code might argue that the last chapter, which focuses on best programming practices, could also be excised; but those are the very individuals who need those recommendations the most.

Fortunately, the few weaknesses in the book are completely overwhelmed by its positive qualities, of which there are many. The coverage of the topics is quite extensive, but without the repetition often seen in many other technical books of this size. The explanations are written with clarity, and provide enough detail for any experienced database programmer to understand the general concepts, as well as the specific details. The sample code effectively illustrates the ideas presented in the narration. The font, layout, organization, and fold-flat binding of this book, all make it a joy to read — as is characteristic of many of O'Reilly's titles.

Moreover, any programming book that manages to lighten the load of the reader by offering a touch of humor here and there, cannot be all bad. Steven Feuerstein is the author of several well-regarded books on Oracle, and it was nice to see him poke some fun at the database heavyweight, in his choice of sample code to demonstrate the my_replace() function: my_replace( 'We love the Oracle server', 'Oracle', 'MySQL').

The prospective reader who would like to learn more about this book, can consult its Web page on O'Reilly's site. There they will find both short and full descriptions, confirmed and unconfirmed errata, a link for writing a reader review, an online table of contents and index, and a sample chapter (number 6, "Error Handling"), in PDF format. In addition, the visitor can download all of the sample code in the book (562 files) and the sample database, as a mysqldump file.

Overall, MySQL Stored Procedure Programming is adeptly written, neatly organized, and exhaustive in its coverage of the topics. It is and likely will remain the premier printed resource for Web and database developers who want to learn how to create and optimize stored procedures, functions, and triggers within MySQL.

Michael J. Ross is a Web programmer, freelance writer, and the editor of PristinePlanet.com's free newsletter. He can be reached at www.ross.ws, hosted by SiteGround.


You can purchase MySQL Stored Procedure Programming from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

MySQL Stored Procedure Programming

Comments Filter:
  • by ShieldW0lf ( 601553 ) on Wednesday April 18, 2007 @02:35PM (#18786829) Journal
    You know what it is?

    It's lack of trust.

    MySQL started off making their fast little datastore that uses a little SQL syntax, and they told everyone under the sun that if MySQL didn't do it, you didn't need it, and ought to design around it.

    Referential integrity, ACID compliance, enforcement of rules... every step along the way, they tell you you don't need it and you ought to push the missing logic to the next tier, until they get it, if they get it, then they're so great.

    Couple that with the Project Mayo/DivX corporate structure, then place Postgresql next to the whole shebang as a superior alternative, and the arguments for giving MySQL any of your attention become increasingly small.

    MySQL owes its success to the fact that it was always so simple to choke it off when you were giving it to people on $5/month hosting plans, so it became popular among the very cheap.

    Period.
    • Does it tell anything concrete about MySQL 5? No.
      • Not really FUD (Score:3, Interesting)

        by Anonymous Coward
        It IS a little out of date, but the MySQL forums were dotted with little gems from the programming team like "if MySQL doesn't do it, you don't need it".

        For a high-traffic fairly leisurely updating database where element veracity isn't CRITICAL, they were right.

        What they didn't realise was that people on the forums didn't all work in areas where that was true and would prefer not to have to use two databases...

        They're better, but then again, they're losing the edge on speed, too.
        • Re:Not really FUD (Score:5, Informative)

          by elp ( 45629 ) on Wednesday April 18, 2007 @04:02PM (#18788085)
          Yep it was really irritating. A lot like the Postgres users who kept claiming the next version of their server was going to be really fast.

          In the end the postgres crowd have a right to be upset. They could have been the major player for open databases but their devs were too arrogant to listen to their users and design it to be friendly.

          For all its faults mysql is trivial to install and works out of the box for most applications. Last time I looked the default install for postgresql still seemed to be tuned as though it would never have to handle more than a handful of users. Stored procedures and TCP/IP are off by default and the auto vacuum thing needs to be set up manually. Then don't forget that while the postgres query parser does more error checking that mysql its error messages are incredibly cryptic so its MUCH hard to trouble shoot.

          Your average newbie takes one looks at it, gives up and moves to mysql. When that newbie finally grows up he has too much time invested in mysql to be bothered learning the intricacies of postgres. Every extra feature that mysql adds is one less reason for anyone to try postgres.

          Postgres is a better DB once its setup and tuned properly but considering its usability issues and that mysql users probably out number postgres users a thousand to 1 or more I think mysql is always going to be the number one opensource DB.

          • Re: (Score:3, Informative)

            by cortana ( 588495 )
            I have to say that you haven't checked out PostgreSQL for far too long. None of your criticisms apply to any vaguely modern version of it.
            • by ari_j ( 90255 )
              Not only that, but I can't comprehend anyone who claims that MySQL is easier to administer out of the box than PostgreSQL. User management alone is proof of the opposite.
          • Re:Not really FUD (Score:5, Informative)

            by gullevek ( 174152 ) on Wednesday April 18, 2007 @07:12PM (#18790545) Homepage Journal
            the Postgres speed was true until the release of Version 8. There it might such a huge jump, that was just unbelievable. You should give it a try.
      • by cyphercell ( 843398 ) on Wednesday April 18, 2007 @03:12PM (#18787337) Homepage Journal

        Does it tell anything concrete about MySQL 5? No.

        It does speak volumes about MySQL's history, though. The things he lists are are the reasons why MySQL is still compared with M$ Access. They are valid points, because MySQL as a company has a sordid past, as far as presenting something that resembles modern database theory. I'm not saying I don't appreciate MySQL, I'm just say that I thoroughly understand the frustrations. MySQL has been presented as an off the shelf enterprise contendor for years and that's only begining to resemble fact.

    • Re: (Score:3, Insightful)

      by bahwi ( 43111 )
      "Postgresql next to the whole shebang as a superior alternative"

      I call shenanigans. Only recently has it become superior. Documentation isn't just a feature, it's a necessity, even with the open source world, and Postgresql's documentation is finally getting to a good point. I tried numerous times to install and use this "superior alternative" with bad documentation(it was all there, but in backwards, confusing steps, how to access your database was before creating it, etc..) it was just disorganized. Privi
      • Re: (Score:3, Informative)

        I've never had a problem with documentation. Are you saying the only reason you discounted PostgreSQL as a superior database was the documentation, despite the fact that for years, MySQL would happily drop data without telling you?
        • I've never had a problem with documentation. Are you saying the only reason you discounted PostgreSQL as a superior database was the documentation, despite the fact that for years, MySQL would happily drop data without telling you?

          I am! Let me tell you: PostgreSQL's documentation, until very recently, was quite lacking. I agree the poster you're replying to: the docs were a disorganized mess and were missing important parts.

          A piece of software is only useful if you can figure out how to use it without

          • Re: (Score:3, Interesting)

            by ShieldW0lf ( 601553 )
            My point is that the people behind MySQL have no problem telling you that their software is suitable for a purpose even when it isn't.

            They've come a long way, but unless I'm misinformed, they've still got problems with automatic data conversion breaking data integrity rules.

            It wasn't that long ago they were pushing the worst possible practices as gospel to people who didn't know any better, all while labouring to catch up with the Jones because they knew they were behind.

            They are deceitful.

            Put it this way,
      • by XorNand ( 517466 ) on Wednesday April 18, 2007 @03:39PM (#18787739)

        I recently decided to move to Postgres from MySQL. There are some pretty cool things about Postgres; flexible authentication options and sequences being my current favorite. I've found that it's docs are actually pretty good (I don't know what they were like before). However, since the topic here are stored procedures, I have to really complain bitterly about Postgres's implementation of stored procedures. Creating a sproc that returns a dataset rather than just a outpur parameter is a convoluted dance. You have to exactly define the output using a "TYPE" and then iterate over the dataset using a cursor-like syntax.

        Consider this simple example that I'm currently working on. It's for an internal peer review application where coworkers give one positive and one negative comment about each other:

        DROP TYPE answers_type CASCADE;
        CREATE TYPE answers_type AS (
        positive text
        ,negative text);

        CREATE OR REPLACE FUNCTION answers_get(
        _review_id int
        ) RETURNS setof answers_type AS $$
        DECLARE
        rec answers_type;
        BEGIN

        FOR rec IN SELECT
        positive
        ,negative
        FROM answers
        WHERE review = _review_id
        ORDER BY id DESC
        LOOP
        RETURN NEXT rec;
        END LOOP;
        RETURN;
        END; $$ LANGUAGE plpgsql;

        This ends up being very unwieldy for larger and more complex stored procedures. I recently compared simple output -parameter only stored procedures [rightbrainnetworks.com] between Postgres, MySQL, and MS SQL on my blog. Fortunately it's a lot more straightforward when using that method. I'll stick with Postgres for now and just hope that this is eventually improved.

      • by LizardKing ( 5245 ) on Wednesday April 18, 2007 @04:59PM (#18788871)

        Only recently has it become superior. Documentation isn't just a feature, it's a necessity, even with the open source world, and Postgresql's documentation is finally getting to a good point.

        Unless something dramatic has happened to MySQL documentation since I last used it (version 4.1), then PostgreSQL has the better documenation and has done since as long as I've been using it. The PostgreSQL documentation reads like a coherent set of books, while MySQL documentation seems to be a random mess that grew out of some simple README file. As for the software itself, PostgreSQL has always been superior - a simple comparison of features alone bears this out, but if you want to go further take a look at the code as the same distinction is found there.

    • by ClosedSource ( 238333 ) on Wednesday April 18, 2007 @03:02PM (#18787215)
      I think part of postgresql's problem is its awful name. Just about anything would have been better (e.g. TurboSQL, AgileSQL, FastSQL, UglySQL, FatDumbAndHappySQL, etc).
    • MySQL owes its success to the fact that it was always so simple to choke it off when you were giving it to people on $5/month hosting plans, so it became popular among the very cheap.


      age old concept - cheap, easy, simple thing that works. almost all tech stuff took off like that.
    • Although it wasn't efficient, I hacked together a way to call "stored procedures" in MySQL and PHP. Essentially I had a function callSP. You passed in the name of the SP's and whatever parameters you needed (as a string). Then I'd use PHP to build the necessary query and return $result. It worked for whatever I was doing... although it wasn't a "true SP".
      • by Ajehals ( 947354 )
        Its a "procedure" that is "stored" somewhere, if it works it works!

        For the record on the MySQL (The world's most popular open source database) vs PostgreSQL (The world's most advanced open source database), I think Prefer flat files and grep.
      • Although it wasn't efficient, I hacked together a way to call "stored procedures" in MySQL and PHP. Essentially I had a function callSP. You passed in the name of the SP's and whatever parameters you needed (as a string). Then I'd use PHP to build the necessary query and return $result. It worked for whatever I was doing... although it wasn't a "true SP".

        Umm... that's not a SP at all, never mind being a 'true SP' or not. You basically made a PHP function; the whole purpose of SP is that the database server does the work, not the calling application.

        • by vivin ( 671928 )
          Thanks, Captain Obvious :) My point was that I was only able to emulate the interface. Not the actual part (obviously) of the database doing the job.
    • ... every step along the way, they tell you you don't need it and you ought to push the missing logic to the next tier, until they get it, if they get it, then they're so great.

      Sounds like they're violating a patent for "Method and Implementation of Field-Based Reality Distortion" held by Apple, Inc.

    • by CoughDropAddict ( 40792 ) on Wednesday April 18, 2007 @04:29PM (#18788459) Homepage
      Amen, brother.

      For people not familiar with MySQL's history, I would suggest a little reading from previous versions of MySQL's manual:

      How to cope without COMMIT/ROLLBACK: For the moment, we are much more for implementing the SQL server language (something like stored procedures). With this you would very seldom really need COMMIT-ROLLBACK. This would also give much better performance. [utk.edu]

      Reasons not to use foreign keys. There are so many problems with FOREIGN KEYs that we don't know where to start. [utk.edu]

      I decided long ago that the MySQL guys are clowns. MySQL's lack of features was never as big a problem as the fact that I just couldn't take these guys seriously (and the above is only a small subset of the reasons for that).
      • I've not worked with MySQL outside the hobbyist PHP/MySQL personal website, so I really didn't get into the guts of MySQL.
        Looking at those links...Holy Hell! Someone willing uses this thing for anything more than the PHP/MySQL home page? I can see where one could forgive the lack of foreign keys. The complaints listed against them are mostly valid. Still, outside of very basic applications the extra checks on the program logic are well worth the extra overhead. This could put the database team in a si
    • Even worse is license confusion.

      MySQL's dual-license scheme is about the most complicated thing on earth. Do I have to pay a licensing fee for this install? Who knows! Maybe a highly-paid lawyer, but no mere mortal can figure it out.

      I dunno, maybe this was a few years ago, but it was definitely a huge problem then. Since the DB had to be (basically) embedded, and was going to stay small and mostly static, I actually opted for SQLite instead. No confusion about SQLite's license.
    • Kudos to you Shielfw0lf. I worked on an enterprise project using MySQL. I'd used it before on hobbyist/home-project/web-sites and thought it was waaaaaaaaay cool. But when we started working on, man, we found it so painful. Often The indexing system is insane (only one index can be used per query), and it was very buggy. MySQL InnoDB was better, but even it suffered from 'epic rollbacks' that would take hours. Things often wouldn't work properly: You'd find simple expressions that wouldn't evaluate properly
  • What's your opinion (Score:4, Interesting)

    by CastrTroy ( 595695 ) on Wednesday April 18, 2007 @02:38PM (#18786863)
    I would like to know what slashdotters think is a good level of stuff to be putting into stored procedures. I've seen organizations where every single select query is put into a stored procedure. I've also seen places that avoid it like the plague. Personally I like to keep as much business logic as possible out of the database, but I realize it can speed up things considerably, so I use it where speed is critical. Is there any hope that stored procedures will become cross platform and work on all databases, at least to the level of SQL, so that there's some kind of standard, or do they just push us towards vendor lock-in?
    • by Tony ( 765 ) * on Wednesday April 18, 2007 @03:00PM (#18787195) Journal
      Stored procedures should be used to enforce data integrity and data access. The only "business logic" that should be there is the logic that applies to keeping your data whole, complete, and coherent.

      Middle-tier application layers are great to help pull data together, present model-specific views of data (say, OO/R mapping, if that is what gives you a chubby), and provide update interfaces. They can even do a first pass at making sure the database will accept the data.

      But.

      The data logic should be stored firmly in the database logic itself, using stored procedures and triggers and rules. RDBMS engines are *designed* to keep your data in good shape. Use them in that fashion, and you will be plenty happy. Don't, and you risk losing data integrity, and you sacrifice security.
    • by sammy baby ( 14909 ) on Wednesday April 18, 2007 @03:02PM (#18787221) Journal
      Oh man, talk about a can of worms.

      On the one hand, folks who are trained to think in terms of data relationships and database development are liable to want to put as much as possible right in the database.

      On the other hand... well, forget it. There is no other hand, it's more like a shifting mass of appendages, like Shiva [wikipedia.org] on an acid binge. The other extreme are people like David Heinemeier Hansson, who want to use database to store information and otherwise stay the hell out of the way - as I believe he put it once, to be as dumb as possible.

      That may be a minority view, but the minority isn't exactly vanishingly small. eBay, for example, not only skips out on transactions (you know, the thing people like to beat up on MySQL for not having years ago), but doesn't even enforce referential integrity in the database. Stored procedures are right out. (warning: reference is a PDF [singleobject.org].)

      My own personal, under-informed and probably worthless view: I like enforce referential integrity where I can in the DB, and transactions are a good thing, but stored procedures are better left to maintenance and administration functions than anything involving business logic.

      • Re: (Score:2, Interesting)

        by PRMan ( 959735 )

        I'll probably get completely trashed for this advice, but I find the following run counter to "the standards", but to be essential for good database performance.

        1. CRUD procedures are often bad for performance. People will send 100 individual queries to the server to do something that could be done in 1. This is common. Or, the middle tier will send 100 queries to the database to do the work of 1. Whatever. In either case, it's bad.

          As long as the Stored Procedures/Middle Tier are dealing with singl

        • I don't know about trashing you, but I don't really agree with you.
          Well written CRUD procedures will make everyone's life better. The application developer doesn't need to know the underlying data structure, and that structure can be changed to deal with modifications in the database, if there is a need. While it's nice to think that a database will be designed to handle all eventualities, this is not likely to happen in reality. If data access is handled through a standardized set of SP's, those can be
        • Re: (Score:3, Interesting)

          by nuzak ( 959558 )
          > Transactions are really bad for performance.

          Unless you're using postgres, in which case your performance goes to shit if you DON'T use one. My results with oracle have been mixed -- I suspect, as with all things oracle, it depends on the configuration.

          > ... Why do you want to hold up the entire database when someone accidentally pulls the network cable on your PC?

          What kind of brain-dead database would implement all transactions with a global lock?

          As for Dynamic SQL, it certainly has its place, but
        • by shutdown -p now ( 807394 ) on Thursday April 19, 2007 @02:48AM (#18794725) Journal

          Transactions are really bad for performance. Really bad.
          This was true for those RDBMSes which used locking, but now that more and more are moving to versioning (PostgreSQL, Interbase/Firebird, SQL Server 2005, and I believe Oracle), it changes. You get isolation level that is almost equivalent to ANSI SERIALIZABLE, and it's cheap as well.
    • Re: (Score:3, Insightful)

      by arivanov ( 12034 )
      Nothing.

      I am fully aware that I would be flamed to death by ACID zealots, but I will again repeat nothing.

      We are in 2007. Using non-OO fortran-like obscenities dated 1993 instead of looking at the calendar and getting a grip with reality gives you exactly that - nothing.

      There is a reason why banks, govt, etc has been looking more and more at middleware layers on top of databases. You get the same you get with stored procedures while still having modern data and code representation.

      Similarly, the little engi
      • by F1re ( 249002 )
        fortran? wtf? That doesn't make any sense. Did you mean cobol?
      • Re: (Score:2, Insightful)

        by Anonymous Coward

        I am fully aware that I would be flamed to death by ACID zealots, but I will again repeat nothing.

        You mean, people who actually know something about data modeling?

        We are in 2007. Using non-OO fortran-like obscenities dated 1993 instead of looking at the calendar and getting a grip with reality gives you exactly that - nothing.

        Well, sonny, this might be before your time, but do you know how they wrote apps in the 60's and 70's? That's right. Everything was in the apps. Everybody was creating their

    • Re: (Score:3, Insightful)

      by shatfield ( 199969 )
      My opinion? I'm glad you asked :-)

      Rule #1 of Software Development in the 21st century:

      Don't put any business logic into sprocs.

      Why?

      It's very simple really, and very logical.

      1) Only CRUD operations should be in sprocs. These sprocs are designed to allow someone to create/read/update/delete data in the tables in the database without giving the user access to or knowledge of the underlying table structure. Use application roles (approles) to allow access to the tables. This keeps people from loading up your
      • by turbidostato ( 878842 ) on Wednesday April 18, 2007 @09:12PM (#18792053)
        "Don't put any business logic into sprocs."

        Do put critical enforceable bussiness logic (and I mean *bussiness* logic, not application logic) as near as possible to the data (and that usually means SP).

        "The second that you place a business rule into a sproc, the users will want the rule changed"

        That's true. And that's an advantage of stored procedures: they won't be able to change them (that's why I talked about Critical-Enforceable-Bussiness-Logic).

        "Why is this bad? Because sprocs are almost always under the control of the DBA"

        Why is this good? Because sprocs are almost always under the control of the most data management knowledgeable techie round there.

        "most of the time there is a layer of politics involved between DBAs and Software Developers"

        And that's good because that refrain them from their need (either because management pressure or pure ignorance) to do the thing the Real Stupid Way just because it's the fastest/the only way they know.

        "What usually happens is that the dev will make the change to the business logic in the middle (or even worse, GUI) tier, thereby doing twice as much work"

        So you say that such a bussiness logic should go into the middle tier instead of the RBDM because in that case the developer would do a stupid thing -like expressing it in the middle tier? This is both a circular argument and one more reason to put those kind of rules *out* of the reach of such a stupid developer.

        "Adding Database servers to a cluster isn't cheap. If you have a lot of users, and you have had to cluster your servers to accommodate more users..."

        Then you need to add more database horsepower. If you need to push or pull more data from the place the data is stored... well, you need it. No middleware is going to change that.

        "Adding more middle-tier servers is much cheaper"

        Yes. And buying a 1GB pen-drive is even cheaper than that, having in common with your "solution" that they both have nothing to do with the problem at hand. You either need to pull/push more data from where it resides or you don't. In the first case you always need more database horsepower; in the second you won't need it (and if cacheing is a good solution to your current problem then no, your problem is not that you need to push/pull more than provided and no, a cacheing solution is not a "middleware").

        Resuming:
        You will want stored procedures for your critical enforceable bussiness logic because:

        *Developers tend to suck regarding data access/management (design, integrity or efficency); DBAs a little less so (it's the work they are focused on, after all).

        *No matter how good your bussiness logic implementation on your new shiny app is, tomorrow it will be developed a new app that will access the same dataset (like the example you talk about people pumping data from Excel -presumably instead of through your pretty web app that tried to enforce this or that rule) and will surely break some bussiness logic or at the very least you will need to reimplement them again. If you don't want this to happen, enforce the rules as near to the data as possible so there's no way to overrun them.

        *Your managers are crazy. It's much more probable that your new manager (or the old one if it happens to read the last shiny brochure from "PHB's IT") decides to rewrite all your .Net software to Java or the other way around than to move from Oracle to DB2 (if just because -as you already said, privative RBDM licenses and support are *very* expensive to play with them and they are buried more profoundly in the caves of the black teachies so they make for not as good PR as a new front end with a new brighter colorset and round corners). Go defensive and give your bussiness rules a sanctuary against crazyness within your RBDM (I now this seems to be against common wisdom: the most you program as SP, the most locked to the RBDM you are. But while that's true in theory, my experience in the Real World-TM is that more often than not it is the datastore the one that lasts longer than the apps over it).

        *Anyway, your mileage is your mileage: think it hard, think it deep and reach your own conclusions.
    • > I would like to know what slashdotters think is a good level of stuff to be putting into stored procedures.

      Here's an example:

      On a current project I've got a separate department of users who have written a reporting app in actuate against a db2 reporting database (a datamart). Along the way we've found that this team is not highly skilled in sql and often had to rewrite some of the sql to fit it into their tool. Note that this can be relatively complex sql - involving temp tables, etc - in order to sh
      • Re: (Score:3, Informative)

        also, if you put this level of detail (see parent) into a stored procedure then it is much easier to unit test the database separately and hand over reponsibility of that unit test to the "database team". It allows the database element to have a version on it's own independant of the source code.

        I find that (in big teams, where multi-tier applications are being produced) it is far better to maintain tier separation and avoid having sql code in the app servers or worse, the client - because any minor data

    • by nuzak ( 959558 )
      > I would like to know what slashdotters think is a good level of stuff to be putting into stored procedures.

      That's like asking how much abstraction you should use in an app. There's no one right answer.

      Ideally, pretty much everything that constitutes an "API call" should be a SP. Single inserts, reads, deletes, updates, especially when they have to use a transaction to coordinate across tables. Anywhere where you're using a cursor but don't want it leaking out to have an indefinite lifetime. Anythin
    • We use stored procedures where multiple tables need to be updated at once, and where that series of updates will be called by more than one application.

      Basically, we use most of the same logic you'd use when trying to decide whether to refactor a function. If a query, however complex, is only called from one place, then we leave it be. However, we don't want to have the same set of queries copied-and-pasted through 6 apps in 4 different languages if we can help it.

  • Stred pocedures (Score:5, Informative)

    by karavelov ( 863935 ) on Wednesday April 18, 2007 @02:38PM (#18786873) Homepage
    "The major commercial RDBMS vendors -- including Oracle, IBM, and Microsoft -- could point to this deficiency as reason enough to choose their proprietary sstems over MySQL or any other open source system, such as PostgreSQL..." They could not point this because PostgreSQL has stored procedures for decades... fully tested, stable, offering e bunch of languages for writing functions/triggers, including Perl, Python, Tcl and their own PlSQL that is very close to Oracle's variant.
    • reason enough to choose their proprietary sstems over MySQL or any other open source system, such as PostgreSQL...

      I can only think that was a poorly written sentence, and what they really meant was:

      reason enough to choose their proprietary sstems or any other open source system, such as PostgreSQL, over MySQL ...

      The way you interpreted it makes no sense at all, even though you parsed it correctly. I have to assume they didn't really mean it that way.

  • by moore.dustin ( 942289 ) on Wednesday April 18, 2007 @02:44PM (#18786965) Homepage

    if((estimated_rows_in_table($table) < 100000)) {
    return true;
    }
    else {
    return false;
    }
    • by gusx ( 898415 ) on Wednesday April 18, 2007 @02:48PM (#18787019)
      How about...

      return (estimated_rows_in_table($table) < 100000);
      • by suggsjc ( 726146 )
        I'm a little confused. I thought that this post should be modded insightful for offering shorter more efficient code, whereas the GP was the one actually making the joke (although there may be some truth in it).
      • by Ecks ( 52930 )
        Although I am a PostgreSQL proponent, I've got to say that mysql will happily handle > 100000 rows in a table. Especially if you properly normalize your tables. I ran a virtual inventory application on MySQL which tracked well over 100000 items (assigned and available IP blocks, atm virtual endpoints etc) for a medium sized ISP. I'm currently building a small decision support application. One of my tables has 8000000 rows in it. It's used twice in a query and that query takes no more then 0.1 seconds to
    • by coyote-san ( 38515 ) on Wednesday April 18, 2007 @03:37PM (#18787699)
      Even that is generous. If you want to use a database as a simple store (and if they've fixed the tendency to hiccup and corrupt the database), MySQL may be acceptable.

      If you want a DATABASE it's not even on the table, no pun intended. The whole point of a RDBMS is that it isn't a simple store, it's a mechanism for ensuring that your collection of data is always in a sane state even if you've brought in some clueless interns for the summer or you have a disgruntled employee. Or even if you just have two developers (or one developer with a poor memory).

      ACID and referential integrity are two items that are absolute requirements. Calling something without these features a 'relational database' puts you in the same pointy-hair territory as Dilbert's boss saying that he heard the 'mauve' databases were best.

      Attribute constraints, triggers and stored procedures aren't as necessary, but they're still extremely powerful ways of ensuring the sanity of your data. Use a trigger to update a 'updated_on' field, don't just trust the developer to always update it. Use an attribute constraint to ensure that you color field is always 'R', 'G' or 'B' (or just use referential integrity to point to a color table).

      Finally, to address a question asked elsewhere stored procedures are extremely powerful security tools. By now everyone should know that using string concatenation to prepare queries is a Very Bad Idea. A potentially "don't let the door hit you in the butt on your way out" Bad Idea. Prepared statements are better, but how can you enforce it?

      Stored procedures give you an alternative. Drop INSERT and UPDATE rights and force everything to go through a corresponding stored procedure. It's a little more work but it should eliminate any risk of SQL exploits. (It's not a 100% guarantee since you can't eliminate the risk that the database itself can be compromised by carefully selected parameters.)
    • Re: (Score:3, Informative)

      by LordLucless ( 582312 )
      Actually, if all you want is a big table, MySQL is probably a good choice. It's generally very fast. However, as soon as you start getting a complex database schema, you're probably starting to look at other RDBMSs. MySQL provides a lot of advanced features with InnoDB, but then, InnoDB has just been bought by their biggest competitor. If you're needing any of those features (foreign keys, transactions, etc), then I'd be going with PostGreSQL, because, really, I don't think the InnoDB team is going to be re
    • by consumer ( 9588 ) on Wednesday April 18, 2007 @04:02PM (#18788079)
      I'm currently looking at a table on a production MySQL db with 176 million rows in it. It has no problems at all, other than being a huge amount of data. Your ideas about MySQL's limitations are not based on fact.
      • by kpharmer ( 452893 ) on Wednesday April 18, 2007 @04:51PM (#18788771)
        > I'm currently looking at a table on a production MySQL db with 176 million rows in it. It has no problems at all,
        > other than being a huge amount of data. Your ideas about MySQL's limitations are not based on fact.

        Without partitioning you face the choice of selecting data only via a btree index (only typically works if you need to select less than 3% of the data) or scanning it all. With a more typical alternative (certainly db2, oracle, etc) you can partition the data. This can result in 10:1 differences in performance between mysql & db2/oracle for typical reporting queries.

        Without query parallelism you're single-threading all of your queries, and unable to take advance of those extra processors. Since oracle/db2 get near-linear performance benefits from parallelism, you're again suffering a 4:1 performance penalty on a four-way smp.

        Without a robust optimizer you will choke on complex queries against even moderate data - so a query that joins a dozen tables together will inevitately go into the ditch with poorly chosen nested-loop joins. Performance penalty? could easily be 100:1 in some situations.

        Of course, this doesn't mean that you can't keep 200 million rows in msyql - you certainly can. Just don't plan to get the same kind of performance out of a lot of typically complex queries against it - that you would get from oracle/db2/informix or even sql server. Not unless you spend 20x as much on the hardware anyway.

        > Your ideas about MySQL's limitations are not based on fact.
        Unfortunately, your ideas about mysql's capabilities are based upon insufficient experience
        • Re: (Score:3, Interesting)

          by Ant P. ( 974313 )
          "Without partitioning [mysql.com]"? What are you trying to say, that db2/Oracle doesn't have such a basic feature?
        • Re: (Score:3, Interesting)

          by Dirtside ( 91468 )

          Unfortunately, your ideas about mysql's capabilities are based upon insufficient experience

          Ok, choke on this then: I work for a company that runs exclusively MySQL. We have 1,500 tables across our *primary* DBs (that's user-facing data) containing a little over four billion rows. Most of the queries are simple because they're primary-keyed returning single rows, but our largest tables contain 100-200 million rows and are subject to several thousand queries per second.

          And we have fewer problems than we did

      • Re: (Score:3, Insightful)

        All of this is of course based on the scope of the project, but if you are serving up information to a browser, there is certainly a number of queries that will show MySQL's shortcomings. We can argue for ages about what can and cant work for this or that project, but all I was trying to convey was that for any project of significant size or importance, MySQL is not the best answer. It may be an answer, just not the best.
      • Re: (Score:2, Interesting)

        by JAlexoi ( 1085785 )
        I am currently looking at a table with only 17 million records.
        I know that there are inconsistencies, I am just afraid to search how many are there.
        And that including the FACT that there were NO crashes EVER.
        Fortunately NO ONE ever needed 100% consistency on that database, and people will probably "pay" for that.
  • by Tim Browse ( 9263 ) on Wednesday April 18, 2007 @03:56PM (#18787993)

    it was nice to see him poke some fun at the database heavyweight, in his choice of sample code to demonstrate the my_replace() function:
    my_replace( 'We love the Oracle server', 'Oracle', 'MySQL').

    The long Winter evenings must just fly by.

  • While they are certainly useful in certain situations, they are a pain in the ass to debug. It would be nice if they could add some sort of vendor specific command - anything - that would allow me to see output in a console while a stored procedure/function is running. They are useful at times, but i dread writing them.
  • by ScrewTivo ( 458228 ) on Wednesday April 18, 2007 @05:35PM (#18789327) Homepage
    I'll have to put on my flame suit for this one only because so many interests are out here defending non-defendable territory.

    Why does everyone love CSS for separating content from format .... then turn tail and try to put business logic into the database tier. Try moving a large MS-SQL app that utilized stored procedures to Oracle or MySQL. Tell the wife you'll see her next year!

    Presentation - Logic - Storage. Clean and simple. Stored procedures and triggers are nothing more than DB-CRACK. Easy to use in a "pinch" yet keeps you addicted forever.

    The concept of moving trigger/stored procedure coding out of the database engine is the scariest thought for Oracle/MS/IBM....yet it works surprisingly well in the freebie MySQL.

    This subject is so deep and broad it leaves the mega dollar database companies room for more FUD the HS in NYC in 1905 (check that one out in your database).

    SCALE THAT IN YOUR BOARDROOM!

You can tune a piano, but you can't tuna fish. You can tune a filesystem, but you can't tuna fish. -- from the tunefs(8) man page

Working...