|
|
Posted by Norman Peelman on 01/27/07 13:14
Geoff Berrow wrote:
> Message-ID: <b-ydnfwzS5NGISfYnZ2dnUVZ_qunnZ2d@comcast.com> from Jerry
> Stuckle contained the following:
>
>> I suggest you try it before you start telling me how bad it is. As I
>> said - I've done it for a number of sites. It works great.
>
> Let's say I'm interested enough to try it Jerry, have you got a little
> sample code I could play around with?
>
Geoff,
What would you like to see? I'll tell you my system (understand this
is a specialized sysytem):
1) I create dummy data for a set number of pictures upon account creation.
2) I pad all my images with zero bytes to a predetermined size (for me
it's 10k). This allows me to calculate the size of my expanding db at
anytime with great accurracy.
3) Prevents fragmentation when my users want to delete or replace an
existing image (as rows are not deleted and created after account
creation). I do only UPDATES (a DELETE just gets copied over with the
dummy data).
4) I pull my images out with "SELECT SUBSTRING(data,1,$size) FROM data
WHERE id = $id LIMIT 1"; $size being the original unpadded size.
5) I then create a GD image with imagecreatefromstring(), perform
anything I want to on the image, then send it out.
I think it's a good example, again highly specialized, but it works
great. Even excluding 1,2,3,4 once you create the image (5) your
possibilities are endless. I see so many people actually write the image
data back out to the filesystem just to read it back into the script for
processing. There is no need. It can probably be done with the magicwand
api as well but i've yet to try it.
I chose this way of doing things for my needs. I'm not looking for
an ultra-compact dataset. I'm looking for ultra-ease of managability.
Norm
Navigation:
[Reply to this message]
|