671Chapter 36PEAR Database FunctionsMySQL and PostgreSQL the (Dedicated web hosting) only adjustments
671Chapter 36PEAR Database FunctionsMySQL and PostgreSQL the only adjustments you d have to make would be in the codedirectly concerned with accessing the database opening a connection, sending a query, and so on. You d have to specify that the new database is of the Oracle variety, and providedetails about its hostname and other aspects of its implementation. In reality, to supportnumerous databases, you might have to make some adjustments to your SQL statements aswell, because all database servers differ in the way they implement SQL. Beyond the ANSI- standardized basics, database servers can vary considerably in the syntaxes they consideracceptable. The new database server will have to be configured with the databases, tables, column names, and rows that the migrating application requires. The decision to use a database abstraction layer should always be made on a project-by- project basis. Feel free to heavily discount the opinions of coders who tell you that they are always good or always bad. Also discount those who claim that the benefit of databaseabstraction is that you yourselfwill be able to switch between databases easily. That happensvery rarely (and is usually a sign of much bigger underlying errors in judgment) and shouldtherefore never be a major consideration in designing a system. The actual benefit of sup- porting multiple databases is if your usersneed to use multiple databases. The rule of thumbis, the more users (in the sense of separate installations) of your application there are, themore demand there will be for numerous databases and therefore the more it might gainfrom PEAR DB or one of its competitors. Most standalone Web sites will benefit very little from PEAR DB, because the extra weight ofthe abstraction layer is a much bigger concern than the small possibility of having to changedatabases in the future. Contractors need to weigh the potential gains to them of reusabilityover the potential loss to the client of performance. In situations where you might need tointegrate numerous disparate PHP packages, PEAR DB might help or hurt you. The one case where PEAR DB can clearly be a win is a standalone application that will havemultiple installations, needs to run on as many DBMS as possible, has a developer communitywilling to take on the added work to support multiple databases, and doesn t need to be veryperformative. Many open source and commercial PHP packages such as wikis, blogware, trouble-ticket systems, bulletin boards, and so on do meet all these criteria and wouldtherefore benefit from a database abstraction layer. Portability is almost certainly a much big- ger issue for this type of project than it will be for a Web developer working on a single site although even here, many packages choose their own lighter-weight solutions to databaseabstraction rather than PEAR DB so don t be so dazzled by the fact that some big-namePHP project uses PEAR DB that you forget that your own needs might be very different. One common reason for using PEAR DB is simply because the individual developer happensto prefer a fully object-oriented database connection paradigm. This is fine, but technicalleads and architects should be aware that there are freely available database-specific classesthat may be more performative and maintainable than PEAR DB. The main point stands, however: If you designed your application to use the PEAR DBclasses, very little of your application s PHP code will require modification in order to movethe application from one database management server to another. That s a real advantage if you anticipate numerous users who might wish to use a wide selection of databases to runyour application. Caution41
If you are in need for cheap and reliable webhost to host your website, we recommend http web server services.