The Death of PostgreSQL...maybe!

I was just wondering what everyone thinks about MySql taking over SAP DB?
http://www.internetnews.com/storage/article.php/2212341

...with SAP throwing their weight behind MySql is Postgresql/Firebird going to be lost.

I don't know about PostgreSQL, but as a user of Firebird I see no need to worry. Firebird is in a completely different league compared to MySQL and it would take an awful lot of work to make MySQL suitable for those situations where Firebird really shines. Likewise, if you are satisfied with MySQL you probably do not need the functionality of Firebird with its overhead.

And - if I should be proven wrong - it is no big deal if I have to change from my beloved Firebird - provided the replacement would be a better database, of course. It would just save me the $300 per year which I as a member of the FirebirdSQL Foundation pay to secure the future development of Firebird.

I am an ex-MySQL user who is glad to see MySQL continuing to expand and make inroads into new areas. Good for them.

But just like Oracle, DB2 and SQL Server can't seem to run each other out of businesss, I don't see a MySQL/SAP amalgam killing Postgresql or Firebird. One thing that Firebird has going for it is a well-established base of Interbase customers. I imagine that the Postgresql base is pretty substantial too (I bet there are more Postgresql installations than Firebird but just out of curiousity, I wonder how Postgresql measures up against Firebird + Interbase...I wonder which is bigger).

In order for people to switch to MySQL/SAP, it will have to offer something that the other databases don't have. That will be kind of tough since both Postgresql and Firebird offer a lot of features. Nobody is going to go through the pain of migrating to a new database if they don't get some "have to have" feature. Even if this does leapfrog MySQL forward, both Postgresql and Firebird will continue to add features as well.

The main thing I think this will do is keep current MySQL customers from outgrowing MySQL and jumping to another database when they run up against one of MySQL's current limitations.

Well I've never used SAP DB so I may be ignorant on this issue, but after reading the article it just seems that MySQL AB is repackaging and releasing SAP DB under its own name as a separate product from what they call "MySQL Classic." Since I haven't used it I'm guessing that SAP DB has some of its own proprietary data types and syntax that will make migrating from MySQL Classic to it a bit of a chore. While I don't doubt that it's a good move for MySQL (the company) in that it will get them more exposure and also a good code base for them to look through, I'm not so sure it's an immediate technological leap forward for MySQL Classic.

Even if it is, the only way you'll take Postgres from me is from my cold dead hands....

In my eyes the only that'll stop Postgres and Firebird is if the core developers/community stop it themselves either by going in a totally backwards direction or ceasing to develop and support it.

-b

I gave SAP a cursory glance a while back. It seemed to have a lot of features but I saw a couple of items that caused me to wonder if it would be the right database for me. One item was that there was not a C API. The only method of connectivity on the Windows side was ODBC or JDBC. On the Unix side you used embedded SQL with a precompiler.

I like using C++ Builder / Kylix 3 with Firebird because I can program the same way using the same API for either Windows or Linux.

SAP did not appear to be the database for me so I have no plans on switching. It will still be interesting to see if the combination of the two will make both better: a case of 1 + 1 = 3.

No, I think it will be a case of 1+1=1.5.

Hehe... reading about the MySQL/SAP arrangement was one of the better laughs I have had all year.

Of course, there is no way in any reasonable time that SAP DB will become part of MySQL as a "code merge" (a ridiculous concept anyway). So yes, I would imagine it would just involve a repackaging of SAP as MySQL-Relational, or something like that ;-). MySQL has tried to make a career out of incorporating 3rd-party table types anyway, but this is a completely different animal, and I don't expect to see the "MySAP" table type as a part of regular MySQL anytime soon...lol. (But ooohh... I just hope they repackage SAP as MySAP...)

To me, what this really shows is that the traditional MySQL will eventually go the way of the dinosaur. The MySQL guys are finally realizing that moving from what they had to a fully (sorta) relational SQL enterprise system is a bigger task than they thought. In fact, I suspect that the codebase is somehow fundamentally broken for handling the more advanced stuff. Even their furthest roadmap doesn't show them developing relational capabilities like constraints and domains anytime. Even views, which are one of the fundamentals of relational concepts, aren't due until version 5.1. And, by the time MySQL 5.1 is available, who knows where PostgreSQL will be in terms of ability?

So, I see this as an act of desperation on both parties. SAP realizes that, while they have a good DBMS, it's kind of an albatross around their neck, for various other reasons: as I understand, the codebase is a little strange. Many core parts of SAP DB are written in Pascal, and then there is a step in the compile process that converts the Pascal to C before final compilation, in order to get decent performance. Most people who have used SAP DB seem to have many problems installing and configuring it, so in that sense it is just the opposite of MySQL. It is definitely much harder than compiling and configuring PostgreSQL.

As far as I can see, SAP has exactly two advantages over PostgreSQL:
1. Subtransactions-- so individual operations in a transaction can be comitted or rolled back without canceling the entire transaction. Even then, this is somewhat limited, and cannot be part of a trigger, for example.
2. Clustering capability, such as supporting Microsoft cluster server.

Other than that, SAP DB does have some limitations that don't look too good, compared to PostgreSQL, such as the old 8K row-limit (as with MSSQL), and a few other odd limitations (3 triggers maximum per table, etc...). Also, SAP DB doesn't have PostgreSQL's extensibility, with user-defined types and operators, multiple procedural languages, etc...

So, I don't really foresee the MySQL developers actually developing SAP DB further. I foresee them using it as a way to say "see, we have that enterprise stuff also", as a stopgap while they figure out what to do next. Honestly, I expect sooner or later for both MySQL and the SAP DB codebase to be ditched.

Ouch! That's cold.

But based on your arguments, quite possibly very accurate...I was just trying to be optimistic.

Well I think its more the death of the current MySQL than the death of anything else.

Well if MySQL goes the way of the dodo I will dancing and singing upon its grave

I can only pray MS Access goes the same way one day. I will be dancing and singing a heck of a lot louder when that happens

i don't know why you would say that

if you don't like a particular database, don't use it

how can other people using it, and using it successfully, possibly bother you?

where does the antipathy come from?

mysql and access are extremely popular, very capable, totally satisfactory solutions for some people

live and let live


rudy

Sometimes we dont have a choice but to use a technology.



Settle.... I never said that it bothered me did I?



Just because something is popular doesnt mean its good. I would never go as far as saying they are very capable. MySQL is a simple database solution, same as Access, and is great for learning. I don't view Access as an enterprise solution since it starts going funny when 10 or so people use it at once. MySQL is not a enterprise solution either, imo. It lacks many features that I would consider mandatory in a proper database.

There are better tools on the market that do the job a lot better than either one of these. If people want to use them, go ahead. I never said I had a problem with it.

I am happy that MySQL have seen the light and realised that what they have is a sub-standard product with not much hope of getting something decent out of it.

I did some really great programming with both Access and MySQL. I made some users very happy. But I kept bumping into the limitations of both so I moved on. I believe there are better products out there that are just as easy to use.

r937, if you're getting good use out of these products, then great. But don't take criticism of these products so hard. Everybody has their favorite. I use Firebird, rycamor uses Postgresql and we all think MySQL stinks. But ultimately, if you can make the users happy and you like it, then that's all that matters.

I had to write a program today using Access 97 because it was going on a Windows machine that's about 8 years old. My brain started to bleed trying to remember VBA, but I got a pretty cool 2-user, 6 table database with a switchboard and some smart forms thrown together in a couple of hours. It was the easiest way to solve this problem quickly so I used the best tool for this particular job.

C'mon rudy... didn't you know that software is war?

Yes, sometimes there is needless antipathy, but I have to sympathize with some of it. When you are required to use the wrong tool for the job too many times, you will celebrate the death of that tool.

I have done plenty of projects in both Access and MySQL (some that were pretty clever, IMHO), but for different reasons hope I never have to rely on either of them again.

Yes, I still can see uses for Access and MySQL. I can even see uses for delimited text files. But it continually amazes me the ideas some people get about fitting a square peg in a round hole. The other day, I actually had to talk a developer out of using MySQL for banking information ( I kid you not). I have seen developers use elaborate work-arounds to deal with business-rules-intensive systems in MySQL, when spending just a few days reading PostgreSQL, Oracle, or Sybase docs would save months of needless, buggy, always-delivered-late application code.

No, the problem is not with the tool itself, but with the application of said tool, or the downright disingenuous nature of the claims made by the developers. MySQL-- fine, but don't try to call it a "relational database management system", and claim that it can do the same things for you that Oracle can. In that sense, I actually have more patience with Access than with MySQL, because at least there is no exaggerated claim. Access handles most relational operations quite well, and if you want enterprise-level performance, you move the back end to MSSQL, of course; end of story. With MySQL, once you outgrow it, you have nowhere else to go, except a very painful porting procedure to get your data into a more capable system.

That describes my experience with both of them. I am forced to use wrong tool for job and try and plan way of converting to using proper tool. Not that easy once it has come to this level though