Re: [PHP-DB] Re: PostgreSQL versus MySQL
Has this thread got anything at all to do with PHP? -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DB] Re: PostgreSQL versus MySQL
On Mon, 9 Apr 2001, Bob Hall wrote: MySQL is providing an SQL frontend to a bunch of tables and indices, that is it ... it is up to the programmer to handle the "managing of data" part where it revolves around being relational ... I've developed database apps in which the data was inserted in batches, which meant that transactions were unnecessary. On the other hand, the apps needed an RDBMS to handle normalized tables. Okay, so you start the insert, and one of the records in the batch failed to insert ... then what? You manually rollback the other ones? Well, with MySQL, you start the batch over again, but use IGNORE in the INSERT statement, and MySQL passes over the records that are already inserted. A "transaction" is effectively a batch ... if one of the batch fails, either the programmer has to manually remember and roll everything back, or you let the database itself handle it .. No, a batch isn't very much like a transaction. In OLTP, the DBA doesn't initiate a transaction, has no control over it, and can't recover lost data. In batch processing, the DBA initiates and controls the batch, and any missing data is in the file. Futhermore, some datawarehousing and web projects involve relational databases that are inserted and updated in batches at night, making transactions unnecessary. See above ... I have an application that loads ACT! data into a database every night ... each contact in the system has something like 20-30 fields associated with them ... if, for some reason, *one* of those fields fail to insert properly, that contact is invalid, and the transaction that its wrap'd in automatically rolls back everything I've done since the start of the transaction, so that there is no record of that failed contact except in my error log file ... no "incomplete" data, no stray data ... If your DBMS doesn't give you the capability to restart the batch at the point where it failed, then that's necessary. I have a hard time believing, though, that you can't do that in whatever DBMS you're using. I'll concede that transactions are preferable in that circumstance, but I also have experience with databases where transactions have nothing to offer. batch or interactive doesn't matter ... its the data integrity that is maintained by using transactions that is key ... I'm not trying to claim that MySQL can handle all types of db applications. MySQL is a niche product that was never designed to handle certain types of applications. My point is that whether a DBMS is relational depends on the structure of the data it deals with. Whether it needs to support transaction depends on the environment it operates in. I think that your point is that in an OLTP environment, lack of transaction support screws up the data to the point that the database becomes useless. I agree, but not all RDBMSs operate in an OLTP environment. No, my point is that in any environment that needs the features of being "relational" (data spread across multiple tables, link'd together), IMHO, transactions are required in order to maintain data integrity *unless* the programmer himself wants to take it upon himself to maintain this data integrity in the application layer ... ... if data in table C requires that the data saved to table B was stored, then if table B fails, the transaction should fail and the changes to table A should be reversed automatically ... *shrug* By extension, if the data to table C fails for whatever reason, the data put to Tables A and B should be automatically reversed ... ... or the missing data inserted. How did DBAs handle batch processing before there were transactions? Bob Hall Know thyself? Absurd direction! Bubbles bear no introspection. -Khushhal Khan Khatak MySQL list magic words: sql query database -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DB] Re: PostgreSQL versus MySQL
Doug, There's something wrong here. This is the internet, we're disagreeing, but we're not flaming each other. If we keep this up, they'll revoke all our software licenses because of our noncompliant behavior. Hi Bob! That would make a very interesting study. Attempting to come up with a modern definition of RDBMS. Of course, it would be only an academic exercise...but it would be a fascinating paper if any youngsters reading this from a university dorm room or computer lab would like to tackle it. It's too late. Everyone has their own definition of RDBMS, which they aren't going to give up. :) Yes, the SQL standard is a moving target. But so are the likes of COBOL and FORTRAN. So all one can do is attempt to produce a product that at least attempts to conform somewhat to some published version of the standard. It is true that no product adheres perfectly to ANSI SQL standards. I believe that that's primarily because, as it exists, SQL is an incomplete and underdefined language. However, some products appear to be more in compliance than others. But I offer up my pet peeve (MySQL's bastardization of LIKE and the recent addition of the BINARY keyword instead of fixing the problem) as an example of MySQL's blatant non-conformance. There are examples in PostgreSQL's history (which indeed has had a turbulent past) of similar things, but they seem to try with every release to bring themselves more in conformance with either ANSI's published standard or at least the generally accepted implementation of what ANSI has published when the standard is unclear. MySQL just complicates an already bizarre language with even more bizarre constructs (BINARY is a recent example). From Paul's book: "BINARY causes number-to-string conversion." It may not comply with the letter of the SQL standards, but it certainly complies with the spirit; it's completely non-intuitive! I would tend to agree with THH that if MySQL is a database management system it should offer up more than just their SQL-like front end to a bunch of indexed disk files. I've read their site. (I like their site and their documentation better than PostgreSQL's site and documentation, by the way.) Their excuse for not conforming to SQL standards and for not implementing important features is that they would slow it down unnecessarily. Two things about that: * I do not think things like triggers and transactions are unnecessary, and * According to recent reports, PostgreSQL is no longer a dog. Of course, this is beta code...but all indications are that it not only performs admirably, but it also exhibits quite acceptable performance under load. That's something that a roughly similar MySQL installation appears to have some problems with, according to the same studies. (Major reference would be SourceForge, but there have been some other reports bandied about. Note that one must take anything resembling a benchmark as an advisory, not gospel. Also note that for every experience or study that favors one product over another, there will undoubtedly be another that says the opposite. So I encourage everyone to take all such reports as ADVISORY ONLY and make up their own mind.) Now, PostgreSQL has triggers and transactions and features that MySQL specifically omits (and indeed eschews) because they say those features are not important and they would slow everything down. Do the stories we're hearing about the new PostgreSQL offer evidence against MySQL's seemingly firm stance against triggers and transactions? I don't know. I suppose time will tell. If anyone is actually following this conversation (other than us die hards), please don't take all of this as MySQL bashing. That's not what I'm trying to do. I use MySQL myself for certain things. As a matter of fact, I find that you can turn even the a Win32(R)(TM)(C)(BC)(AD) machine (which is what I use for my favorite email client, Eudora) into a web development powerhouse with the Win32 versions of Apache, PHP, MySQL, The Gimp and WinCVS. This laptop that I'm typing on right now is outfitted as described. I couldn't buy this laptop without Win98 so I am still using it. (Maybe my next laptop won't be so limited?) Anyway, getting PostgreSQL to work on Win32 is a PITA. PostgreSQL does work on Win32. I know because I got it to work. But I didn't like it, and stopped using it. Doug I will agree with everything thing you say, with the understanding that there are many projects for which the functionality missing from MySQL isn't necessary. (And with the understanding that there are many projects for which it is necessary.) I have my own personal list of non-standard aspects of the MySQL SQL interface that tick me off, but I still prefer it to the QBE modules in Paradox and Access. And having used versions of Paradox who's support for SQL functionality was very poor, MySQL doesn't strike me as seriously nonconforming. Just the same, more compliance is better
RE: [PHP-DB] Re: PostgreSQL versus MySQL
I'm rooting for PostgreSQL to become the open source app that ate Oracle. MySQL will never be capable of that, but I don't think it needs to be. There will always be a niche for small, quirky apps that have just enough functionality to get the job done and keep the learning curve short and shallow. sorry to interject. i'm using posatgresql at work for a calendar system and have found it an excellent tool. still learning and i'm sure i've only scraped the surface but it copes well with 100+ users whihc is what we want. i've also used mysql at home and for web projects and found it ok. to make my point though which is this. i ,too, also hope that postgresql will become the product that ate Oracle, along with MS SQL Server. the groundwork is there and it gets better with each release. my company is on the brink of dropping MS altogether (for internal network and server needs) and i hope it is one of many. Bob Hall Know thyself? Absurd direction! Bubbles bear no introspection. -Khushhal Khan Khatak -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED] -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DB] Re: PostgreSQL versus MySQL
On Sun, 8 Apr 2001, Bob Hall wrote: Doug, You've posted your usual good sense, combined with one statement I strongly disagree with. One of these products is a relational database management system. The other is a quasi-SQL-like-front-end-to-systems-of-indexed-files that has never concerned itself with things like standards conformance. The implication is that MySQL is not an RDBMS. The only attempt I know of to define an RDBMS was Codd's, and no DBMS has ever met the criteria he published in a paper in the late 80s (1986?). Even though Oracle doesn't meet the criteria of the best known definition (only definition?) of an RDBMS, we all seem to agree that Oracle is an RDBMS. An RDBMS is a DBMS designed to manage a relational database, and a database is relational because it stores data in linked, normalized tables. The only thing I question in this is that without transaction support, what exactly is MySQL "managing"? The data in the normalized tables. MySQL is providing an SQL frontend to a bunch of tables and indices, that is it ... it is up to the programmer to handle the "managing of data" part where it revolves around being relational ... I've developed database apps in which the data was inserted in batches, which meant that transactions were unnecessary. On the other hand, the apps needed an RDBMS to handle normalized tables. Also, note, that even today, MySQL does not handle transactions, Berkeley DB does, and its purely optional, and per table. So, effectively, it has "transactional tables", its not a "transactional system" ... if you didn't define a table for transactions when you created it, you just created your weak link ... again, its not MySQL that manages the system, its the programmer who has to do it ... *shrug* Transactions have to do with the environment the DBMS operates in, not the type of database. Relational database theory was developed when multi-user OSs were still pretty new, and database processing was batch processing. In that type of environment, ACIDity isn't an issue. In an OLTP environment, even OODBMSs have to deal with transactions. At the same time, the lack of transaction support doesn't disqualify an OODBMS from being object oriented. Futhermore, some datawarehousing and web projects involve relational databases that are inserted and updated in batches at night, making transactions unnecessary. I'm not trying to claim that MySQL can handle all types of db applications. MySQL is a niche product that was never designed to handle certain types of applications. My point is that whether a DBMS is relational depends on the structure of the data it deals with. Whether it needs to support transaction depends on the environment it operates in. I think that your point is that in an OLTP environment, lack of transaction support screws up the data to the point that the database becomes useless. I agree, but not all RDBMSs operate in an OLTP environment. Bob Hall Know thyself? Absurd direction! Bubbles bear no introspection. -Khushhal Khan Khatak -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DB] Re: PostgreSQL versus MySQL
On Mon, 9 Apr 2001, Bob Hall wrote: MySQL is providing an SQL frontend to a bunch of tables and indices, that is it ... it is up to the programmer to handle the "managing of data" part where it revolves around being relational ... I've developed database apps in which the data was inserted in batches, which meant that transactions were unnecessary. On the other hand, the apps needed an RDBMS to handle normalized tables. Okay, so you start the insert, and one of the records in the batch failed to insert ... then what? You manually rollback the other ones? A "transaction" is effectively a batch ... if one of the batch fails, either the programmer has to manually remember and roll everything back, or you let the database itself handle it .. Futhermore, some datawarehousing and web projects involve relational databases that are inserted and updated in batches at night, making transactions unnecessary. See above ... I have an application that loads ACT! data into a database every night ... each contact in the system has something like 20-30 fields associated with them ... if, for some reason, *one* of those fields fail to insert properly, that contact is invalid, and the transaction that its wrap'd in automatically rolls back everything I've done since the start of the transaction, so that there is no record of that failed contact except in my error log file ... no "incomplete" data, no stray data ... batch or interactive doesn't matter ... its the data integrity that is maintained by using transactions that is key ... I'm not trying to claim that MySQL can handle all types of db applications. MySQL is a niche product that was never designed to handle certain types of applications. My point is that whether a DBMS is relational depends on the structure of the data it deals with. Whether it needs to support transaction depends on the environment it operates in. I think that your point is that in an OLTP environment, lack of transaction support screws up the data to the point that the database becomes useless. I agree, but not all RDBMSs operate in an OLTP environment. No, my point is that in any environment that needs the features of being "relational" (data spread across multiple tables, link'd together), IMHO, transactions are required in order to maintain data integrity *unless* the programmer himself wants to take it upon himself to maintain this data integrity in the application layer ... ... if data in table C requires that the data saved to table B was stored, then if table B fails, the transaction should fail and the changes to table A should be reversed automatically ... *shrug* By extension, if the data to table C fails for whatever reason, the data put to Tables A and B should be automatically reversed ... -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Odp: [PHP-DB] Re: PostgreSQL versus MySQL
Od: "Bob Hall" [EMAIL PROTECTED] Temat: Re: [PHP-DB] Re: PostgreSQL versus MySQL The implication is that MySQL is not an RDBMS. The only attempt I know of to define an RDBMS was Codd's, and no DBMS has ever met the criteria he published in a paper in the late 80s (1986?). Even though Oracle doesn't meet the criteria of the best known definition (only definition?) of an RDBMS, we all seem to agree that Oracle is an RDBMS. An RDBMS is a DBMS designed to manage a relational database, and a database is relational because it stores data in linked, normalized tables. The only thing I question in this is that without transaction support, what exactly is MySQL "managing"? The data in the normalized tables. Of 12 Codd's rules (1985), MySQL doesn't meet four: 5 - full internal language implementation with transactional processing support; 6 - using views for data modification; 10 - autonomous referential integrity mechanism built into database; 11 - autonomous data distribution. Of SQL-92 instructions MySQL doesn't implement following: CREATE | DROP SCHEMA, DECLARE LOCAL TEMPORARY TABLE, CREATE | ALTER | DROP DOMAIN, CREATE | DROP CHARACTER SET, CREATE | DROP COLLATION, CREATE | DROP TRANSLATION, CREATE | DROP VIEW, ALLOCATE | DECLARE | OPEN | CLOSE CURSOR, COMMIT, ROLLBACK, FETCH, CLOSE, CREATE | DROP ASSERTION, SET CONSTRAINTS MODE, SET SESSION AUTHORIZATION, SET TRANSACTION MODE, SET NAMES, SET SCHEMA, SET TIME ZONE, ALLOCATE | SET | GET | DEALLOCATE DESCRIPTOR, DESCRIBE, PREPARE, DEALLOCATE PREPARE, EXECUTE, EXECUTE IMMEDIATE, GET DIAGNOSTICS This set is about 85% of SQL-92 standart, but i didn't see any DBMS that implements that all. Of SQL-92 keywords, about 65% is absent in MySQL, but they are not too often used even if they are present with significant exception of trigger and procedural language. Cheers Jarek Zgoda -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DB] Re: PostgreSQL versus MySQL
On Sun, 8 Apr 2001, Bob Hall wrote: Doug, You've posted your usual good sense, combined with one statement I strongly disagree with. One of these products is a relational database management system. The other is a quasi-SQL-like-front-end-to-systems-of-indexed-files that has never concerned itself with things like standards conformance. The implication is that MySQL is not an RDBMS. The only attempt I know of to define an RDBMS was Codd's, and no DBMS has ever met the criteria he published in a paper in the late 80s (1986?). Even though Oracle doesn't meet the criteria of the best known definition (only definition?) of an RDBMS, we all seem to agree that Oracle is an RDBMS. An RDBMS is a DBMS designed to manage a relational database, and a database is relational because it stores data in linked, normalized tables. The only thing I question in this is that without transaction support, what exactly is MySQL "managing"? MySQL is providing an SQL frontend to a bunch of tables and indices, that is it ... it is up to the programmer to handle the "managing of data" part where it revolves around being relational ... Also, note, that even today, MySQL does not handle transactions, Berkeley DB does, and its purely optional, and per table. So, effectively, it has "transactional tables", its not a "transactional system" ... if you didn't define a table for transactions when you created it, you just created your weak link ... again, its not MySQL that manages the system, its the programmer who has to do it ... *shrug* -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
[PHP-DB] Re: PostgreSQL versus MySQL
On the contrary, MySQL is much better at handling table crashes and data corruption than PostgreSQL is. What you may have heard is that due to lack of transaction support, critical data may be lost "in transit" from your application to the database, in the event of a system crash or a dropped connection. Well, guess what? MySQL now supports transactions in its latest release. Using transactions is probably not really needed though, unless your data is critical, such as credit card numbers. As for a full comparison between the two, I think the bottom line is that MySQL is slightly more light-weight, but easier to use and faster than PostgreSQL. So if you're looking for a database for a relatively noncritical web application, I'd say go with MySQL, especially since that's what you already have experience with. One of the upcoming features in MySQL I'm really looking forward to is query caching, which is a great feature for web applications. Jon Valvatne Can someone outline the differences between the two? I am partial to MySQL from experience but want to get a good view of why one is better than the other. Also, I've heard that you will lose data with MySQL if a system failure should occur. Thanks. Matt -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
Re: [PHP-DB] Re: PostgreSQL versus MySQL
As for a full comparison between the two, I think the bottom line is that MySQL is slightly more light-weight, but easier to use and faster than PostgreSQL. So if you're looking for a database for a relatively noncritical web application, I'd say go with MySQL, especially since that's what you already have experience with. tim perdue recently negated this whole 'speed' argument with the Sourceforge migration ... if you are planning on having a low-hit-rate web site, go with MySQL, but as soon as you get into concurrent users, MySQL's performance drops like a rock ... See the numbers that Tim ran to compare the two: http://www.phpbuilder.com/columns/tim20001112.php3 One of the upcoming features in MySQL I'm really looking forward to is query caching, which is a great feature for web applications. Something that PostgreSQL has always done ... glad they are starting to catch up ... -- PHP Database Mailing List (http://www.php.net/) To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] To contact the list administrators, e-mail: [EMAIL PROTECTED]
