Having your web server serve the images as files off the filesystem disk is almost guaranteed to be faster than serving them out of BLOBs in a database. Don't put them in the database, unless you really need to, is a good general rule. A database with 500,000 records with a decent primary key will be plenty fast for everything else. ..chrisxj On 9/10/07, Glenn Wybo <glennwybo@hotmail.com> wrote:
Ok, thanks,
well, was considering if it would be necessary to use BLOB's to upload the images to a database between our server and the compunter of the client. The thing is that my boss wants to upload many images (corresponding with the company of the customer) to another database when the customer logs in on the website. This database will only be used for storing the images and the corresponding data. The only reason for this is to improve speed. When the customer selects a couple of images, it may only be a matter of milliseconds to select the images (and the data that corresponds with it) in the database and upload it to the screen of the user.
thanks for the advice,
Glenn
Date: Fri, 7 Sep 2007 10:20:27 -0500 From: mark.m.fredrickson@gmail.com To: development@drupal.org; nevets@mailbag.com Subject: Re: [development] table vs tables
The "obvious" way to break up the table would be to use 1000 a smaller tables, but too many tables can also cause a problem.
You might also look at table partitioning:
http://dev.mysql.com/doc/refman/5.1/en/partitioning-overview.html
http://www.postgresql.org/docs/8.1/interactive/ddl-partitioning.html
Basically, it splits one tall table into many, smaller chunks that look and behave like a single table. So you don't have to change your queries but you could possibly get some performance benefits by not having to scan or load as much of a table into memory.
I'm not a DBA, so I don't know how this really ends up working in practice, but that's the theory at least.
-Mark
________________________________ Bekijk de beste Live Earth concerten op MSN 07/07/07 Live Earth