How do you store text and images...

...in a database?

[knighty]

I am doing a database of products and am storing the product information in a field called text.

this information is basically a HTML file pasted into the field i.e. tables, images etc.

would i be better off storing it in a seperate TXT or HTML file?

This would solve the problem of differing layouts and keep the table leaner but would it make it any faster and how would people edit the information> (i was hoping to do it all through a textarea)

[Fischerlaender]

The standard (and IMHO better) way is to just store the product information (price, description, ..) in a database and use a template system. So you just have to edit one template and not every single HTML page. And if someone has to change the product information, he is not confronted with HTML; he just has to edit a single value.

[knighty]

Well thats what I set out to do but...

Some pages have a lot of product information and need 3 or 4 tables as well as text/images - how do you edit 3 or 4 tables and how would you store it?

At the moment I just have a load of HTML tags

[jpjones]

how do you edit 3 or 4 tables and how would you store it

Why not create a secondary table wihch holds the values to go into these tables, with a related field which refers to the main table? Then on output your template script should look in this table to see if there are any records. If so - build the tables in the output!

JP

[knighty]

I did consider that - seems a bit complicated though.

I'd have to have each cell value stored in a field and hown many rows,columns etc. plus how would you make it editable? then id have to set up other entries for each table.

some of these tables have many rows and some columns merge across others...my heads spinning already ;)

I'd love to hear how other people hanlde multiple comlplex pages of HTML

[lorax]

My approach is to keep everything but raw data OUT of the db. I use template pages - different ones for different purposes (news page, products page, calendar of events, etc...).

I focus on normalizing my database so that the tables are as efficient as possible for their intended purpose. IE - if they will be used primarily for reads (such as a products table) then I will use several indexes on a variety of fields dependent upon what I allow the customer to search on. If the table will constantly be added to often (like a customer or purchases table) then I will reduce/eliminate the indexes and focus on speed.

The long and short of it is that if you find yourself repeating information/data entries then you need to rethink how you've laid out the tables. There are times when it will be necessary but these should be few and far between.