Slashdot Mirror

← Back to Stories (view on slashdot.org)

PostgreSQL vs. MySQL comparison

Posted by ryuzaki0 on from the get-the-morning-starter dept.

prostoalex writes "Ever find yourself wondering which open source database is the best tool for the job? Well, wonder no more, and let your tax dollars do the work in the form of Fermi National Accelerator Laboratory publishing this unbiased review of MySQL vs. PostgreSQL. After reading it, however, it seems that MySQL ranks the same or better on most of the accounts." My poor sleepy eyes misread the date of posting on here; caveat that this is more then 15 months old.

4 of 390 comments (clear)

  1. Re:Foreign Keys by mwanaheri · · Score: 5, Insightful

    Foreign keys are more than nice, they are essential. Unless, maybe you don't care about the integrity of your data or want to make the necessary checks in their application. The latter should keep their eyes down and their mouth shut if the talk is about 'speed' of any rdbms, off course.

    --
    Idha khatabahum lijahiluna qalu salaman
  2. Re:MySQL is ridiculously easy to configure by Schraegstrichpunkt · · Score: 5, Insightful

    You have to give the Notepad guys credit for the fact that it is an incredibly easy product when it comes to configuring it for your needs. For me, out of college, going to Vim was a culture shock because the process of learning Vim was so convoluted and drawn out for simple stuff. I know that Vim and Emacs can be much more powerful than Notepad, but there is something to be said for how easy it is for a developer to install Notepad and just start working with it.

    --
    http://outcampaign.org/
  3. Re:Foreign Keys by CaptainZapp · · Score: 5, Insightful
    Foreign keys are more than nice, they are essential.

    Bingo!

    It doesn't cease to amaze me, when the Mysql croud argues that "you don't really need those pesky integrity stuff, it just slows down the database."

    Guess what guys; You're dead wrong!

    Any DBA worth his salary will enforce data integrity on the lowest possible level, which means constraints (however implemented) on the object level.

    Sure, you can let your coders in Bengaluru ensure that the primary key is unique instead of just applying a unique index and the same goes for referential constraints between tables. You can implement them in the application just fine until somebody overlooks some minor detail in the code and you're royally fucked!

    Again! Foreign keys or triggers are not "niceties". They are essential in implementing an industry strength database; period!

    --
    ich bin der musikant

    mit taschenrechner in der hand

    kraftwerk

  4. Re:Foreign Keys by Branko · · Score: 5, Insightful
    Your app should be checking itself anyway.

    Actually it shouldn't (in this context). Typically, one database will have several client applications attached to it. If data consistency is not checked at DB level, then:

    • Bug in single application might compromise the data consistency of the whole system.
    • You must keep all of your applications precisely synchronized.
    • You are repeating the job of implementing the same consistency logic across all applications instead of implementing it only once - in database.
    • Implementing these sorts of checks can be difficult to do correctly at the application level in a concurrent environment typical for a DBMS.
    • Data consistency at DB level is directly supported by modeling tools, so you can plan for it and visualize it early enough to spot problems and communicate it to the other team members more easily.