No triggers, no stored procedures - no love

djberg96 on 2003-03-24T06:16:10

For some reason I thought MySQL added stored procedures and triggers in 4.x. Apparently, I was mistaken. I'm glad I found out, though. One of my colleagues was thinking of switching our database to MySQL if company negotiations with Oracle broke down. Without stored procedures or (especially) triggers, I'd say there's no chance of that now.

Where does that leave us if Oracle goes bye-bye? Hmm...PostgreSQL has both. :)


once again proving...

merlyn on 2003-03-24T07:05:35

PostgreSQL is a "real" database... a valid open-source replacement for most of Oracle, while MySQL is merely a step up from using BerkeleyDB for structured storage.

I can't recommend MySQL for any new installations any more.

MySQL does a job and does it well..

TeeJay on 2003-03-24T09:56:01

..you don't always need the 'power' of databases like Postgres and Oracle.

I still use mysql for a lot of reasons

  • Its very easy to manage, install and administer
  • Easy to secure
  • Some of the best full text searching available - far better than any of SQL Server, Oracle or Postgres.
  • Provides the features and SQL that I need for most web development tasks.
  • Very very good documentation and support.

Don't go writing off mysql because it doesn't provide triggers or stored procedures - these are hardly requirements to qualify as a real RDBMS.

Its much improved support for full text indexing and transactions in version 4 means that it is up to the job for most tasks.

Should you need any more power - it is relatively easy to combine with postgres and pretty simle to migrate parts to Postgres.

When I worked in bristol we had MySQL and Postgres working together, we were moving parts of the system bit by bit to postgres from MySQL and it went very smoothly.

Re:MySQL does a job and does it well..

djberg96 on 2003-03-24T16:13:26

Oh, I'm not writing off MySQL as a "real" RDBMS. I certainly didn't mean to imply that I thought MySQL sucked or anything because it lacked these features (and I'm aware they're being added in 5.x).

The problem is that there are certain business rules we simply can't (or shouldn't) get around without triggers and so MySQL is simply out of the question. Now, if MySQL adds these features (and they get good reviews) by the time we *do* switch, I'll be happy to look again. :)

Re:once again proving...

ziggy on 2003-03-24T14:36:06

PostgreSQL is a "real" database... a valid open-source replacement for most of Oracle, ...
For the task of migrating an existing commercial RDBMS to an open source one, PostgreSQL is certainly the best choice today. Open Source software is nothing if not dynamic. Most people who write off MySQL do it with old information. MySQL has supported ACID transactions for a while now, and stored procs are being demonstrated live next month at the MySQL User Conference; expect stable, production-grade stored procs in MySQL by the end of the year at the latest.

For people who are migrating a simple schema (e.g. no triggers, no stored procs), MySQL is certainly an acceptable and a defensible choice.

... while MySQL is merely a step up from using BerkeleyDB for structured storage.
I'm quite surprised to see someone who waves the TMTOWTDI flag and actually teaches the principle of TMTOWTDI to paying students assert that there is only one real choice in the rather vibrant world of open source RDBMS servers. Asserting that PostgreSQL is the only "real" open source database is just spreading FUD and snobbery. The situation changes quickly, and MySQL development versions support stored procs today, so I'd expect to see them in production later this year. Surely the story for triggers is similar.

It's been a long time since I looked at it, but Firebird certainly deserves a look.

And lots of people need a simple, fast SQL database engine. In situations with many readers and few writers, MySQL is a perfect solution. (Yes, it's ACID compliant...) If I had a high throughput problem I needed to solve, I'd look at MySQL before PostgreSQL any day of the week.

Then there are the people who need embedded databases. I'm using SQLite for a few projects I'm working on at the moment. After talking to David Axmark last week, I'm seriously considering switching to embedded MySQL. I don't think embedded PostgreSQL is an option. Interbase used to be embeddable; I don't know if Firebird is.

I can't recommend MySQL for any new installations any more.
Um, there are plenty of reasons to recommend MySQL for new installations. Not everyone makes decisions on a pure technology basis or even from a my feature list is bigger than your feature list perspective.

MySQL has a much more vibrant user community around it. Someone who is not a dba and doesn't want to become one is more likely to find an anwer to a MySQL dba question much more quickly than they would a PostgreSQL dba question. Why? Because practically everyone and their pet rock have some experience with MySQL. Plenty of smart people have no hands-on experience with PostgreSQL. Sure these issues aren't difficult to figure out, but a lot of people don't have an answer on the tip of their tongue, nor do they know if a problem has a 30 second fix, or if they need to spend 15 minutes reading the docs to find the 30 second fix.

And don't even get me started with add-on tools that are available for MySQL but not PostgreSQL. Add all that up, and it makes MySQL a much better fit for a set-it-and-forget-it type installation.

For someone who is just playing around, MySQL is also a better choice than PostgreSQL, because there are more books, articles and websites aimed at learning database theory centered around MySQL than SQLite, Firebird, PostgreSQL or Joe's SQL. (This is the Torkington Principle applied to databases: «MySQL is a great first database to learn, but PostgreSQL is the last database you ever need»)

No, seriously

gnat on 2003-03-24T10:56:19

I hear good things about Microsoft's SQL Server. No, really. And it's a small fraction of the price of Oracle.

--Nat

Re:No, seriously

djberg96 on 2003-03-24T16:01:40

I'm not sure if I should mod this as "Funny" or "Troll" - perhaps "Funny Troll". :-P

I have this nagging suspicion that MS SQL Server will become the replacement if Oracle goes away. SQL Server has some serious issues. First, it doesn't run on Solaris (does it?), which would mean the company would probably have to buy new hardware. Second, anyone remember Code Red?

I can't speak for other groups in the company but I can tell you that *our group* won't be using it.

run away!!

TeeJay on 2003-03-24T17:26:00

SQL Server has plenty of nasty dis-advantages.

Its JDBC and ODBC drivers are second-rate.
Its full text searching is frankly rubbish.
Its error messages are frequently unhelpful.
It requires a lot of hardware and nursing and coaxing into working.
Its clustering, backup and synchronisation leave a lot to be desired as well.

Re:run away!!

gnat on 2003-03-24T21:57:02

How odd. My uncle has been running it in hundreds of customer sites, managing inventory and sales for clothing retailers, and he has nothing but praise for it. As always, I guess, YMMV.

--Nat

Re:run away!!

TeeJay on 2003-03-25T08:54:41

Indeed Mileage will vary, just more with some databases than others.

Bear in mind also - where I worked previously was an MS shop, they had a huge number of problems with SQL Server, but the boss loved its GUI and thought microsoft could do no wrong.

I would never reccomend SQL Server for ecommerce for the simple reason that it has severe data corruption, security and searching issues and these are critical for ecommerce.

Coming to mysql

delegatrix on 2003-03-24T13:58:07

Stored procedures are being written into v5 of mysql.

Stored Procedures

belg4mit on 2003-03-24T15:10:46

http://software.tangent.org/projects.pl?view=myperl