- Using DBI to Solve a Real World Problem
- Open Database Connectivity (ODBC)
As the Web makes inroads into corporate intranets, one of the primary uses of Web technology is providing an interface to data stored in corporate databases. One of the strengths of the Web in these environments lies in its ability to provide a platform independent, open interface to these corporate databases. Database interfaces also play a key role in online shopping, automated order processing, and information gathering and distribution applications. In all of these applications, using a professional UNIX-based database package such as Oracle, Sybase, or Informix (to name a few) is almost always the best alternative. These packages provide a powerful, configurable, and expandable solution. Unfortunately, manufacturers of these professional database packages have developed differing proprietary interfaces for their databases. Obviously, this makes life difficult for programmers who want to write their own Web-based database front ends to access data from these various databases.
In this chapter, we will look at how Perl5 and a set of modules provide a very elegant solution to this problem. You will be introduced to a set of Perl5 modules called DBI that provide a consistent database interface (API) independent of the actual database being used. We will also look at Microsoft's Open Database Connectivity Programming Interface, or ODBC API. ODBC is quickly being adopted by most, if not all, major database server vendors as the standard database interface. Once all database vendors add the ODBC interface to their previously proprietary interfaces, solutions like DBI will not be necessary.
Using Perl as a database interface, or front end, through the Web has many advantages. This approach is very flexible (there are few or no constraints on what you can do) and very easy to experiment with.
Is investing in a professional database package really worth it? Absolutely. With standard APIs such as DBI and ODBC emerging, investing your time developing your application to utilize a professional database makes sense. Portability from database to database has never been easier. Investing your resources in a professional database also makes the transition from a small enterprise to a large enterprise easier. Take, for example, a small ISP building an online catalog. In a matter of months, that ISP could go from taking 100 to 100,000 hits a day. If the ISP initially developed its online catalog on an entry-level UNIX-based Silicon Graphics server using an Oracle database, the migration to a faster SGI could be made in a matter of hours. However, if the ISP chose to make a smaller initial investment by developing their catalog on an Intel-based Linux or NT server, hacking together their own database, scalability of the software and hardware architecture becomes a serious issue.