|
|
Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs
Page 2 of 3
In this case, as in most low-to-medium volume, publishing-based Websites, you can assume the following: most of the data access is reads, not writes; the data, though potentially large, is relatively unchanging; you won't need to do complicated searches, but if you do, you'll use a separate search engine. The advantages of using a mature RDBMS fade, while the advantage of using an object-oriented data model come to the fore.
Finally, it's entirely possible to provide a wrapper for your database that makes SQL queries and translates them into XML streams, so you could have it both ways. XML becomes a more robust, programmer-friendly frontend to a mature database for storing and searching. (Oracle's XSQL servlet is one example of this technique.)
Everybody loves photos! People love showing pictures of themselves, their friends, their pets, and their vacations. The Web
is the ultimate medium for self-indulgent shutterbugs -- they can annoy their relatives from thousands of miles away. While
a full-fledged photo album site would require a complicated object model, I'll focus on defining a single Picture object. (The source code for this application is available in Resources.) The object representing a picture needs fields representing its title, the date it was taken, an optional caption, and,
obviously, a pointer to the image source.
An image, in turn, needs a few fields of its own: the location of the source file (a GIF or JPEG) and the height and width
in pixels (to assist you in building <img> tags). Here there is one neat advantage to using the filesystem as your database: you can store the image files in the same
directory as the data files.
Finally, let's extend the picture record with an element defining a set of thumbnail images for use in the table of contents or elsewhere. Here I use the same concept of image I defined earlier.
The XML representation of a picture could look something like this:
<picture>
<title>Alex On The Beach</title>
<date>1999-08-08</date>
<caption>Trying in vain to get a tan</caption>
<image>
<src>alex-beach.jpg</src>
<width>340</width>
<height>200</height>
</image>
<thumbnails>
<image>
<src>alex-beach-sm.jpg</src>
<width>72</width>
<height>72</height>
</image>
<image>
<src>alex-beach-med.jpg</src>
<width>150</width>
<height>99</height>
</image>
</thumbnails>
</picture>
Note that by using XML, you put all the information about a single picture into a single file, rather than scattering it among
three or four separate tables. Let's call this a .pix file -- so your filesystem might look like this:
summer99/alex-beach.pix summer99/alex-beach.jpg summer99/alex-beach-sm.jpg summer99/alex-beach-med.jpg summer99/alex-snorkeling.pix etc.
There's more than one way to skin a cat, and there's more than one way to bring XML data on to your JSP page. Here is a list of some of those ways. (This list is not exhaustive; many other products and frameworks would serve equally well.)
java.util.List of name-value pairs
Note that these techniques could be applied equally well to an XML stream you receive from another source, such as a client or an application server.
XMLEntryListServer-side Java: Read the whole series -archived on JavaWorld