This discussion has been archived.
No new comments can be posted.
MySQL 5.0.0 (Alpha) Released
Related Links Top of the: day, week, month.
A computer lets you make more mistakes faster than any other invention, with the possible exceptions of handguns and Tequilla. -- Mitch Ratcliffe
Windows-like version numbers (Score:5, Interesting)
It would help if the major stable releases were
-Charles
Re:Windows-like version numbers (Score:5, Informative)
Not that uncommon (Score:1, Insightful)
Re:Not that uncommon (Score:3, Funny)
Re:Not that uncommon (Score:2)
Several hundred per second.
Re:Not that uncommon (Score:2)
Re:Windows-like version numbers (Score:3, Funny)
alpha, beta, release versions (Score:5, Insightful)
2.3 (released) -> 2.3.1a -> 2.3.1b -> 2.3.1 (released) -> 2.4a -> 2.4.b -> 2.4.1a -> 2.4.2a -> 2.4.3a -> 2.4.3b -> 2.4.4a -> 2.4.5a -> 2.4.5b -> 2.4.5 (released)
The versions released would be known only as 2.3, 2.3.1, and 2.4.5. 2.3 would be binary compatible with 2.3.1, and the same GUI and features, but 2.4.5 would only look and feel like 2.3, without binary compatibility (either data formats or APIs). This scheme makes version numbers actually useful, to consumers, new developers, and even automated interoperability systems (a la apt-get). It also offers an incentive to keep version numbers lower, as higher numbers reflect more changes (get it right the first time). At least in the minor and build/patch numbers. Most importantly, it reflects a reasonable test/revise/release discipline. So the numbers are the tail, wagged by the dog.
Re:alpha, beta, release versions (Score:3, Informative)
The added advantage is that they sort alphanumerically according to the order they were released in.
Re:alpha, beta, release versions (Score:2)
Re:alpha, beta, release versions (Score:2)
It results in a remarkable strong release system. Check out the release notes for 7.4.1: http://www.postgresql.org/news/169.html Almost none of these bugs would be considered a show stopper really. Als
Re:alpha, beta, release versions (Score:2)
Re:alpha, beta, release versions (Score:2)
Re:alpha, beta, release versions (Score:2)
Re:Windows-like version numbers (Score:4, Informative)
MySQL has often been described as more of an SQL-interface to a file system than a database.
Re:Windows-like version numbers (Score:2)
Another reason that MySQL is so fast is because of its query caching.
Re:Windows-like version numbers (Score:3, Insightful)
Re:Windows-like version numbers (Score:2)
Re:Windows-like version numbers (Score:2)
Re:Windows-like version numbers (Score:3, Informative)
Re:Discussion of MySQL should include MySQL gotcha (Score:2)
The technique is straight out of the AntiSlash Karma Whoring How-To -- don't let this jerk get away with it.
Re:Discussion of MySQL should include MySQL gotcha (Score:2)
It's also not a troll. Everything in that post is TRUE. While MySQL AB add functionality, they leave little broken parts all over in MySQL, and those parts need to be fixed. It's a reasonable complaint, and one that keeps me from recommending MySQL for most purposes. Sadly, the folks at MySQL haven't seemed real keen on fi
Re:Discussion of MySQL should include MySQL gotcha (Score:2)
No, but the fact that those links had been posted to this discussion several times already does. Thus,
-1 Redundant.
> and simply because it bothers you that someone would point out flaws in MySQL does not make it flame bait.
That's not what I said. This is not a case of "You dissed my DB so I hate you forever" crap, okay? Nor am I knocking the MySQL Gotchas, other than that they're formulated in such a way as to make the o
Re:Discussion of MySQL should include MySQL gotcha (Score:3, Interesting)
It would be a reasonable complaint if MySQL didn't have an ANSI-compliant mode, which it does.
doesn't fix all the problems. It fixes quite a few, but the ones that are left are still pretty nasty, imnsho.
Further, about Postgresql, you said:
2. The documentation is crap. Actually it's worse than crap, but going into that in detail would be off-topic. (Whereas the MySQL documentation is mostly very, very good.)
I call shenanigans. While
I wanted the graphic effect of the quirkiness. (Score:2)
Very nice (Score:2, Interesting)
This is sweet, professional level db programming for free might have an incredible impact on the web
Don't forget that most of your favorite sites probably use MySQL.
Re:Very nice (Score:1, Informative)
Re:Very nice (Score:4, Informative)
Re:Very nice (Score:3, Informative)
In my opinion, PostgreSQL is the superior database. Many of the features that are "alpha" in MySQL have been in PostgreSQL for years and are very mature. Using MySQL, there are features that I miss that are present in PostgreSQL. I haven't noticed the reverse at all.
However, there are a couple of very good reasons to use MySQL:
Personally, I couldn't care less about Windows support, but
Re:Very nice (Score:2)
That's been working for years on PostgreSQL. I just tried it again to be sure. PostgreSQL even outpaces MS's SQLServer.
drop table xfoo_a;
create table xfoo_a
(
a int
);
drop table xfoo_b;
create table xfoo_b
(
b int,
x text
);
insert into xfoo_a ( a ) values( 1 );
insert into xfoo_a ( a ) values( 2 );
insert int
Re:Very nice (Score:2)
Re:Very nice (Score:2)
Except that the original poster mentioned something or other about "free"...pretty sure MS hasn't started giving away MS SQL Server for free yet.
Great, (Score:1, Flamebait)
Re:Great, (Score:4, Interesting)
Re:Great, (Score:2)
Grandparent is a DB-fascist who doesn't think that programmers/admins are able to decide for themselves whether those features are needed in their particular application and thus should be required to use them in all cases.
AFAIC, MySQL's support of a diverse range of table types with differing feature profiles is one of the greatest features MySQL has.
Re:Great, (Score:2)
Choice is sometimes good, but being able to setup the database so as to not give that choice to users is also sometimes a very good thing.
Re:Great, (Score:2)
But why are differing table types an advantage? PostgreSQL only has one table type, and I don't notice anything missing from it. I am still waiting for a MySQL advocate to come up with some feature that makes it somehow more useful than PostgreSQL. PostgreSQL guarantees the enforcement of all of your rules (i.e. foreign key, all types of constraints, etc), database wide, no matter what. MySQL people argue all day about why they
Re:Great, (Score:3, Interesting)
What I've heard is MySQL's main point in favor (at least on the MyISAM table) is the performance, especially on a command sequence that largely consists of SELECTs, with comparatively few write ops. It is probably reasonable to suspect that at least some of that performance advantage over (as near as I can tell) every other SQL (or near-SQL) implementation comes from not implementing the extraneous stuff.
Thus, if you have an application where the queries are going to mostly be SELECTs (and the applicatio
eh? (Score:5, Funny)
And who is reading f$%king slashdot on Christmas Day too??
Oh wait.
Re:eh? (Score:1)
Re:eh? (Score:2)
Re:eh? (Score:2)
Re:eh? (Score:2)
I keep waiting for them to put a story about it being Xmas day on the front page so I can watch everyone say it's a dupe ('they posted this last year...'); I'm sure I'm not the only one.
If you look at the current poll [slashdot.org], it appears that 10% of Slashdotters will be coding...
Re:eh? (Score:3, Insightful)
Personally I will later on be celebrating the day by watching Return of the King
Re:eh? (Score:2)
I do (read my last two journals).
Re:eh? (Score:4, Funny)
People who care enough about stored procedures to ignore their family and check Slashdot. That's who.
Its all about priorities.
no letup (Score:2, Funny)
This rant brought to you by a Squadron of Attack Kittens.
Re:no letup (Score:1)
Most of the world does not celebrate Christmas, so why do you find it so amazing that people may be reading Slashdot on December 25th? Hell, I celebrate Christmas and am reading Slashdot because I don't feel like dealing with family.
I have to confess.. (Score:4, Interesting)
So, no, it's hardly Oracle, but even MySQL's alpha stuff seems to be reasonably usable, as long as you aren't doing anything too serious. And, as any database expert will tell you, you probably aren't going to be using MySQL for anything that serious anyway. Nice work MySQL.. I'll spare my users from an immediate upgrade to MySQL 5 however.. for now!!
MySQL, MySQL-Max, Enterprise RDBMS (Score:5, Informative)
It is quite interesting what they are doing with MySQL-Max with seems to be their enterprise solution. They teamed up with SAP DB [sapdb.org], an open source database technology that SAP bought from Software AG [softwareag.com] to tease Oracle a bit. It is based on Adabas D [softwareag.com] a commercial database that has a "oracle compatibly mode" via ODBC [cbbrowne.com].
It is quite interesting to see a mixture of SAP DB and MySQL united in MySQL-MAX. (Infoworld article) [infoworld.com]
Re:MySQL, MySQL-Max, Enterprise RDBMS (Score:2)
Adding features before "growing up" is not a good sign. I don't call adding features before essential functionality growing up.
About MySQL (Score:5, Informative)
Transaction support has been available with MySQL since 3.2x - that's over two years ago - you need to check what table type you are using. MySQL 4.x has replciation between master adn slave databases. Using replication you can easily do backups without taking down your live server. MySQL 4.1.1 Does subqueries. MySQL 5 should be where we get database clustering.
Now, if folk want to start criticising MySQL without complaining about these features being absent, that'd be great.
Re:About MySQL (Score:2)
Re:About MySQL (Score:5, Informative)
The reason people continue to say there's no tranaction support is probably because ANY other database out there does not require you to explicitly specify what type of table is needed to actually get transaction support.
I'll get modded as a troll on this one, but honestly, MySQL seems to do things opposite any other DB. The things you mention which are doable (transactions, subqueries) require significant rewrites to port an app to or from MySQL.
Re:About MySQL (Score:3, Informative)
There is an overhead to transactions and not every application requires transactions (for instance, a web board). Thus, having the flexibility to use transactions for some tables and not for others is actually a good thing. Use the right tool for the job.
Now if only InnoDB supported all the features of MyISAM...
Re:About MySQL (Score:2, Informative)
The only thing you need to do is change a line in the config file and specify the table type when creating the tables. I don't call that a significant rewrite to be honest. A simple search and replace would do it.
Re:About MySQL (Score:2, Troll)
Also remember transactions silently fail! You need to quadrouple check everything first since you cannot rely on the database to tell you something is wrong.
I simply cannot trust myself to use MySQL for important data. Too many things to double and triple check are *still* correct and properly const
Re:About MySQL (Score:2)
Re:About MySQL (Score:2)
> Now, if folk want to start criticising MySQL without complaining about these features being absent, that'd be great.
You bet - so when are they going to support a free online backup solution that isn't a complete hack?
I mean really - backing up your replication server? That's a pathetic solution...
backing up your replication server (Score:2)
In a way, it's pathetic that this is the only way to do it; in another direction, though, it's a very smart thing to move any activity that doesn't need to happen on the primary (bottleneck) server to a secondary server instead.
A similar practice is commonplace in the MS SQL Server world, running lengthly reporting queries on a secondary reporting database instead of on the primary.
MySQL Suitability for,,, stuff. (Score:2, Insightful)
Now, I'm no database expert at all, and I've only ever used MySQL for databases. But as far as I know, slashdot itself runs on MySQL (supporting evidence?) [slashcode.com]. Now, this is a site that gets a hojillion comments per article, several articles per day, with enough viewers to crush lesser sites at will. Surely this suggests that MySQL must be ready for "mission critic
Things broken with MySQL (Score:5, Interesting)
One of the biggest problems with MySQL that so many people complain about is that the entire design philosophy is not one that supports data integrity. Take a look at the list of MySQL Gotchas [sql-info.de] for starters.
The reason that it's satisfactory for slashdot is the same reason that it became popular in the first place. It was one of the first freely available database servers, and it had particularly fast benchmark results for situations that required lots of selects and not many updates. (I might be slightly wrong about the details, so someone correct me if necessary.) The fast-select advantage made it a popular option for websites a few years ago, because they involve just that. Lots of page-views (selects) and not many updates.
On the other hand, the integrity aspect of MySQL makes it a pain to code for. The MySQL credo seems to be that if input doesn't make sense, then try to guess what was meant and don't report it. (eg. Inserting a null instead of reporting an error.) Furthermore, the MySQL parser recognises certain parts of SQL syntax that are ignored, and (again) not reported. Instead, it just doesn't do anything and pretends that it all worked.
So instead of being able to rely on constraints set in the database, as can be done with nearly any other well-used database, it's necessary to put large amounts of integrity-checking code for things as simple as making sure that dates are the correct format. In some ways it's more like a half-built SQL interface to a regular file system than a database, with features for data integrity hacked on here and there if you know how to use them and always use them correctly.
In slashdot's case, don't be surprised if a random comment goes missing every now and again, because the integrity support just isn't there without complicated overhead work that induces possible mistakes. Slashdot can get away with losing bits and pieces of data, but that's not usually the case. If I say that I want to put some data in the database and that it must meet specific rules, it should either put it in or result in an error. MySQL doesn't do this reliably.
MySQL now seems to be living only on it's fast reputation that it had in the past, driven by people who've heard that it's good and it's fast, but don't know the details. By now, other free databases (postgresql [postgresql.org] in particular) have caught up a lot, and should be preferable in most cases if you're starting from scratch.
Re:MySQL Suitability for,,, stuff. (Score:2)
The two problem spaces are completely different, with completely different requirements in terms of reliability and recoverability.
In financial situations, 99.999% right isn't good enough. 99.999999% isn't good enough.
Just to give you a comparison of reliability, on my new test server, I setup postgresql 7.4, and initiated 250 parallel bank transactions, where each c
Re:MySQL Suitability for,,, stuff. (Score:2)
I personally wouldn't be upset if Slashdot lost a few comments here and there, but I'd guess that the folks who run slashdot.org take data loss pretty seriously.
Enterprise-readiness questions (Score:2)
How much time does it take to do a backup of a 100GB database?
Failover support: when a slave takes over, how long does it take to restore the master and switch back for a 100GB database?
Are views or foreign keys with constraints supported?
Does stored procedure increase performance by precompilation?
MySql vs. Postgres (Score:4, Interesting)
I keep hearing about all the great god-like features of Postgres....but what exactly can Postgres do that mysql can't? i'm going towards setting up a central database (MySQL) linux server at work which will be accessible via Ms. Access using an ODBC driver from the clients. (ie. client running Msft Access changes data on a mysql database on a linux server, easy enough to use gui and a strong enough backend)
So far, i'm not doing anything out of the ordinary. nothing too complicated database wise. What exactly would be the advantage of using Postgres.
What does it do that mysql can't?
Re:MySql vs. Postgres (Score:2)
Not to put you down, but if you don't understand the differences between the two (or any other d
Re:MySql vs. Postgres (Score:2, Troll)
> What exactly would be the advantage of using Postgres.
How's this - you'll be using a mature database that has a good implementation of almost all standard database functionality - vs one that has only implemented some of it, and has repeatedly claimed that this standard functionality wasn't necessary.
So, now MySQL is quickly trying to check off all these deficiencies, which include:
- transactions
- uni
Remember, Postgresql is a MOVING target. (Score:3, Informative)
I'll just add to the other comments and say that Postgresql is a moving target, under active development by a very talented team, so while MySQL tries to play catchup, Postgresql moves on ahead as well.
The things coming in the next year or so are:
Point in Time Recovery
Sub transactions
Very low I/O contention vacuuming.
Win32 native port
Multi-master / multi-slave async replication
In the last year, postgresql has added other key features as well, such as industrial st
Re:MySql vs. Postgres (Score:2)
Not answering your question here or anything, but you might want to check out Rekall if that Access code is not in place yet.
For all the PostgreSQL zealots out there... (Score:5, Informative)
First of all, I remember back when I was trying to decide which of the two databases to use for my bicycle touring community website, crazyguyonabike.com [crazyguyonabike.com], and I heard all the same arguments that MySQL is a "toy" that's simply an SQL interface to a flat file system, and how PostgreSQL was a "real" database with actual transactions, subqueries and so on... but then, digging further into PostgreSQL, I found out about the 8k row size limit, and the requirement to halt everything to do a VACUUM occasionally. That really set me back on my heels - 8k? That's really pathetic. Ok, so they've fixed that in the later versions, and the VACUUM also seems to be bit less blocking now, but still - it left me wondering just what else these zealots were conveniently choosing to forget about when recommending PostgreSQL. How about speed? How about all the anecdotal accounts of corrupted databases (again, probably improved somewhat more recently). What other major limitations are they conveniently neglecting to mention these days? I ask, because these people were making exactly the same noises back in the 8k rowsize limit, blocking VACUUM days as they are now.
Thing is, MySQL works really well right out of the gate for most things that people want to do in real life. Here are a few factoids for you:
MySQL *does* have real transactions. It has for quite some time now - just use the InnoDB table type. And for anyone who whines about this not being the default table - get a life! Choice is good, and I would say that for 99% of applications out there, you just don't need transactions. Go ahead and crucify me for saying this - I don't care. It works for a lot of people, many companies all over the world use it for heavy duty database work. I've used it for four years now, and it has *never* crashed on me, *never* lost any data. I use RAID and backup regularly too, but MySQL is ROCK SOLID.
MySQL is getting all these things like subselects and procedures, just with a different priority to PostgreSQL. So what? Again, I have never missed subqueries, and I have some pretty complex queries in my website. Again, go ahead and flame me, I don't care - it works for me, and it works for a LOT of other people too. Which brings me to another thing:
There is a definite sense of intellectual snobbery and elitism in many of the comments from PostgreSQL fans slamming MySQL. This reminds me of some of the people I used to know back at University - these are people who are so wrapped up in their own little cozy theoretical worlds that anything remotely practical or pragmatic in its approach seems to be extremely threatening. I think this is one of the big reasons for the bile - these people are simply threatened by the fact that MySQL is so popular and so much more used across the world. Could there also be a little tribalism creeping in here? You know, my team vs your team. They just can't seem to understand that BOTH databases work very well and BOTH databases have weaknesses, which BOTH development teams are working very hard to fix and make better. Getting religious about this sort of thing helps nobody. But, I guess, given the fact that Religion is in fact so widespread in the world, this would then also point to there being a somewhat large number of people who are so hung up on their own little certainties and fixed viewpoints that anything else just can't be left to stand. Like the Christian missionaries, they have to have everyone else adhering to THEIR point of view, regardless of the fact that there are, in fact, many "ways" to spiritual enlightenment (or data management). Again: Not everyone needs transactions. Many people just need simplicity and speed, and they get it with MySQL. And you know what, if they want transactions then they can have that too! Th
Re:For all the PostgreSQL zealots out there... (Score:2)
> Well, for whatever reason, this time I feel compelled to comment in return.
Point taken: postgresql used to have some performance and availability limitations, mysql still has functional and usability limitations.
> MySQL *does* have real transactions.
which are implemented using a third-party product, are limited and aren't seamlessly integrated, and which c
Re:For all the PostgreSQL zealots out there... (Score:2, Insightful)
Nah, more likely it's the disgust that the more experienced developers feel with an obvious charletan that claims that well-proven techniques aren't necessary. Kinda like if ten years ago Yuga had insisted that air-bags, seat belts, and bumpers weren't needed "by most people in most situations". Yeah, right.
yep, I've occasionally developed trivial databases without [subqueries]. But I've seldom developed a serious database without them.
Wow, thanks! Another snid
Re:For all the PostgreSQL zealots out there... (Score:2)
Dude, don't take criticism of the mysql product so personally. Relational databases have been around a *long* time, and the basic functionality is *well* understood. If mysql ab hadn't taken the equivilent position to declaring OO unnecessary and delivering a new implementation of COBOL '68 - then they wouldn't be the recipient of so much *legitimate* criticism.
And don't act
Re:For all the PostgreSQL zealots out there... (Score:2)
> for hair loss even back when these limitations were in place.
Ah maybe so. Well, in the interest of helping to set the record straight, here's my take on that:
- 8k wasn't much of a limit until we started storing multi-media in databases. Prior to that it was rare to hit an 8k limit. Postgresql was a little late with their support here.
- mandatory maintenance downtime was common even in co
Avoid quirkiness. (Score:2)
Re:For all the PostgreSQL zealots out there... (Score:5, Informative)
Also, while you seem to be remembering how badly the Postgresql folks badmouthed MySQL, you seem to be conveniently forgetting the badmouthing that MySQL AB (not the users, the COMPANY) handed out to Postgresql, basically LYING in their online crashme results about Postgresql. While the most aggregious of lies have been removed, and the climate between the MySQL developers adn the Postgresql developers has turned decidedly more civil, there was a time when MySQL, the COMPANY, bad mouthed Postgresql, the community. Remember, there is no company to pay for marketing of Postgresql like the is for MySQL.
Even today, the crashme tests erroneously claim a 16 Meg limit to an insert statement (MySQL's is properly listed as 1 Meg). The reality of the fact on that one is that the buffer MySQL uses to test the database is 16 megs, and when it fills up, the test says "yep, 16 megs is the max." Care to guess what the maximum query size is for Postgresql? Well, there isn't a limit, until the machine runs out of RAM, then SWAP. I.e. no real limit except as declared by your hardware.
There were all kinds of snide and nasty comments about Postgresql in the older MySQL docs, like how code in it wasn't carefully crafted, just tossed in, and how it wasn't well tested.
Those kinds of barbs stung, and there are still a lot of Postgresql users with a chip on their shoulder trying to settle the score.
Postgresql, and MySQL, like every data base has warts. It's just knowing which warts are there so you don't pick the wrong database for the wrong application. In the past, the MySQL party line was that you didn't need the things MySQL was missing, even if you were doing banking style transactions or accounting. That attitude has softened as MySQL has gained both traction and features and the marketing behind it has matured.
What I'd like in MySQL is "per database" settings for things like default table types, ansi compliance (ie. " instead of ` for quoting field names, non-insertion of invalid data etc...) so I could create an HR database that had real relational integrity and enforced it, and didn't allow MyISAM tables, but only innodb.
Postgresql has settings that live "per database" that are quite cool, like "alter database set transaction isolation serializable" and it means that all transactions in THAT database will default to serializable. That kind of per database setting would fix a lot of my problems with using MySQL as a general purpose database.
also, there are ways of making transactions cost VERY little in Postgresql, if that's important, such as putting the xlog on a seperate drive, or even better on a battery backed cache RAID controller, or even disabling FSync. Lately, I'd say Postgresql is an even match for MySQL as a content storage database, and it gets rock solid transactional support as a bonus without me having to worry if I declared my tables properly.
Re:For all the PostgreSQL zealots out there... (Score:2)
Your last paragraph, where you say:
As for the 8k row limits, so, in this regard, MySQL was in fact *better* than the big databases such as MSSQL and Oracle? So why, instead of complementing MySQL for this accomplishment do we slam it as a toy database?
sho
Re:For all the PostgreSQL zealots out there... (Score:2)
And you can't normalise MySQL tables? I've converted several "Hey, let's pretend it's just like Excel" horrors done in MS-SQL into *normalised* MySQL DBs, reduced their sizes on disk by anywhere from 50% to 80% and made them run 2-3 times as fast just by appl
Re:For all the PostgreSQL zealots out there... (Score:2)
ngunton: MySQL's many bugs aren't a problem. It works fine. I've never seen data loss, so it must not happen.
Cajal: well, actually, there are problems here they are: (list of problems follows)
ngunton: Nu uh! You're saying MySQL is evil, you're mean. MySQL works. It works it works it works it works, and I won't believe you.
Cajal: But, here's the list (repeat list)
ngunton: Nuh uh! You're saying MySQL is evil, you're mean. MySQL works. It works it works it works it wo
Re:For all the PostgreSQL zealots out there... (Score:2)
In fact he carefully pointed out the areas where MySQL is strong, as well as the areas it is weak, and why he would or would not recommend it.
Each time he did this, you kept taking it personally, and responding with emotion laden, logically fallacious arguments that proved no point other than the fact that you take these things far too personally.
Keep in mind, in this same thread, I als
Re:For all the PostgreSQL zealots out there... (Score:5, Insightful)
When I started using postgresql, at 6.5.3, it was deficient in many ways. Advocates may have tried to hide these deficiencies at the expense of whoever they were advising. But, I never got any sense that the developers did.
I remember a post by someone on the mailing list that asked (and I'm paraphrasing here from memory, so I could be off): "Would you run your payroll system on PostgreSQL?" (implying that he bet his paycheck on postgresql) and a primary developer responded "not on 7.0, but on 7.1 [just released at the time], yes."
I really think that postgresql has moved a long way since that time. It's at 7.4.1 right now, and I I simply haven't heard reports for a long time about any sort of "weirdness". It's a 24/7 system now. Heck, I was running a 7.1.x system for a long time with no problems.
Now, I get the same feeling about hidden issues with MySQL from the advocates of that system. But I actually check up on my facts, and I've decided that I would prefer not to use a database that thinks Feb 31st is a date.
Granted, I understand that the features of PostgreSQL have to develop a track record of actually working. Well, all the things you mention were fixed at least a year ago, and yes, they do work.
I also understand that MySQL works for you. But what I don't understand is why PostgreSQL doesn't work for you. I'm not saying you should switch to postgresql, but I would like to hear of an actual problem someone had using it in the last 12 months (or heck, 24 months) that MySQL solved. What can PostgreSQL possibly do that would attract your attention again?
From my perspective, MySQL has nothing to attract me away from PostgreSQL. MySQL improvements have been suggested many times, and they're working on them. What improvements do you suggest for PostgreSQL?
Re:For all the PostgreSQL zealots out there... (Score:2)
Their loss. If you can do without transaction control & subqueries, good for you. Foreign keys, on the other hand, are really useful: they're basically an effiencent way of ensuring that all the info in your database actual
Re:For all the PostgreSQL zealots out there... (Score:2)
Fuck you! (Score:3, Funny)
Stored Procedures? Which language? (Score:2)
Stored procedures are a mess, with a de facto ill-defined Java standard trend, a de jure SQL/PSM standard supported by IBM DB2 and not much else, and a proprietary, non-portable PL/SQL supported by Oracle and PostgreSQL.
But anyway I won't consider MySQL when I have PostgreSQL with a much sounder, even if not perfect, approach to fundamentals.
Just finished upgrading... (Score:2)
Re:The big question: (Score:2, Funny)
mssql
hahhahahahahahahaha
o man, good one!
Re:Serious bug (Score:2)
Dear Moderators,
This is not flamebait. It's a sarcastically funny, but honest criticism. Learn to tell the difference.
Thanks,
- jck
Re:Serious bug (Score:3, Insightful)
Re:Serious bug (Score:2)
Re:Unlike PostgreSQL (Score:2)
Re:Unlike PostgreSQL (Score:2)
We have a postgreSQL system (well, cluster) that handles 400-800 queries/second sustained for several hours a day (it's a stock-market information system).
We tried MySQL and decided against it because:
a) It was much, much slower with a large number of concurrent queries.
b) It has really, really bad error reporting - it just silently truncates, converts and discards data.
c) Their implementations of foreign indices is somewhat flawed, and there are no stored procedure or tri
Re:Unlike PostgreSQL (Score:2)
To anyone who complains about speed:
(1) Does RDBMS performance actually affect your application, or does the bottleneck lie elsewhere?
(2) Do you really have the numbers for your application behavior, or are you just guessing?
(3) Did you put some minimal informed effort into making the RDBMS perform well, or at least as much effort as you put into the alternative? A good place to start for a postgresql performance problem (hint, hint) would be a detailed description of t
Re:Unlike PostgreSQL (Score:2)
You might want to try it again, and report back to the pgsql-performance list to see if they can get you some help.
Re:MySQL and PHP legalities (Score:5, Informative)
Re:why this matters? (Score:2)
nostalgia? I mean, there are some folks who really miss that 70s pre-RDBMS coding in IMS, ISAM, etc....
Re:why this matters? (Score:2)
What other regards? This is a serious question, because I don't think the developers always know. They know everyone wants easier-to-use replication (there are some good solutions out there, but nothing is really "out of the box"). I suppose that changing the owner of a database counts, but I don't think I've ever had to do that. I'll try it out and maybe try to get that fixed.
So, for the benefit of the success of PostgreSQL, what is your
Re:why this matters? (Score:2)
I don't use it much, but it looks very nice and is easy to work with for the little stuff that I have done. It's also cross platform, and I've used it on windows and linux.
Re:great, now all we need is... (Score:2)
Tsearch rocked, and Tsearch2 looks to be another giant step beyond.