ORACLE vs MYSQL
Posted 27 February 2007 - 07:18 PM
Posted 21 June 2007 - 06:27 PM
Not to be a name dropper but the ones I have worked with are....
Oracle = For the price it is worth the support and the database.
SAPDB = SAP's Database and now its MAX DB
MYSQL = This is great piratical database.
To me they are all do the same work. If I had to choose what one to work with it would be MYSQL. It is a free product, and everyone has worked with it, and made many modifications as well as documentation on how to do anything. I feel that this is the best thing when developing an app that works with a database. It allows for better support.
Posted 11 July 2007 - 02:33 AM
Posted 30 July 2007 - 06:15 AM
Posted 20 November 2007 - 08:27 AM
With that said, here's a few observations I have for you. Oracle is a database that runs on just about every computing platform anyone is using, while mysql is predominately a unix program (although there is a windows and mac version). Oracle has scalability features and a mature set of features that go substantially beyond what MySQL offers. One of Oracle's great strengths is it's concurrency system, that by default offers versioning, known in Oracle terms as "read consistent views." Basically, with Oracle, there is no need to have readers and writers contend with each other. For example, let's say that you are doing a query of a table of transactions in order to create a financial report. The query needs to go through the entire table row, adding credits and subtracting debits. In most databases, the solution to this problem is to put a "read" lock on the table, which would prevent updates from occurring to any of the rows of the table for the duration of the query. If this was a large table, this locking period could really slow things down and be very undesirable for a high transaction system. Suffice it to say, that Oracle doesn't require read locks of any kind, and that query runs fine and will not interrupt inserts, updates and deletes. Oracle also offers highly functional stored procedures and triggers, including the ability to write sprocs in either pl/sql language or Java. MySQL zealots love to debate this stuff, but point of fact there's a huge list of features Oracle has that MySQL doesn't, and probably won't anytime soon. The thing that people typically point to is that MySQL's default mode (using the myisam engine) doesn't have support for transactions, or declarative referential integrity, both of which are meat and potatoes RDBMS features you find in about any other rdbms database (including Postgresql btw).
MySQL is a bit of an oddity in the relational database world. It offers a unique feature that depending on how you look at it, is either a strength or a weakness: that of storage engines. As I mentioned, MySQL's myisam engine doesn't support transactions, while the Innodb engine does. This allows mysql to do some very cool things with specialized engines.
Where PHP is concerned, MySQL has a property that works very well, in that PHP has page scope. This means that PHP offers no persistence mechanism ... when a script runs it creates variables, and when that script is done, all the variables are garbage collected. Because MySQL connections are very lightweight, there's almost no overhead in creating a MySQL connection, which works well with PHP's design.
Oracle on the other hand, has a heavy connection process that can on the order of seconds. Oracle has a session concept, and connections in general should be pooled and reused. With Oracle, you make one connection if you need to do multiple queries, and issue the seperate queries using oracle sessions. Often people who don't understand this don't realize that they needed to use the ora_pconnect rather than the ora_connect. There was almost no info on this in the old oracle client manual pages.
Another key difference that helps with PHP is that MySQL's query execution process is far more lightweight in general use than Oracle's. Oracle makes extensive use of query execution caching, however, the use of dynamically generated SQL statements as is common in PHP applications will result in very poor performance, because these statements will not be cached by Oracle. Oracle requires the use of bind variables in order for Oracle to pull statements from it's query cache. Many people find the work that you need to use bind variables to be tedious, although the increased interest in PHP security, and the development of PHP PDO are both developments that may have helped people appreciate the security benefits that can be had.
Plainly speaking, PHP just didn't work very well with Oracle in the past, and was a bitch to get setup, requiring a pretty extensive understanding of Oracle, and the various client environment variables and client libraries. In comparison, getting PHP setup with MySQL was simple and easy.
In the past couple of years, Zend entered into some agreements with Oracle post PHP 5, and work on integration with the Oracle library was stepped up significantly. Part of that was a rewrite of the oracle client library to support 8,9 & 10 features, and BLOB types. This client offers additional functions, as well as a variety of variables that allow you to tune connection caching, along with articles you can find on the Oracle Technology network, using PHP with Oracle is a lot more viable than it used to be.
Posted 26 November 2007 - 03:29 AM
For me, I really go for "Oracle". Its the best option you can have when it comes to database, though there is this "Cache" which, some says, had already surpass "Oracle", but "Oracle" has already been established well in the industry compared to this "Cache". Ahm, but the sad part of this is, "Oracle" (as what others already have said in this topic) is not FREE.
Posted 31 December 2007 - 11:25 AM
0 user(s) are reading this topic
0 members, 0 guests, 0 anonymous users