PHP Application Development Part Two - Storing Dynamic Data (
Page 2 of 4 )
Having established the basic rules for handling configuration, we should now evaluate or options for storing dynamic data in our application. Dynamic data consists of any information that is expected to either change often or be manageable through a Web interface, or both, as is typically the case. In a typical Web application, this would consist of things such as text for Web pages or items to appear in a menu. This could of course be extended to include any sort of data with which your particular application works.
There are only two options available for storing dynamic data: the filesystem itself or a database. Storing data in a database is by far the most common choice in recent years with the advent of easy to use databases like MySQL. While I use MySQL for nearly every project I build, there are still times where storing data in a file simply makes more sense. There are a few quick questions you can ask yourself if you aren’t sure which is appropriate for your situation.
- Will the application need to produce reports comprising aggregate pieces of data from the site?
- Will the application need to store meta data for persistent objects?
- Will the application need to maintain strong relationships between persistent objects?
If the answer to any of these questions is yes, then a database is probably the logical choice. Typical justifications for using a database include “this website needs a search tool” or “this website needs to store data in multiple languages.” Oddly enough, neither of these are reasons to use a database, and in the case of storing text in multiple languages a database can often complicate the situation. Web application searching can be achieved with free tools like htdig and multiple languages can be handled simply by good file system orgnization.
Databases really show their strength in producing aggregate data, storing metadata, and storing logical relationships. It is true that you could build reports from data stored in flat files – after all, that’s how it was done before databases were around – but why reinvent the wheel? SQL provides a consistent semantic method for producing reports; by all means, use it.
Maintaining metadata is also possible with flat files, either by maintaining a metadata file for each persistent object or by combining the metadata and the actual data into a single file using XML or some custom encoding scheme. Often the best solution is to use a combination of the file system and a database. Consider a system where users should be able to upload images. It is far more efficient to store images in the file system, but storing metadata in the database allows you to normalize your data and search image metadata without clunky text file processing. In the case of a system that stores text documents, it would make sense to store the metadata and the actual text in the database and avoid flat files altogether. This simplifies management, boosts maintainability, and simplifies feature changes such as adding support for versioning, authors, publishing state, and so forth.
Databases also shine when used to store relationships between persistent objects. SQL allows you to easily build a result set containing individual records for objects spanning multiple tables or even databases without writing a lot of XML parsing code, messy object serialization or even worse, the use of some proprietary encoding scheme. This task can be accomplished in the filesystem with either method, but neither one is robust or elegant. Portability and semantics are completely lost when this sort of information is stored in a serialized or proprietary format, and while XML does maintain the integrity of the data from a semantic standpoint, it fails to provide a simple interface for object retrieval – meaning that you must write a lot of code to properly repopulate and reconstruct objects from XML files.
The most common solution is to use a combination of the file system and a relational database, especially in cases where binary data storage is a necessity. Performance is only a small consideration in this situation, but more often than not storing information in a database will yield better performance than flat files, as the database already provides an optimized data retrieval layer. Again there is also a measure of personal preference involved, and some people may find working with flat files simpler than working with a database or vice versa. Ultimately, it is important that as a developer you use the best approach possible for the job and mold personal preference around what produces the best results.
/ 33 
