<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html>
<head>
<meta content="text/html;charset=ISO-8859-1" http-equiv="Content-Type">
</head>
<body bgcolor="#ffffff" text="#000000">
Hi Glenn,<br>
<br>
In the future, please create a new email instead of replying to a
threaded one. Your question ended up in the middle of a long discussion
about Drupal and GPL. Emails that are threaded are tagged so your email
client can tell which emails relate. When you replied, your email got
tagged making it appear being part of the GPL discussion. Creating a
new (untagged) email, your email will be considered to be a new thread
and will end up at the "root" level.<br>
<br>
Thank you,<br>
<br>
Jakob Persson<br>
<br>
<br>
Glenn Wybo wrote:
<blockquote cite="mid:BAY124-W55B914984B273AC85F3949A2C00@phx.gbl"
type="cite">
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>Ok, thanks,<br>
<br>
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. <br>
<br>
thanks for the advice,<br>
<br>
Glenn<br>
<br>
<br>
<br>
<br>
> Date: Fri, 7 Sep 2007 10:20:27 -0500<br>
> From: <a class="moz-txt-link-abbreviated" href="mailto:mark.m.fredrickson@gmail.com">mark.m.fredrickson@gmail.com</a><br>
> To: <a class="moz-txt-link-abbreviated" href="mailto:development@drupal.org">development@drupal.org</a>; <a class="moz-txt-link-abbreviated" href="mailto:nevets@mailbag.com">nevets@mailbag.com</a><br>
> Subject: Re: [development] table vs tables<br>
> <br>
> > The "obvious" way to break up the table would be to use 1000
a smaller<br>
> > tables, but too many tables can also cause a problem.<br>
> <br>
> You might also look at table partitioning:<br>
> <br>
> <a class="moz-txt-link-freetext" href="http://dev.mysql.com/doc/refman/5.1/en/partitioning-overview.html">http://dev.mysql.com/doc/refman/5.1/en/partitioning-overview.html</a><br>
>
<a class="moz-txt-link-freetext" href="http://www.postgresql.org/docs/8.1/interactive/ddl-partitioning.html">http://www.postgresql.org/docs/8.1/interactive/ddl-partitioning.html</a><br>
> <br>
> Basically, it splits one tall table into many, smaller chunks that<br>
> look and behave like a single table. So you don't have to change
your<br>
> queries but you could possibly get some performance benefits by not<br>
> having to scan or load as much of a table into memory.<br>
> <br>
> I'm not a DBA, so I don't know how this really ends up working in<br>
> practice, but that's the theory at least.<br>
> <br>
> -Mark<br>
<br>
<hr>Bekijk de beste Live Earth concerten op MSN <a
moz-do-not-send="true" href="http://liveearth.be.msn.com/"
target="_new">07/07/07 Live Earth</a></blockquote>
</body>
</html>