-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 On Wednesday 05 March 2003 10:17, Ian Bruseker wrote: > On Wednesday 05 March 2003 12:41 am, Shawn wrote: > > For database, I think I'd prefer Postgres - everything I've heard about > > MySql makes me think it's to databases what MS Access is. Whereas > > Postgres seems to be more on par with Oracle/MS SQL Server. > > It's really unfortunate that people have this impression. I'm not faulting > you personally for this, Shawn. My co-worker once called MySQL a "baby > database". I wanted to smack him. ;-)
don't smack him: he's right. and there's nothing generally wrong with that. MySQL is a good tool for a certain domain of problems that a "real" RDBMs won't be as good at (in particular, for where data integrity doesn't count for anything and raw write speed does) > MySQL seems to have taken a bit of a hit over the last few years for > missing some "enterprise" features like foreign key relationships and > transactions how about normal (e.g. non-"enterprise) RDBMs features like subselects and stored procedures? or normal ANSI SQL? do they even have a BOOL data type yet? and foreign keys and transactions aren't "enterprise" features they are "i don't like corrupting my data" features ;-) > The foreign key thing they used to explain way as being something most > people don't need and even fewer truly understand, which I don't entirely > disagree with. :-) But they do seem to have support for that now too. > Check out this: http://www.mysql.com/doc/en/ANSI_diff_Foreign_Keys.html wow. whoever wrote that has little idea what they're taking about. they say that foreign key constraints w/out ON DELETE are mostly documentary, but they aren't. they are there to enforce data consistency and are very much active and useful. they say they don't support ON DELETE but that you can mimick that in your client code. well, that's the entire point of foreign key constraints: no client code, which means 100% consistency and no race conditions! they don't seem to mention anything about ON UPDATE, either. probably means they don't have any support for that at all, since that's the usual MySQL way of dealing with such things: pretend they don't exist. they also state the foreign key relations aren't kept in table spec files for later dump/restoring, which is pretty sad since that makes them much less useful... they say a disadvantage is that you can make mistakes with them. well, yeah, you can also make a mistake with just about any other feature of a data storage system. but they certainly prevent more mistakes than they ever create. the "you can make circular rules" thing is kind of odd, since while you can make them you really have to go out of your to do so and fixing such a situation is trivial (just drop the constraint). this "point" of theirs is really one of the most stupid arguments i've ever heard. aside from the technological abilities of mysql, the developers and company behind MySQL have been less than honest, truthful and forthright historically ranging from bad mouthing with lies other products/projects, offering rigged benchmarks and lieing about licensing issues. such attitudes make me wary of the people involved and therefore their project and product. their constant vapourware also irks me, but that's more of a personal taste thing. > MySQL at least makes you work for it, so you can be more sure that a MySQL > database will work. :-) i'd tend to say that it makes it more error prone or at best just slower. you do need to learn more mechanics this way, but it doesn't mean you need to learn anything more about databases =) > Plus, Access does not scale nearly as well as > MySQL does (in my personal experience - no charts or graphs to back this > up, just gut feel). same here... - -- Aaron J. Seigo GPG Fingerprint: 8B8B 2209 0C6F 7C47 B1EA EE75 D6B7 2EB1 A7F1 DB43 KDE: The 'K' is for 'kick ass' http://www.kde.org http://promo.kde.org/3.1/feature_guide.php -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.2.1 (GNU/Linux) iD8DBQE+Zrxt1rcusafx20MRAtRpAKCdO9TjcGcT5MikETvkSW9J3gSXggCePPe/ 4SivRYRonBN3HD+dQa4AwnI= =T68f -----END PGP SIGNATURE-----
