09775ch04final
7/1/08
9:40 PM
Page 39
CHAPTER 4 ■ NAMING FILES AND DESIGNING THE DATABASE
Poorly Designed Databases Ambitious web applications will certainly call for complicated database design. All too often developers try to find a way to fit every piece of data into a field without building associations between tables. Or, rather than store a reference to a record in another table, some developers build scripts that write information into a text field. Worse yet, some developers write a static list in the HTML of the site and change the list manually depending on where the list appears in the application. Not only do these methods make updating the code of the application more cumbersome and less portable, they also don’t fit into the paradigm of Cake’s rapid development methodology. Poorly designed databases can adversely affect Cake’s rapid development qualities and turn up errors or dead ends that lead to time wasted on forcing you to accommodate a bad database.
Why Good Database Design Matters Much of Cake’s rapid development functionality comes from conventions that are tied to how the database is designed. Not only does a good database design matter for the scaffolding feature or the Cake console, but it is the very bread and butter of Cake’s data handling. The interactions between different kinds of data will affect the time it will require to use that data throughout the application. In theory, the database should separate data into categories that work off each other, rather than the MVC structure separating roles of operations into different areas. Cake relies on the process of database normalization for its naming conventions and model functions. Normalization is the technique of designing relational database tables in an effort to minimize duplication and safeguard the database against structural problems. By normalizing your database, you produce an effective schema that improves your Cake application and saves you from data anomalies that can cause data-handling errors. To contrast poor and good database design or, in other words, to explain why database normalization is so important, I’ll discuss a social networking application scenario. For sites that give users web pages of their own, a lot of data will need to be stored. A poor database would have a record for each user’s profile and a field for each item in the profile: user’s name, e-mail address, home page address, favorite book 1, favorite book 2, image, avatarsized image, slogan, description, friend 1, friend 2, and so on. When fetching the user’s profile in the URL, a bad database wouldn’t have any kind of unique ID, so the record would be pulled by the username. This scenario is problematic because the number of fields is static. The user cannot add more than two books or two friends unless the developer manually adds more fields. Also, the number of fields would get large quickly the more the developer adds functionality to the application. Back-end database maintenance would be frustrating with a high number of fields. Field names such as favorite_book_1 are clumsy and make it more difficult to organize the code when processing data. Also, without a unique identifier to differentiate the profile records, the possibility exists that the username could get duplicated and thus break the queries that would seek to fetch a user’s profile. In theory, without some unique identifier for a record, that record could potentially get forever lost in the database and would not be retrievable.
39