[development] table vs tables

[Glenn Wybo]

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 at gmail.com
> To: development at drupal.org; nevets at 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

_________________________________________________________________
Een dagje naar het strand? Neem je vrienden mee!
http://get.libe.com/mobile/messenger
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.drupal.org/pipermail/development/attachments/20070910/6326ab2f/attachment.htm