Skip to Content
Last modified by Pascal Robert on 2011/02/22 10:35
From version 6.1
edited by Pascal Robert
on 2007/09/03 15:16
Change comment: There is no comment for this version
To version 7.1
edited by Pascal Robert
on 2011/02/22 10:35
Change comment: There is no comment for this version

Summary

Details

Page properties
Title
... ... @@ -1,1 +1,1 @@
1 -Web Applications-Development-Database vs Filesystem
1 +Development-Database vs Filesystem
Content
... ... @@ -6,8 +6,10 @@
6 6  
7 7  == Joe Moreno ==
8 8  
9 -Keep in mind that the purpose of a database is to store data to be search and retrieved.<BR>It would be a rare case when you'd actually send a query to a database that consisted of an image blob (i.e. search for an image that matches certain binary data). More than likely, you'd perform a search for an image based on its meta-data like date, time, image name, or file system path. A good solution is to store the path to the medium and then simply build the reference URL for the client's browser to reference or have the application retrieve the medium from the file system and serve it up through the WebObjects adaptor. In the former case you can keep the media under the Web server (say image thumbnails) and, in the latter case, you can keep full size images anywhere else on the server's file system and server them up based on a user's profile (i.e. did they successfully check out?, etc).
9 +Keep in mind that the purpose of a database is to store data to be search and retrieved.
10 10  
11 +It would be a rare case when you'd actually send a query to a database that consisted of an image blob (i.e. search for an image that matches certain binary data). More than likely, you'd perform a search for an image based on its meta-data like date, time, image name, or file system path. A good solution is to store the path to the medium and then simply build the reference URL for the client's browser to reference or have the application retrieve the medium from the file system and serve it up through the WebObjects adaptor. In the former case you can keep the media under the Web server (say image thumbnails) and, in the latter case, you can keep full size images anywhere else on the server's file system and server them up based on a user's profile (i.e. did they successfully check out?, etc).
12 +
11 11  == Michael Engelhart ==
12 12  
13 13  Storing images in the database is generally a bad idea in my opinion. There's much more overhead in retrieving image data from a database then there is in just letting Apache serve up the image. Apache has been highly optimized just for this purpose. Databases generally have not.
... ... @@ -26,7 +26,7 @@
26 26  Say I have a Product entity and want to upload and store product photos: I would create two entities Product and ProductPhoto. I would then relate them with either a toOne or toMany relationship depending on whether I need one or many ProductPhoto objects for each Product object.
27 27  
28 28  With this design pattern fetching Product data doesn't directly load the images. Instead EOF will create faults representing the images.
29 -The image data isn't fetched until the fault is fired by accessing the ProductPhoto fault object. So If you fetch 500 Products and batch them into groups of 10 with the WODisplayGroupProgrammingWebObjects-Web Applications-Development-WODisplayGroup then your first page would fetch only the first 10 images not the 500 (and only if there is a WOElement? or method that accesses the image data).
31 +The image data isn't fetched until the fault is fired by accessing the ProductPhoto fault object. So If you fetch 500 Products and batch them into groups of 10 with the WODisplayGroupWO:Programming~_~_WebObjects-Web Applications-Development-WODisplayGroup then your first page would fetch only the first 10 images not the 500 (and only if there is a WOElement? or method that accesses the image data).
30 30  
31 31  This pattern also greatly simplify uploading and storing the images because you can bind the NSData used to upload the image to your ProductPhoto's imageData BLOB.
32 32  
... ... @@ -193,9 +193,9 @@
193 193  
194 194  Images are normally served statically from the filesystem... because you are now serving them as dynamic content, the following performance hits occur:
195 195  
196 -* no client side caching [[ouch]] five copies of a single image on a page yields five seperate hits on WO.
198 +* no client side caching [[WO:ouch]] five copies of a single image on a page yields five seperate hits on WO.
197 197  * image requests must be serialized- not only do IMAGE hits have to be serialized, but all other hits on the WOF app will have to wait for any pending image hits to be handled. In terms of Netscape's REALLY SLOW table layout algorithm that requires the size of all images to be known, this means that the user WON'T see the contents of the table until ALL image hits have returned at least the size of the image.... since hits are serialized, that means that all but the last image must be entirely handled.
198 -* performance difference between a static hit vs. a fully dynamic hit is tremendous [[in favor of static]]. Think about it... a static hit basically means the web server opens a file, reads/writes the contents to a socket, closes... dynamic hits require IPC, a database round trip [[maybe]], a bunch of memory munging, a pass through request/response, etc.etc.etc...
200 +* performance difference between a static hit vs. a fully dynamic hit is tremendous [[WO:in favor of static]]. Think about it... a static hit basically means the web server opens a file, reads/writes the contents to a socket, closes... dynamic hits require IPC, a database round trip [[WO:maybe]], a bunch of memory munging, a pass through request/response, etc.etc.etc...
199 199  * no server side caching; every instance of your app will end up with a copy of every image served in its memory. As well, the IPC between database and WO app server will have to pass all that data back and forth, as well.
200 200  * most databases are not designed to handle BLOBs well.... regardless
201 201