Become a fan of Slashdot on Facebook

 



Forgot your password?
typodupeerror
×
Programming IT Technology

MySQL 3.23 Declared Stable 115

redcoat writes "After two long years, MySQL 3.23 has been declared stable. Improvements over 3.22 and .21 include rudimentary transaction support using the BerkeleyDB lib, full-on replication (master/slave configuration) and lots of other goodies. It's been a long wait, but a worthwhile one, no doubt."
This discussion has been archived. No new comments can be posted.

MySQL 3.23 Declared Stable

Comments Filter:
  • Well those are neat, but they are minor features to most people. Replication and load-balance between slaves is neat, but what's the point to load balance between slaves when MySQL doesn't even cache queries. With web sites running always the same queries again and again, caching queries would gives incredible speed boost and isn't a very hard feature to implement (quite easier than foreign key or transaction IMHO).

    Sure things improves in MySQL, but huge missing features are ignored in favor of minor improvements here and there. I'm sorry but full-featured transaction, foreign keys, caching, constraints, nested queries, etc. are what people expect their database to do, and they are very MISSION CRITITAL in many situations. Reworking the table file format yet again is not what I'd call a massive improvement.
  • by -brazil- ( 111867 ) on Sunday January 21, 2001 @10:59PM (#491575) Homepage
    Wusthof-Trident 7" Kitchen Knife declared versatile [minutemeals.com]

    Well, compared to what? It doesn't even have a can-opener!

    Do yourself a favor and get yourselves a Victorinox Swiss Army Knife with builtin digital altimeter and thermometer [milnejewelry.com], so you can play with a real knife!

  • What do you want? A stable database? Or lots of
    new features with bugs in them?

    It's a whole company, but do you know how much people they are? Don't always think of giants like Mircosoft or Intel when thinking of companies, MySQL is developed by just a few people (I counted 12 or 13 coders), and they are keeping the whole stuff platform independent, the server and the tools run an Windows, and many flavours of unixes.

    Ever built a transaction feature yourself? Or a rudimentary database? I don't think half an year is to long for the things they implemented in 3.23.

    Michael
  • I don't get it. I've used MySQL with many, many different versions over the past two years. I'm no DBA, and I never spend time tweaking its performance -- basically I always just set it and forget it.

    ...and in all that time, I've never had a crash or corrupted table. What gives? Am I that lucky?

  • Seems like a Relational database system would have relations and a Transactional database system would have transactions.
    With Transactions the code is to write first then check. If there are problems, you can always rollback.
    With MySQL (other than with transactions on BDB), the update is atomic. It either succeeds or fails. It's a different paradigm and in many cases a better paradigm. You do need to do better analysis and coding, though.
  • by __aanonl8035 ( 54911 ) on Monday January 22, 2001 @06:10AM (#491579)
    I found an interesting article
    by a fellow who has worked on some
    major open source oriented sites.
    He does a quick comparison of
    postgres and mysql here [phpbuilder.com].
  • You obviously don't understand MySQL versioning, what it means is that the latest release MySQL 3.23 "is the latest stable release"

    Alex
  • In 3.22.34, it would crash just from a run o' the mill ORDER BY. Hope at least that much is fixed...
  • It allows NULL in indexed columns!

    Are you saying this is a good thing or a bad thing? Certainly at least for non-unique indexes you want to be able to have an index on the rows that do have data. Queries which use the index should should still be speedy.

    For unique indexes it's another matter. Oracle allows unique indexes on nullable columns which is pretty bogus since it doesn't ensure uniqueness.

    -Bruce
  • MySQL have for many years been been considered as a very unstable product and that it have been (still are probably) lacking a lot of really useful features.
    No, MySQL has been rock stable at the very least for the last 2 years. I've been using it for website development since mid 98 or thereabouts, and it's never crashed or lost any data. MySQL is definitely nowhere near the high end of databases when it comes to features, but what it does, it does it really well.
  • But the Microsoft solution does get you transaction support in ASP, never mind the database, a replication architecture that has been around a couple of versions (I've never actually used it, but I know that at least SQL6.5 had it), and an army of button-pushers who know how to use it.

    Maybe you don't need all the database and transactional features for your application, but you aren't comparing like for like here.
  • So Do Nusphere [nusphere.com].
    I ran tests for a client using both Nusphere & AbriaSQL distributions of php, mysql,apache & perl (nupshere only) on Red hat & win 2k. The Nupshere was easyer to install on both platforms.
    Also unless you pay for support, AbriaSQL use elder versions of all the programs. whixh is bad.
  • Yes, Postgres 7.1 supports LEFT, RIGHT, and FULL outer joins. It's still in beta but it's been running Sourceforge for a month ...
  • Well, check out sapdb at www.sapdb.org.

    It will be GPLed soon.
  • Wow. No foreign keys. No transactions. No stored procedures. An Excel Spreadsheet has the EXACT same functionality as MySQL.

  • With web sites running always the same queries again and again, caching queries would gives incredible speed boost...

    That might be an issue if performance were a problem. Most web sites built on MySQL get results plenty fast without having to cache things.

    I'm sorry but full-featured transaction, foreign keys, caching, constraints, nested queries, etc. are what people expect their database to do, and they are very MISSION CRITITAL in many situations.

    I don't think anybody is suggesting using MySQL to run your Fortune 500 company database. MySQL's niche is web sites. The web is inherently session-based. If you've got somebody entering data in a form, and they bail halfway through, you have no way to tell. How many web sites allow you to "unsubmit" a transaction? So transaction rollback isn't a big deal for a lot of applications. Likewise with foreign keys. If you're coding your site in such a way that foreign key violations are what tip you off to a data integrity problem, you need to do some more work.

    MySQL is not Oracle. It's not PostgreSQL either. In many ways, that's a good thing. That's the great thing about competition: You can pick the tool that does what you need.

  • Let's see ...

    1 & 2: PG 7.1 (now in beta3) allows infinite length tuples, so you might want to reconsider that restriction, given that you're still in development and that PG 7.1 will be released in a very short time.

    3: "order by" has to sort the output rows regardless, so sorting the indices alone doesn't help as much as you might think. This is particularly true if you're doing a "join" first. And merge joins result in an ordered set of output tuples which in some cases, at least, will match the "order by" sort requirements, meaning it can be left out altogether

    4: PG 7.1 does ...

    5: True

    6: Not quite sure what you want, here, but PG does support a fast "COPY" command to import data quickly.

    7: True

    8: PG 7.1 does ...

    9: True

    10: Sourceforge recently migrated from MySQL to PG 7.1 :)
  • by bwt ( 68845 ) on Monday January 22, 2001 @06:58AM (#491591)
    I'm of the opinion that the open source databases are all so substantially behind the capabilities of the proprietary market leader Oracle that I don't consider them viable replacements for enterprise grade data solutions. I work on a system that has 800 concurrent users at any given moment, and I don't see anything remotely close to worthy of consideration in the open source arena.

    Worse, I see Oracle as pulling away. In the last two years, the open source databases have struggled to add features that I view as expected and required while Oracle has added 10X more. Transactions & row-level locking, nested selects, foreign keys, etc... are not optional features. In order to compete, open source needs database projects with forces comparable to the linux kernel, apache, gnome, and KDE projects. I just don't think Larry Ellison is out there worrying about GPL'd competition.

    I don't think Oracle gets the proper attention in the open source community. Oracle has a greater "lock in" effect and has mostly got a free ride from the open source community so far. Oracle is a big gorilla that is rapidly becoming the most secure proprietary software vendor around.
  • This is why the replicate user only gets issued the FILE privilege, like the tutorial mentions:

    GRANT FILE ON *.* TO replicate@ip_address IDENTIFIED BY 'password';

    Although, you are correct, as this is a potential problem to be aware of, as listed in the MySQL documentation:

    "Don't give the file privilege to all users. Any user that has this privilege can write a file anywhere in the file system with the privileges of the mysqld daemon! To make this a bit safer, all files generated with SELECT ... INTO OUTFILE are readable to everyone, and you can't overwrite existing files. The file privilege may also be used to read any file accessible to the Unix user that the server runs as. This could be abused, for example, by using LOAD DATA to load `/etc/passwd' into a table, which can then be read with SELECT."

  • it's a whole company, but do you know how much people they are? Don't always think of giants like Mircosoft or Intel when thinking of companies, MySQL is developed by just a few people (I counted 12 or 13 coders), and they are keeping the whole stuff platform independent, the server and the tools run an Windows, and many flavours of unixes.

    On the developer's mailing list of Akopia's Interchange open source e-commerce package, http://developer.akopia.com/archive/interchange- users/2001/msg00535.html , Monty Widenius said himself last week the following:

    Our development has during the last year grown from 2 1/2 to 8 people and we have also got a much bigger market penetration during this time.

  • Hey, thanks, it works!

    Any ideas on how efficient it is for large tables? Does it have to internally randomly order the whole table before returning just one row?
  • I use Oracle in my day job. It definitely has some good features, and a good few mis-features as well.

    While you are probably correct that there aren't any open source alternatives at the high end, at the mid-range PostgreSQL is definitely an alternative, with (better than) row level locking, transactions, foreign keys and nested selects all there in current production versions.

  • whoa, whoa cowboy!
    mysql is not out the crush the oracle competition! mysql and oracle are too different applications designed for different solutions. wanna make the next ebay? use oracle. wanna make a lightning fast accounting app for a small to medium sized business? use mysql.
    please don't compare the two in this regard.

    golgotha
  • 1&2: You are right, but still doesn't support BLOBS in tuples, which simplifies a lot the maintenance and programming.

    3. AFAIK, if you are sorting a table, which is very common in web pages, indexes reduces a lot the complexity of the sort. According to the PG docs, it's even makes use of temporary files for sorting data in case the output it's too big for doing it in memory.

    6. It means that the file is available in the client or server side. It's important if you want to "download" a file from the client or import the contents from a server side file. It affects access privileges as well.

    Regarding the remaining issues... you are right too.

    --ricardo

  • There was an (unwanted) discussion broken out on the developer's mailing list of Akopia's Interchange open source e-commerce package last week.

    Michael Widenius gave himself some responses, which might be interesting for those following this discussion.

    Search http://developer.akopia.com/archive/interchange-us ers for "monty@mysql.com" or read the thread:"[ic] postgres versus mysql"

    Please don't post comments to that list if they are not related to "Interchange". Thanks.

  • At a recent open source database conference-thingy down here in the SF bay area (sponsored by abriasoft [abriasoft.com]), the mysql guys said that row level locking was a ways off. I, personally, was rather sad to hear that.
  • by Betcour ( 50623 ) on Sunday January 21, 2001 @11:00PM (#491600)
    Say you have an e-commerce app... one table with orders, one with customer account.

    Now say you allow orders to be passed with or WITHOUT an account (don't want to force people on creating an account first).

    you have in your orders table a "customer_account" field, can be NULL or can a foreign key to the customer table.

    Now you can do this in MySQL :

    SELECT * FROM orders LEFT JOIN customers ON orders.custumer_account=customers.account_name WHERE (blablabla)

    And then you have in your results either only orders info (if custumer_account is NULL) or orders AND customers info at the same time. No need for two separated requests...

    So LEFT JOINS are quite usefull in any table that has a foreign key that can be NULL.
  • yeah! is there an efficient way of doing that with PostgreSQL? I'm currently selecting count(*) from the table, then picking a random number from that group and selecting the row. Probably not the best method. Thanks!
  • by TheCorporal ( 306071 ) on Sunday January 21, 2001 @11:04PM (#491602) Homepage
    Yes yes, I would have to say the most important in the final stable release of 3.23 is the fact that they have fully working Replication now! Yee ha, talk about a timesaver for our dual DB system.
    One way replication can be used is to increase both robustness and speed. For robustness two (or more) systems can used to switch to a backup server if you have problems with the master. The extra speed is achieved by sending part of the non-updating queries to the replica server.
    Who can resists? Hehe Ill bet a lot of you can, and probably are still peeved about its lack of lots of stuff. But hey, its a step in the right direction right? I was just wondering though, do they have any row-locking features yet? I am too lazy to look =)
  • I think MySQL developpement is slloooowwwwwwww. You would think a whole company dedicated to MySQL would allow for lots of new features coming out every week.

    Well, they have been working on the 3.23 for about half a year and all they managed to do is implement a basic transaction feature. And they didn't even did it really by themselves, they had to take some code from the Berkeley DB and use a different table file format.

    I guess by 2017 we can expect to have nested queries, 2045 for row-level-locking and 2078 for true foreign keys... at least Postgresql, with all the its flaws, is improving at a much faster pace and we can expect a whole lot of migration from MySQL to Postgresql sometimes in 2001/2002.
  • by hexx ( 108181 ) on Sunday January 21, 2001 @11:10PM (#491604)
    In the open source world, I find two RDBMS especially good. PostgreSQL and Interbase. They are both fine products and probably near commercial grade RDBMS standard.

    Now, would that be Interbase with [slashdot.org] or without a compiled in superuser backdoor account? :)

    Of course, for pure SELECT power, nothing beats MySQL. So if you're not inserting data too often, and you don't mind running ISAMCHK every now and then, and data integrity isn't entirely critical (which does work for a surprising number of people), then yay MySQL!

    I use it.
  • Don't you just love the way MySQL gives reasons not to use SQL features they don't support [mysql.com]? And not just foreign keys, either, but transactions [mysql.com] as well, among other things. Yeah, yeah, yeah, there's now rudimentary transaction support via BDB. Not that I'd trust any important data to something that is considered "rudimentary".

    Then again, some people just have to reinvent the wheel several times over. One could wish that MySQL would just go away, in favor of more mature products [postgresql.org] that are also "Free". It won't happen anytime soon, but we can dream.

  • It allows NULL in indexed columns!
  • That's hardly fair. MySQL is in no way "equivalent" to MS SQL Server, which is in the class above.

    That said, you could just as easily use Sybase ASE on linux, which is effectively free, and is a proper RDBMS.

  • If you have local users, it's in your best interests to upgrade, since .21 reportedly has a buffer overflow. (See bugtraq) MySQL shouldn't be running as root, but the MySQL user often has access to non-public databases.
  • Actually I don't blame them for the time it took to add transactions - this is IMHO a very difficult feature to add with major implications everywhere. But queries caching and nested SELECT aren't very hard to implement and should be on the "top priority list" :

    Query caching is simply a matter of keeping SELECT results somewhere and ditching them when an UPDATE/ROLLBACK comes in. I guess MySQL team is more interested in fixing some obscure bug with DB replication than speeding up their database by several order of magnitude...
    As for nested SELECT, why don't we have them yet ? Is it so hard to run QUERY #1, then feed the result into QUERY #2 ? Heck, we all do it ourselves on the client side of MySQL with a loop in PHP/PERL and it takes 5 lines of code... shouldn't take that much to implement in MySQL itself !

    Postgresql doens't have 13 full time coders working on it, yet it has much more functionnalities, and according to the latest benchmarks around, has gotten faster than MySQL.
  • Went to the postgres site, downloads are only for linux, didn't see a source download. What gives? is it only supported on linux?
  • Check out Interbase. [interbase.com] Some folks were turned off [slashdot.org] due to their troubles with releasing the code and the infamous backdoor [slashdot.org].

    I have run it on Linux and NT for the past 6 months. I built a real estate lease entry and tracking system using Interbase, PHP, and Apache. It does support full transactions. It does support full FKs. I don't know how it compares to PostgreSQL, but PG was not an option as the client only has NT for the server.

  • uniqueness of what? Data!

    But null means "no data" it is not some special data value.

    If you don't want nulls, say "not null" in the column definition, but it has been a source of greif to me that I couldn't index on a field just because I didn't have a value in every case.
  • With PostgreSQL so far I've had to use two queries. If there's a way around that someone please tell me. :-)

    are you referring to the except clause in select? it uses a subquery, but i think it's still considered one query.

    use LaTeX? want an online reference manager that
  • Once they find out that they have something stable in their distribution, they will have to change it as a matter of "Company Policy." :^)
    ---------
  • I think you can make the argument that Interbase lost 'the battle' because they have a lousy marketing department. Until Interbase went Open Source (tm), I had never heard of it even though I have been building Oracle and Sybase applications for the past 5 years.

    Sounds more like a marketing problem than a functionality problem.Interbase has cool features [borland.com] that other 'commercial' RDBMS do not have (like events).

  • ftp://ftp.postgresql.org/pub/latest/ [postgresql.org]

    use LaTeX? want an online reference manager that
  • SELECT * FROM tablename ORDER BY random() LIMIT 1;
  • PostgreSQL runs on Windows NT just fine.
  • by gallir ( 171727 ) on Monday January 22, 2001 @07:24AM (#491619) Homepage
    I am one of the team doing PHP development for the Balearic Islands LUG [lug.net]. The current system runs with PostgreSQL and we were analysing the convenience of migrating to MySQL.

    Find enclosed some of the conclusions:

    1. PG does treat BLOBs as part of a tuple, MySQL does.
    2. There are serious problems with PHP and PG transactions for reading and writing BLOBs in the database. PG forces to use transactions, MySQL doesn't.
    3. PG doesn't use any index to speed up sorts (ORDER BY clauses), MySQL does. This is a problem for web pages were most of the result are ordered according to articles IDs or modification dates.
    4. PG, as in V7, doesn't accept tuples of more the 8KB, 32 KB support can be selected at compilation time but speed is seriously affected. There is not this kind of restrictions in MySQL.
    5. PG does not accept "full-text" indexing and queries.
    6. In MySQL you can choose if a file to be imported is being read by the backend or the frontend.
    7. You have to run VACCUM ANALYZE in PG from time to time in order to get your queries optimised.
    8. PG doesn't allow to do BLOB content search, MySQL does.
    9. PG accept RULES for executing SQL sentences on table insert or updates, MySQL doesn't.
    10. NASA has migrated one of their webs to MySQL ;-)
    We found that the previous reasons justify the migration to MySQL.

    --ricardo

  • The PostgreSQL HOWTO at the LDP was written by a moron and is in no relation to the PostgreSQL project. Just a couple of days ago the LDP webmaster finally yanked it.
  • The SQL standard allows (multiple) NULLs in unique indexes. The relevant portion reads: (8.9 GR 2)
    If there are no two rows in T such that the value of each column in one row is non-null and is equal to the value of the corresponding column in the other row according to Subclause 8.2, "<comparison predicate>", then the result of the <unique predicate> is true; otherwise, the result of the <unique predicate> is false.
  • I reported this bug a while back and its STILL not fixed. They won't even acknowledge it has a bug. MySQL DOES NOT work using PAM LDAP.

    So, I am suck running MySQL as root becuase that get it taken care or ... ARGGGGGGGG!


    until (succeed) try { again(); }

  • How does this compare with PostgreSQL and Interbase?

    Which databases support replication and transactions?

  • I never ceased to be amazed the lengths people will go to to install a substandard database product like MySQL when Postgres is as free, and far more capable. It even ships with some Linuxes, fer crying out loud.

    --

  • NuSphere is adding row-level locking. They were one of the companies that invested in MySQL and allowed it to be GPLed. The press release talking about it is at: http://nusphere.com/releases/103000.htm
    They say it is targeted to be available in spring 2001. It sounds like they are implementing yet another storage architecture. They say it will have transactions also. So if you want transactions you will have two table types to choose from Gemini (NuSpheres new one) and bdb that is new with 3.23. So we are seeing open source competition between different modules within an open source project. And it seems each new one is better than the last.
  • by account_deleted ( 4530225 ) on Sunday January 21, 2001 @10:09PM (#491626)
    Comment removed based on user account deletion
  • I tend to agree that Oracle is the best, but small companies cannot afford its ridiculous prices for a small web site or even large one. As you will see here [mysql.com], a small department in NASA even had to switch from Oracle to MySQL due to budgetary constraints.....
  • 3. What does MySQL do if your sort doesn't fit in memory? Give up? Crash? Or use temp files?

    Postgres supports tables which exceed the operating system file size limit. Many of us can't afford processors with more then 2 or 4 GB of RAM. I don't think the fact that Postgres will let me sort files that don't fit in memory is a weakness ...

    Of course in the web environment sort results are likely to be relatively small, in which case they'll fit in RAM just fine assuming you've set the postgres per-sort limit to a reasonably large value.

    Again, in some cases being able to sort directly on indices does make a difference, in other cases it doesn't.

    1&2. The BLOB interface is a bit clumsy, true. However as of PG 7.1 pg_dump will make consistent snapshots of databases containing BLOBS, which can then be restored. I don't really see the fact that you need to use the interface in a transaction as a bad thing, though people who are used to not using transactions (most MySQL users) might think it is. After all, if your BLOB insert dies you generally will want to roll back any related inserts ...

    The clunkiness of the BLOB interface isn't a big deal for most websites. Even if you're dealing in images, word files, etc the fact of the matter is that in a well-designed system the low-level details will be abstracted into a small set of routines. It does work ...

    6. The BLOB interface lets you import files directly, for instance those files that a client "downloads" from the web which are stuffed into a temp file by your webserver ...

  • That might be an issue if performance were a problem. Most web sites built on MySQL get results plenty fast without having to cache things.

    Excuse me to tell it this way : this is a very short sighted answer. Web sites tend to grow, and sometimes they grow big enough that the DB server start crawling to its knees under the load. You can never have to much optimized software. Slashdot needs a 4 CPU system to run MySQL... maybe with queries caching it could do the same job with just one CPU and an extra gig or RAM (forums are a lot of read and just a little of write). That's a lof of money saving !!!

    Secondly, so request can still be pretty slow on MySQL. I use it to generate charts from 1000's or record... even with indexes and lots of work on the queries it's somewhat silly to run again and again the same queries when they could be cached.

    MySQL's niche is web sites. The web is inherently session-based.

    So ? Because it's the web means you don't need rollbacks ? What if, behind the web site, you have e-commerce, statistics manipulations, etc ? What if your user have points they can trade ? Wouldn't that require at least sessions ? What if I'd rather use nested SELECT than code some ugly loops in PHP to do it with several queries ?

    Because MySQL is targeted to the Web doesn't mean it is ok to have no professionnal features. people do important things now on the Web (except porn, but then even porn can be good money ;)
  • MySQL doesn't recognize or enforce foreign keys. But you can still make fields that hold values that are keys to other tables, which, according to my relational DB course, is what you call a "foreign key" :-)

    I think the MySQL syntax even allows for the keyword "FOREIGN KEY" in table definitions (and they even plan to sometimes save this information somewhere, maybe there's hope !).
  • Well done guys and girls.

    I'm of the opinion that along with several other open source applications, MySQL is what's helping Linux make large inroads to the enterprise market.

    A while back I priced a WinNT solution for a basic e-commerce site, with MS-SQL 7, ASP, and all the rest of the NT fluff needed. It came to over $5,000 Australian dollars (about $7.33 USD :) The equivilent freeware solution came to exactly zero dollars (duh). (hardware costs not included, btw).

    MySQL was a large part of the equation. I was and still am very impressed with it.

    Again, well done to the team.
  • The biggest "feature" of 3.23, of course, is the fact that it's GPLed. 3.22 is not. As for switching to Postgresql, I need enum, I need mediumint(5) unsigned zerofill. To some extent it's just programmer laziness, but it's nice to have your code not need to do so much data type checking and formatting. User-defined data types and/or stored procedures would be preferrable, then I wouldn't have to use tinytext for urls, for instance, but for now the only two real choices are MySQL and Postgresql.
  • by Carnage4Life ( 106069 ) on Sunday January 21, 2001 @10:30PM (#491633) Homepage Journal
    I was really hoping that proper foreign key support would be added by know but was dissappointed to see it missing from the list. I decided to see if it was in the TODO list [mysql.com] and was surprised to see full foreign key support in the Things that have to be done sometime section instead of the Things that should be in 4.0 or the Things that must done in the real near future sections. So it looks like full foreign key support won't be around till 5.0 or later. *sigh*

    Lack of full foreign key support (and maybe transactions) is the only reason I don't consider mySQL a proper relational database management system as it claims [mysql.com] sinceit doesn't enforce relationships via referential integrity checks [mysql.com]. In many large complex applications, having referential checks built into the DB is very useful and it would be a great boon if mySQL had this functionality.

    Grabel's Law
  • Sure, it might be a _little_ bit quicker then PostgreSQL. But, I still belive PostgreSQL is the better choice. But, its good to hear its now a stable version. Maybe they can start adding things like sub selects and what not.
    until (succeed) try { again(); }
  • So why don't you use PostgreSQL? It's had foreign keys since last May. The release 7.1 that's coming out soon will fix limitations like the 8K row length limit and will add outer joins and some other stuff. I'm running the beta3 now on a test box and it seems pretty sweet.
  • AbriaSoft [abriasoft.com] has a free download for "AbriaSQL," a distribution of MySQL, PHP, and some other stuff with a wizard-driven interface that takes just a few minutes. It fixes the MySQL install problem in RH7, also. Check'em out...

  • Um, Does Postgres even support LEFT JOIN yet?

    They both suck in a lot of areas.... don't bash one without bashing the other.

  • 8K limit in Postgress makes it unacceptable
    for many users. Yes, it will be lifted soon.
    So I heard. Let us talk when. Meanwhile MYSQL
    is here and does the job.
  • by Micah ( 278 ) on Sunday January 21, 2001 @11:20PM (#491639) Homepage Journal
    That's also the case when you have two tables, say customers and widgets, and customers can have any number of widgets, including zero. Say you want to display a list of all customers and the number of widgets they have. Implementing it with a simple join, customers with no widgets simply won't show up in the result set. With MySQL there's a way to do it right with left joins. With PostgreSQL so far I've had to use two queries. If there's a way around that someone please tell me. :-)

    That's the biggest disadvantage of PG I've found, and it's not *that* big a deal.
  • from the congratumlations-to-all dept

    Someone fill me in. I don't get the joke.

    Or is it just a really bad typo?

    -
    -Be a man. Insult me without using an AC.

  • There's applications where you simply don't need transactions (anything without interdependencies between different acions). They may not be sophisticated, but they're quite numerous. Thus, a DBMS without transactions is much more useful than a knife without a handle. If it were different, MySQL would not be so widespread.
  • That limit will be lifted VERY soon. 7.1, which removes it, is in beta 3 and may be finalized any day. Almost certainly by early Feb.
  • I know it's a bit trite, but the source is there if you want to add those features yourself.
  • by JohnZed ( 20191 ) on Sunday January 21, 2001 @11:43PM (#491644)
    Umm... maybe you read a different changelog than I did, but I think that the new features are extremely substantial and useful.
    • Full text search -- This is huge for me, and probably for most other web sites that use MySQL. It's also very non-trivial to implement.
    • New table types -- MyISAM, BDB, heap, etc. are all huge improvements over the old ISAM format.
    • Replication -- Another HUGE feature: load-balance between slave databases, yum. . . This was actually sponsored by VA Linux so /. could use it, right? Wonder how it's working out these days. . .
    • Many smaller things -- Improved maintenance tools, new SQL functions, basic transactions, etc.


    I'm just disappointed they didn't bump up the version number further to let people know how substantial the release really is.

    --JRZ
  • From what I have heard, row level locking is coming in June/July timeframe.
  • According to the PostGreSQL Howto development on MySQL will eventually be stopped since it is duplicates work being done for PostGreSQL. Not that I trust it. That howto is rather strange at times. Very strange at other times.


    "Homo sum: humani nil a me alienum puto"
    (I am a man: nothing human is alien to me)

  • ==
    Postgres is trying for speed and MySQL for correctness.
    ==

    What are you talking about? I read your post five times and still can't figure out exactly what you are saying. With an opening statement of "Postgres is a mostly complete DB, with some things that need work. MySQL is a fast hack with little overhead.", one is left scratching one's head from the start. What makes Postgres "more complete" than mysql? How does one determine how much "overhead" mysql has? It looks like you might be trying to imply that postgres's SQL implementation is more complete than MySQL's but the statement is too vague to know for certain. Finishing up with "Postgres is trying for speed and MySQL for correctness", the post closes with the reader trying to figure out what "correctness" would mean as it would supposedly apply to an RBDMS. Could you be any more vague in your assessment and comparison of the two systems? All this in a +5 post... argh!

    badtz-maru
  • by American AC in Paris ( 230456 ) on Monday January 22, 2001 @08:02AM (#491648) Homepage
    from the congratumlations-to-all dept

    Someone fill me in. I don't get the joke.

    Or is it just a really bad typo?

    No, no...it's just a minor problem with MySQL data integrity. It seems to happen a lot here on Salshdot...

    information wants to be expensive...nothing is so valuable as the right information at the right time.

  • ==
    MySQL have for many years been been considered as a very unstable product and that it have been (still are probably) lacking a lot of really useful features.
    ==

    I have never heard of any complaint of stability with mysql whereas postgres versions prior to 7 were well known for eating databases. As for useful features, how about the blob support in postgres? Oh yeah, it's nonexistent. I can argue this factually because I prefer postgres but let's not turn a blind eye to its shortcomings. As for interbase, with the backdoor discovery being so recent, it would be hard to consider that platform seriously until a complete security audit was performed on the code.

    badtz-maru
  • Not every aplication is going to be "Mission Critical" we have been using MySQL in my shop for a TON of applications. (Search Engine, Account Data, and for a LARGE scale File Sharing DB) While MySQL is not oracle, it's cost/performance ratio is pretty darn good.
  • But it still doesn't have foreign key support, transactions, true stored procedures with views, a variety of integrity checks, etc....

    I would *never* consider running anything that needs 100% data safety on MySQL.... There are other open-source alternatives, or for those with open minds (and pocketbooks), closed-source databases. Each of which have much better features and support.
    -
    The IHA Forums [ihateapple.com]
  • by Animats ( 122034 ) on Monday January 22, 2001 @08:18AM (#491652) Homepage
    I've been running 3.23.28-gamma on NT for a while, with no problems at all. I'm glad it's made it to "stable". Now the main server (a Linux box) can get upgraded.

    The people who are reporting MySQL crashes should submit bug reports. The MySQL people claim they haven't lost data in years, and if that's not true, it needs to be publicized.

  • by TheFlu ( 213162 ) on Monday January 22, 2001 @06:03AM (#491653) Homepage
    I just have to rave about the database replication included with MySQL, what a fantastic feature. If you are interested in setting up replication yourself, you should read the nice tutorial on it over at PHPBuilder [phpbuilder.com]. The tutorial can be found here [phpbuilder.com].

    The replication feature has been changed a little since the tutorial was written, so you may want to check out the documentation at the MySQL site [mysql.com]. Here's a copy of my own /etc/my.cnf file from both machines, which are setup for 2-way replication, for reference (perhaps I'll get around to posting a tutorial of my own later today on The Linux Pimp [thelinuxpimp.com]

    Main server /etc/my.cnf file
    [mysqld]
    log-bin
    master-host=ip_address_of_backup
    master-user=replicate
    master-password=your_password
    server-id=1

    Backup server /etc/my.cnf file
    [mysqld]
    log-bin
    master-host=ip_address_of_main_server
    master-user=replicate
    master-password=your_password
    server-id=2

  • by Fast Ben ( 241758 ) on Monday January 22, 2001 @08:23AM (#491654)
    Does Postgres even support LEFT JOIN yet?

    The LEFT JOIN is something I wish they (Postgres) would put in, but then, Oracle don't support it either...
    The reasons I prefer Postgres are, to name a few:
    Transactions
    Sub SELECT's
    Using CASE WHEN ... END when SELECTing from tables with 30,000+ rows is very fast (another thing Oracle don't support at all)

    Postgres used (pre 6.5.3 i think) to have some memory leaks when using transactions, but this seems to have been fixed in later versions.
  • Being better is not always what matters. Often, price is what matters. Software design in the real world requires trade offs. If you are on a constrained budget, it doesn't matter if oracle is light years ahead of gpl alternatives. The gpl databases meet your budget The great thing about databases is that there is at least some standardization with SQL. So you can upgrade to a more robust, expensive database over time.
  • 3. I meant (or tried to) that sorting might be very expensive and if they dump some info in temp files, that info is already available at indexes when dealing with single tables.

    1&2. We had problems with LO+transation in PHP4 and PG7.0. The LO remained unaccesible for several minutes and the calling PHP program stayed deadlocked.

    6. When downloading files from the webserver, almost everything is done by PHP, which stores the file in a server disk. What I meant is that when importing from a client (front end) program that can run in the same machine as the backend or in another... PG doesn't allow it.

    --ricardo

  • Did you mean "integrimaty?"

    ObSubheadlineTroll: Taco's ass just declared a continent!

    Boss of nothin. Big deal.
    Son, go get daddy's hard plastic eyes.

  • great.
    so passwords are stored in plain text on potentially publicly readable config files.
  • That's because it actually cost more then SQL server. If the dolts over there at borland marketing dropped the prices and actually advertised it once in a while it might have stayed competitive. Of course their loss is your gain.
    You can go download a multiplatform, stable, easy to manage and maintain database that has been in production forever and is rock solid and has great documentation.
  • I second this statement. I would say it's been stable for at least 2 years as well, that's how long I've been using it. We are using MySQL to run a fairly large db (128+MB) (one that I would _not_ relish rebuilding) with over 8 queries/s (that's average over the last month, which is exactly how long ago I restarted mysql for an upgrade). There's nothing wrong with mysql stability-wise, definitely nothing wrong with its performance (if you turn off table locking), and if you can get by without transactions (for which there is support now with db3). I have to say I wouldn't use it for anything really important or involving money, but that's only because it's not a 'trusted name', so it's largely a perception issue.
  • As far as I know, Sybase ASE is not free for "e-commerce".
  • Excel does better, though, as it can have stored procedures, in the form of macros :)
  • No, I have ran into this problem with it. They both have there pros and cons. But, over all, I personally think PostgreSQL is the better choice. Yet, this depends on what you are doing.


    until (succeed) try { again(); }

  • Everybody always says it's my-ess-queue-ell, but I don't believe them. Try this:


    mysql> select soundex("mysql");
    mysql> select soundex("mysequel");


    You see, even the MySQL developers think it's pronounced "sequel"! :)
  • Okay here's the scoop:

    /etc/my.cnf is used to set global options
    mysql-data-dir/my.cnf is used to set server-specific options (RedHat defaults to /var/lib/mysql) or
    ~/.my.cnf to set user-specific options.

    My original post suggestion of /etc/my.cnf works fine, but it opens you up to the potential security issues discussed above, as isil [slashdot.org] so wisely suggested. I believe the proper thing to do is to put your my.cnf file in /var/lib/mysql. Thanks for the correction.

  • The next version of PostgreSQL (in beta testing right now) is supposed to support outer joins, larger row size (8-32K limit currently) and write ahead logging among other improvements.
  • by alexhmit01 ( 104757 ) on Sunday January 21, 2001 @11:50PM (#491670)
    This is what I love about the MySQL/PostgreSQL silliness. Postgres is a mostly complete DB, with some things that need work. MySQL is a fast hack with little overhead. For real solutions where you can apply heavy engineering, MySQL's speed advantages can be mitigated away. However, it serves a niche.

    If you have a little web site (or even a big one) where integrity is not key and ease of setup is important, MySQL serves that niche. If the improvments don't sacrifice their advantages, go MySQL. However, if they move towards completeness at the expense of speed... well, how silly. We already have Postgres...

    Postgres is trying for speed and MySQL for correctness. Yeah... we get two similar systems. I would rather they focus on their advantages so we maintain two useful system.

    As a lover of DB theory, I hate MySQL. As a lover of low barriers to entry, I love it. I'd hate to see MySQL lose it's niche by becoming too general.

    Alex
  • by Karora ( 214807 ) on Monday January 22, 2001 @12:27AM (#491671) Homepage

    Performance is critical in _any_ database, and you can't add features at the expense of performance and expect to keep your customers happy. You can add slowish implementations of new features, but you better not downgrade existing performance.

    PostgreSQL 7.1 is now in beta and should be out by the end of February (maybe earlier). With support for column sizes up to 2GB(!), as well as many other refinements, I certainly don't think that they are sacrificing feature efforts to performance enhancement.

    That's not to say I find it slow either. My most recent web development (replacing a prior ASP/MSSQL/IIS installation :-) at http://newsroom.co.nz/ [newsroom.co.nz] manages to do around 30-odd queries for the front page and still pops it out in just under 0.1 of a second on a Duron 700 based system.

    I looked at MySQL (and I help out a client who uses it on occasion), but the potential performance improvement isn't worth it to me to lose all those neat features.

  • I like MySQL, but I am hard pressed to call what they implemented replication. It has zero ability to handle fault tolerance and I don't think that people who are accustom to the big comerical databases are really going to consider it for critical applications until this is implemented well.
    I really wish they would have just called this a RO load balancing option, since when you invoke the word replication it means a lot more.
  • Well, performance (defined as quickness) is nice, but it is only one of three critical prongs, the other two being integrity and availability. If it's fast, but tends to crash halfway through a write operation, you don't have integrity. If it's stable but has to be taken down for an hour a day for maintenance, you don't have availability.

    The glib statement is that among speed, integrity, availability and affordability, you can pick three. InterBase [borland.com] kind of spoils the equation, but when you compare MySQL, PostgreSQL, and, say, Oracle, you get the idea.

    Disclaimer I had Chinese food for lunch.

    --

  • Correctness = Proper RDBMS Implementation.

    SQL is a language for interfacing with RDBMS, not a reason for existance.

    I've worked with both. I like that MySQL is fast with little effort. Connection pooling can mitigate the speed issues, but there is more work in that.

    Again MySQL is good for a user with little RDBMS needs that needs a quick way to access data. Postgres is close to being a "real" database.

    Alex
  • You could already do that before with some trickery :

    SELECT something, (RAND()*10) as random FROM table ORDER by random LIMIT 1

    the *10 is necessary or MySQL would optimize the request and compute RAND() one time for all rows...
  • by kaunio ( 125290 ) on Sunday January 21, 2001 @10:54PM (#491688) Homepage
    If find the big support for MySQL somewhat surprising. When I'm running a RDBMS, I want stability, even if it happen to be a commercial or a open source one.

    MySQL have for many years been been considered as a very unstable product and that it have been (still are probably) lacking a lot of really useful features.

    In the open source world, I find two RDBMS especially good. PostgreSQL [postgresql.org] and Interbase [interbase.com]. They are both fine products and probably near commercial grade RDBMS standard.

    So even if MySQL is now considered stable. So what? We have other choices, which have been developed with great care for many years and have been added features from their stability, not the opposite.

    So in my humble opinion, if you want to run anything (semi)serious, definately do not run MySQL, there are MUCH better options out there.

Math is like love -- a simple idea but it can get complicated. -- R. Drabek

Working...