Multi-Tier

Plain Files Model

The idea behind this model is quite simple: you can use binary or text files to store data. The model consists of textual descriptions of the data structure and names to be used for the data files. There are some applications where this type of a data model would be highly useful. For example, massive search engines using indices or hashing with plain files run much faster and have easier maintenance than gigantic data stores.

This model can use a very wide range of file structures, from plain sequential files to b-trees, b* trees, b+ trees, hash tables, binomial heaps, union-find structures, and many others.

Let's consider building a web-based poll application. Here we have different polls with a number of options each, we have votes and might even have comments about polls. We could design a data model based on plain files like this:

    Polls file:
    Binary file, fixed length registers.
    Pollname: 40 bytes.
    Question: 250 bytes.

    Options file:
    Binary file, fixed length registers.
    Pollname: 40 bytes.
    Option: 80 bytes.
    Votes: 4 bytes.

    Comments file:
    Binary file, variable length registers.
    Structure: name length (1 byte) + name + comment length (2 bytes) + comment

    Current poll:
    Binary file, fixed length registers.
    Pollname: 40 bytes.

If we want to find which poll is the current poll, we can open the Current poll file, read 40 bytes, and get the pollname. We can then get the question for the poll by sequentially searching the pollname in the Poll file.

The same sequential search can be adopted to retrieve all the options. Voting only implies adding one to a selected option. Comments can be added by appending data to the comments file. However, deleting data is a difficult task. First, the data has to be deleted by marking a poll or an option with blanks in its pollname, and then building a packing process that will recreate the file by physically eliminating the logically deleted records. For more on advanced file structures see File Structures and Object Oriented Approaches in C++ from Addison-Wesley.

A plain files based data model is really useful when dealing with large amounts of data or when very specific searches must be done over a big volume of information and the queries can't really be adapted to SQL or XML related common queries. For example, search engines such as Google (http://www.google.com/) use a data model based on plain files to maintain the repository of information that is collected from the Web. The extra time needed to design, code, and maintain the programs that manage this information is compensated with superb performance that is really specific to the application.

Using a plain file based data model in PHP is easy since PHP has plenty of file manipulation functions such as flock(), fwrite(), fgets(), fputs(), fopen(), fclose(), fseek(), ftell(), unlink(), file_exists(), filesize(), and so on. These have been explained in Chapter 9.

Relational Database Model

This is the most common approach for web applications today. SQL statements are used to insert, delete, and update the data. The model is defined by an entity relationship diagram (ERD), where you indicate the entities used and the relationship between them. Then you can convert the ERD into a table structure and use this structure to establish table relationships. Let's see how we can model our poll application using a relational database:

    Polls table:
    pollid integer(4)
    pollname varchar(40)
    question varchar(200)

    Options table:
    pollid integer(4)
    option varchar(80)
    votes integer(4)

    Comments table:
    pollid integer(4)
    comment text

This structure is similar to the plain file model except that tables replace files. We don't have to bother about the internal structure of tables since this is what a Database Management System (DBMS) is for. We don't have to update or delete each entity, since we do that with SQL statements.

DBMS gives these common advantages:

• Higher integrity of data (not guaranteed with files)

• Higher consistency of data using multiple access

• Higher security

• Common query language

• Different views using same structures for multiple uses

• Independence of file structures

• No redundancy of information

• Relational mapping with OO

• Less hard drive space from loss-less joins

And these disadvantages:

• DBMSs are slower than files

• DBMSs require additional software

• Commercial DBMSs may be expensive

PHP is great for database programming. It has support for most of the DBMSs available today, such as Oracle, MySQL, PostgreSQL, Sybase, and DB2 (see Chapters 17-19 for more details). It has an established strategy to build or use a database abstraction class that can handle all the regular database operations. You can easily change the database without greatly changing the code written for a particular platform.

Building a true data layer for the application will result in no code changes to the application logic and the presentation layer (increasing code maintainability). However, abstraction is the best way to go to be completely scalable in terms of data storage.

XML Model

XML (Extended Markup Language), a recognized standard from the W3C (World Wide Web Consortium), is an excellent data modeling language. XML stored data is modeled by a set of DTDs or schemas that define the structure of XML documents in an industry or task-based way.

Today there are hundreds of applications and systems built using XML, both for interchanging and storing data. Since XML is a great standard for converting data from one format to another, it is fast becoming a cornerstone for application interaction. Even if applications do not have to interact with other systems, the use of XML can standardize internal structures, simplifying the development process.

Let's consider this single XML file for the polls application:

    <pollsapp>

      <poll>
        <question>Which is your favorite color?</question>

        <option>
          <name>blue</name>
          <votes>6</votes>
        </option>

        <option>
          <name>green</name>
          <votes>7</votes>
        </option>

        <comment>I really like blue</comment>
      <poll>
    </pollsapp>

As you can see here, the poll, option, and votes elements can all be stored in a single XML file.

Let's assume we did not consider that a user might want to add comments to polls. To include the comments in the relational model, we would have to create a table for the comments. In XML we just add comment elements to the XML file.

The really big advantages of XML over a relational model are the following:

• SQL has a proprietary model for metadata while XML uses an open standard.

• SQL is more or less a standard, but the way in which the data is internally stored is proprietary to each DBMS.

• You cannot take a table and understand content without the DBMS interpretation and reporting facilities.

• XML is designed for data interchange while the relational model has to bolt on transform tools.

• You cannot send a proprietary SQL table in open code form. With XML, you can send simple XML files. Any transformation problems are also addressed by the open standard of XSLT.

Finally, to implement an XML-based data model in PHP you must first define how, where, and why to store the data stream. You could use plain files somewhere in the file system or you could use an XML repository solution, like Ozone or dbXML (http://www.dbxml.org/).

Chapter 21 has more in-depth coverage of PHP's XML APIs. There we cover reading, writing, and transforming.

Hybrid Model

The hybrid data model combines two or more different data modeling strategies. For example, you can have a relational model and a set of XML DTDs and files co-existing in the same application.

Hybrid models add complexity to the content layer since there will be more than one interface to store and retrieve data. Although hybrid models demand high levels of design skill at the planning stage, they are the most flexible, scalable, and useful in today's e-business world.