> What I need to know is:
> 1. what would the create table statment look like in Mysql.
DROP TABLE IF EXISTS pictures;
CREATE TABLE pictures (
id mediumint(4) NOT NULL auto_increment,
comment text NOT NULL,
width smallint(6) DEFAULT '0' NOT NULL,
height smallint(6) DEFAULT '0' NOT NULL,
format varchar(4) NOT NULL,
PRIMARY KEY (id),
KEY pid (pid)
);
You may add other colums as needed or create other tables with
foreign keys to this to connect the picture data to other data,
e.g. texts, classifieds, whatever.
> 2. Should I use a longblob based on my 100k .gif size?
You should provide for enough space in the field to hold your
data. The field definitions tell you what is provided. If you
deliver greater values than storage space, MySQL will truncate
your data. You will want to acoid this.
> 3. Is one column with the gifs enough. Or should I add a autoincremented
> primary key?
That is always a good idea, unless you use a foreign key which in
turn will most probably be an autoincremented key itself.
> 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?
I would create a separate table. No, rather I would not store
pictures in a table, as said.
> Werner Stuerenburg wrote:
>>
>> 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
--
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
