| only for RuBoard - do not distribute or recompile | |
First, we need to think about how we will get content into the system, and how we will store and edit that content.
We need to decide on a way that stories and design components will be submitted. Three possible methods can be used.
The writers and designers could be given FTP access to areas on the Web server, and they could then upload files from their local machine to the server. There would need to be a rigid naming standard for the uploaded files (to identify which pictures belonged to which stories) or a Web-based system to deal with this separately from the FTP upload.
Using FTP also creates issues with permissions in this situation. Because of the flexibility required by this example, we will not be using FTP to allow users to upload files.
As we discussed in Chapter 16, "Interacting with the File System and the Server," the HTTP protocol provides a method for files to be uploaded via the Web browser. PHP is able to deal with this very easily.
The file upload method also gives us the opportunity to store text in a database rather than as a file. To do this, we would read in the temporary file and store its contents in the database, rather than copying it to another place in the file system. We will not use file upload for stories in this project.
We will discuss the superiority of a database over the file system later.
We can let users create and edit documents without using either FTP or file upload. Instead you can give the contributors a large text area input box onscreen in which their story content can be edited.
This method is simple, but often effective. The Web browser does not provide any text editing facilities beyond the cut-and-paste functionality of the operating system. However, when you just need to make a small change—for instance, to correct a spelling mistake—it's very fast to bring up the content and amend it.
Similar to file upload, the form data could either be written to a file or stored in a database.
An important decision to make at an early stage is how the content will be stored after it has been uploaded into the system.
Because we will be storing metadata alongside the story text, we have chosen to put the text parts of the content into the database. Although MySQL is capable of storing multimedia data, we choose to store uploaded images on the file system. As discussed in Part II, "Using MySQL," using BLOB data in your MySQL database can reduce performance.
We will just store the image filename in the database. Using the file system, the <IMG SRC> tag can reference the image file directly as usual.
When a large amount of data is being stored, it is important to optimize your data store. Just as the database would require proper indexes to be efficient, the file system will benefit greatly from a well thought out directory structure.
An example of this can be seen in Figure 26.1.
The file system in this case is split into directories representing the first character of each filename. 10,000 files would therefore be spread across 26 directories with around 400 files in each directory. This would be much quicker to access than 10,000 files all in one directory. It is worth pointing out that the filename used should be generated by the upload processing script to ensure that it is unique.
The example in Figure 26.1 assumes that all filenames will start with a lowercase letter.
The example stories we will be using are short one- or two-paragraph news stories with a single image, designed for people in a hurry. They are structured documents in as much as they contain a headline and one or two paragraphs of text with an image.
The more structured a document is, the more easily it can be split up for storage in a database. The advantage of this is that all the documents can be presented in a very consistent, structured manner.
Take our news story example. We will store the headline in a field separate from the story text, and by its nature the image is a separate component of the document.
With the headline as a separate item, we can define a standard typeface and style for that to be displayed in, and can easily separate it from the rest of the story to form our main headlines page.
Another approach for large documents would be to have a one-to-many relationship with the individual paragraphs; that is, to store each paragraph as a separate row in the database, each linked to a master document ID. That kind of dynamic document structure would allow you to present a contents page for each document and display each section independently, or display the whole document at once.
| only for RuBoard - do not distribute or recompile | |