Re: [PHP] MySQL after oracle, still Wise?, was Web application design .......
On Tuesday 02 June 2009 11:36:28 pm optoma...@rogers.com wrote: Everybody has given Angus really great advice in this previous thread and I have learned a lot too. I hope no one mines the fork but I am in the exact same situation as Angus. If anyone could spare a bit of time regarding application infrastructure I would really appreciate it. I know there are lots of databases out there and PostgreSQL is held in high regard but the overwhelming majority of examples seem to use MySQL. Considering that Oracle has bought Sun, do you think it is still wise to use it for new applications? Oracle does not have much street cred in open source circles, maybe they'll cause trouble later and MySQL was already forking was it not? I'd like to use the same DB for a few years. I am attracted to building an application from scratch but I will never get an object relational mapper to work without a framework. If I go the scratch route, I'd better get my database done right(as was advised in the previous thread!)and getting that right probably starts with choosing the right DB. Any thoughts?-Patrick Check the popular projects (phpBB, TYPO3, Drupal) when they start to move MySQL to somewhere it time to start moving. And if you so much thinking about future DB change. Just wrote compatible sql and use multi drive layer (phpADO db). And you are problem free Regards -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
RE: [PHP] MySQL after oracle, still Wise?, was Web application design .......
From: Sancar Saran And if you so much thinking about future DB change. Just wrote compatible sql and use multi drive layer (phpADO db). And you are problem free I have some questions about this suggestion. We currently have production systems using Postgres, Sybase ASA, Oracle and MS SQL Server. Only one product currently supports more than one, it can be installed with ASA or connect to an existing Oracle server. This unfortunate mix was brought about by several acquisitions over the past ten years. We also have a group talking about using MySQL for a portal project. One product did use MySQL prior to their switch to per server license fees, which made them far too expensive for the distributed system they were used in. So that project switched to Postgres. But what is the ADO layer going to look like in order to support any or all combinations of these back ends? How much of a kludge will it have to become? Is there any code out there that will support most of these, or do we have to write it all ourselves? Most of my SQL experience has been with Sybase ASA. I am playing with Postgres a little bit now, and the differences can be both subtle and glaring. But I don't know either one well enough to understand how to design an ADO interface, let alone how to bring in the other options. Thank you, Bob McConnell -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] MySQL after oracle, still Wise?, was Web application design .......
Sadly, Mr. Saran wasted a lot of time writing a pluggable backend db layer, as one is built into PHP now, PDO: http://us2.php.net/pdo Sybase / MsSQL: http://www.php.net/manual/en/ref.pdo-dblib.php Postgres: http://us2.php.net/manual/en/ref.pdo-pgsql.php Oracle: http://us2.php.net/manual/en/ref.pdo-oci.php The only difference in using them is the dsn you pass to the constructor, which can even be dynamically generated if you see fit. The actual usage from driver-to-driver is the same; I've used it on postgres, mysql and sqlite. Based from the meeting notes of several 6.0 developer notes, it might or might not be the only database extension not in PECL soon. On Wed, Jun 3, 2009 at 8:51 AM, Bob McConnell r...@cbord.com wrote: From: Sancar Saran And if you so much thinking about future DB change. Just wrote compatible sql and use multi drive layer (phpADO db). And you are problem free I have some questions about this suggestion. We currently have production systems using Postgres, Sybase ASA, Oracle and MS SQL Server. Only one product currently supports more than one, it can be installed with ASA or connect to an existing Oracle server. This unfortunate mix was brought about by several acquisitions over the past ten years. We also have a group talking about using MySQL for a portal project. One product did use MySQL prior to their switch to per server license fees, which made them far too expensive for the distributed system they were used in. So that project switched to Postgres. But what is the ADO layer going to look like in order to support any or all combinations of these back ends? How much of a kludge will it have to become? Is there any code out there that will support most of these, or do we have to write it all ourselves? Most of my SQL experience has been with Sybase ASA. I am playing with Postgres a little bit now, and the differences can be both subtle and glaring. But I don't know either one well enough to understand how to design an ADO interface, let alone how to bring in the other options. Thank you, Bob McConnell -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] MySQL after oracle, still Wise?, was Web application design .......
On Tue, Jun 02, 2009 at 04:36:28PM -0400, optoma...@rogers.com wrote: Everybody has given Angus really great advice in this previous thread and I have learned a lot too. I hope no one mines the fork but I am in the exact same situation as Angus. If anyone could spare a bit of time regarding application infrastructure I would really appreciate it. I know there are lots of databases out there and PostgreSQL is held in high regard but the overwhelming majority of examples seem to use MySQL. Considering that Oracle has bought Sun, do you think it is still wise to use it for new applications? Oracle does not have much street cred in open source circles, maybe they'll cause trouble later and MySQL was already forking was it not? I'd like to use the same DB for a few years. I am attracted to building an application from scratch but I will never get an object relational mapper to work without a framework. If I go the scratch route, I'd better get my database done right(as was advised in the previous thread!)and getting that right probably starts with choosing the right DB. First, you don't need an ORM. I'll leave it at that. Second, if you're doing something which will be supported on internal servers, choose PostgreSQL. MySQL has deficiencies caused by its development by programmers. PostgreSQL was developed by DBAs. And frankly, the choice of storage engines in MySQL is crazy. Some are incapable of handling transactions, for example. You have to do research and figure out which one has the features you need. Another random example of MySQL deficiency is that it does not natively support boolean fields. And at least some of the engines don't support foreign keys, IIRC. MySQL has the popularity it does because 1) it has a *company* behind it, which PostgreSQL does not; 2) it is relatively easy to administer; 3) at one time it was faster than PostreSQL; 4) inertia/momentum. As for Oracle/Sun/MySQL, because MySQL is open source, there are already forks of it. If Sun decides to get pissy, a new version of MySQL can be cobbled together by the open source community in short order. No one knows what Oracle will do with MySQL, ultimately, but I wouldn't let it worry you too much. Your choice of DB won't really matter that much. Any database should do pretty much whatever you ask of it. You can't actually go wrong with any database. Your choice of database will mostly affect two things: 1) how much work you have to do that the database won't do for you, and 2) expense. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
Re: [PHP] MySQL after oracle, still Wise?, was Web application design .......
High-performance builds of mysql are still faster. And with 5.4 integrating a lot of performance boosts, I'd expect MySQL to retain that lead for a lot longer. There's also a lot more guides / support for MySQL around, as well as having a more robust choosing of UDF's, if you were to need them. PostgreSQL is a great RDBMS, on the other hand, if you're a purist. It's more close to the SQL standards and has a different featureset. While MySQL-unique features are designed to help normal people with complex things - GROUP_CONCAT, for example - PostgreSQL-unique features are designed for complicated tasks handled by well-qualified people (custom data types, arrays, etc). Common knowledge is that MySQL lacks a lot of integrity features, but this isn't (as) true any more, with the introduction of foreign keys and constraints in InnoDB. Regarding storage engines, just use InnoDB by default and forget about it; in the rare cases where a different engine is better suited, you can change it later. The way I'd suggest is that if you're either willing to learn a lot of SQL or have already learned it in a class or something, go with postgres. If you just want to get it done (or care a lot about performance), go with MySQL. On Tue, Jun 2, 2009 at 9:25 PM, Paul M Foster pa...@quillandmouse.comwrote: On Tue, Jun 02, 2009 at 04:36:28PM -0400, optoma...@rogers.com wrote: Everybody has given Angus really great advice in this previous thread and I have learned a lot too. I hope no one mines the fork but I am in the exact same situation as Angus. If anyone could spare a bit of time regarding application infrastructure I would really appreciate it. I know there are lots of databases out there and PostgreSQL is held in high regard but the overwhelming majority of examples seem to use MySQL. Considering that Oracle has bought Sun, do you think it is still wise to use it for new applications? Oracle does not have much street cred in open source circles, maybe they'll cause trouble later and MySQL was already forking was it not? I'd like to use the same DB for a few years. I am attracted to building an application from scratch but I will never get an object relational mapper to work without a framework. If I go the scratch route, I'd better get my database done right(as was advised in the previous thread!)and getting that right probably starts with choosing the right DB. First, you don't need an ORM. I'll leave it at that. Second, if you're doing something which will be supported on internal servers, choose PostgreSQL. MySQL has deficiencies caused by its development by programmers. PostgreSQL was developed by DBAs. And frankly, the choice of storage engines in MySQL is crazy. Some are incapable of handling transactions, for example. You have to do research and figure out which one has the features you need. Another random example of MySQL deficiency is that it does not natively support boolean fields. And at least some of the engines don't support foreign keys, IIRC. MySQL has the popularity it does because 1) it has a *company* behind it, which PostgreSQL does not; 2) it is relatively easy to administer; 3) at one time it was faster than PostreSQL; 4) inertia/momentum. As for Oracle/Sun/MySQL, because MySQL is open source, there are already forks of it. If Sun decides to get pissy, a new version of MySQL can be cobbled together by the open source community in short order. No one knows what Oracle will do with MySQL, ultimately, but I wouldn't let it worry you too much. Your choice of DB won't really matter that much. Any database should do pretty much whatever you ask of it. You can't actually go wrong with any database. Your choice of database will mostly affect two things: 1) how much work you have to do that the database won't do for you, and 2) expense. Paul -- Paul M. Foster -- PHP General Mailing List (http://www.php.net/) To unsubscribe, visit: http://www.php.net/unsub.php
