Generally, it is not advised to add pictures to tables. See
http://www.bitbybit.dk/mysqlfaq/faq.html#storing_images
We had this question here some days ago, so it may ge a good idea
to discuss at length possible problems why people won't like this
approach of storing pics as files.
WARNING: this is _not_ MySQL specific. You may want to stop
reading here.
2nd WARNING: I will also show what can be done with all that
information to arrive at some kind of content management
wizardry. After all, people do use MySQL to do something with it,
and many seem to manage pictures. So here it goes.
If you let people upload images with php (which is built in and
really easy) you will receive the images in, say some sort of tmp
dir. You will have to move them in your code to a separate
storage dir, as php will automatically delete the tmp files (see
manual).
Now php is part of httpd and that runs as nobody, so it cannot
write to that storage dir unless you open that dir to nobody.
This will be ok as you use this dir only for the purpose of
storing those third party images. You may protect it in addition
with .htaccess or move it out of the normal dir tree if you are a
little paranoid.
Now you can store the images as files with no problem and only
note the filename and type or such (for example comments of the
user to the picture) in the database. When you upload, you move
the file, so this is a good point to record the file in your
table. Once you are at it, you can retrieve the dimensions of
that image with php function getImageSize and store them in your
table together with the type as well. So now you know everything
about this file you need for inclusion in your html code.
Hence you write yourself a function, say getImgCode, which
produces the html tags from this info, so you can insert the
whole stuff into your code without any further thought like
...
<?php getImgCode(firstNameOfMyPicture) ?>
...
You may even go a step further if you are in at content
production. Let's assume the user uploads any text and pictures.
The user is instructed to embed their pics with special syntax
like
... stuff stuff stuff *MyImageFirstName* stuff stuff stuff ...
You later insert the image with
$content = preg_replace("/\*(\w+)\*/e", "getImgCode($1)", $content);
This example is taken from http://php.net/manual/en/ref.pcre.php
(I developed a content management system along these lines on my
own, but this is just stunning - an incentive to learn the art of
regular expressions).
Sie schrieben am Donnerstag, 19. Juli 2001, 19:42:08:
> Hi, I'm new to blobs.
> I want to create a seperate table that will hold blob's or pictures.
> Each picture will be a .gif and will not exceed 100k in size.
> each image will be called, ord.gif, bar.gif, cmi,gif, lax.gif, jfk.gif,
> ord.gif, etc.
> The questions I had were
> 1. what would the create table statment look like.
> 2. Should I use a longblob based on my 100k .gif size?
> 3. Is one column with the gifs enough. Or should I add a autoincremented
> primary key?
> 4. Is it better to have a seperate table for this or, is it better to
> update my existing table, and add a blob column. Does it matter in terms
> of speed of queries?
> Queries will be done via php.
> Thanks!
> Pete
--
Herzlich
Werner Stuerenburg
_________________________________________________
ISIS Verlag, Teut 3, D-32683 Barntrup-Alverdissen
Tel 0(049) 5224-997 407 · Fax 0(049) 5224-997 409
http://pferdezeitung.de
---------------------------------------------------------------------
Before posting, please check:
http://www.mysql.com/manual.php (the manual)
http://lists.mysql.com/ (the list archive)
To request this thread, e-mail <[EMAIL PROTECTED]>
To unsubscribe, e-mail <[EMAIL PROTECTED]>
Trouble unsubscribing? Try: http://lists.mysql.com/php/unsubscribe.php
