Are there any operational reasons not to have tables with lots of columns - say 20 or 30 columns?

I am doing an estate agents (real estate) site. Am wondering if I can get away with one big table for all details of each house, or should I break it up? Why?


Many thanks for any thoughts

Edited by - nomadicweb on 12 May 2003 14:30:50

The basic premise for whether or not to use related tables or one singular table is if you will require to duplicate the entry of data.

If you do not, then use a single table.

there is nothing wrong with doing so.

Regards
Vince

Visit my home: www.chez-vince.com

VBScript | ASP | HTML | SQL | Oracle | Hosting

Thanks a lot.

Having one big table won't slow down the time taken to retreive records?

I now realise it could amount to some 70 columns. With Dreamwaever this doesn't seem too daunting as it is easy enough to scroll through and select relevant columns for each recordset.

Eg, I intend to provide scope for 15 rooms, each with room name, room size and room description - this makes 45 columns in itself. As there will not normally be as many as 15 rooms to describe, is this a problem in terms of redundant space, slow performance etc.?

Is it more or less difficult to make changes in the future with fewer tables?

many thanks for any thoughts

it seems like your project requires differing numbers of rooms attached to each house (?)

if so, why don't you create "rooms" in a different table, and link them to the "houses" via a common ID (e.g. house_id)

this will ensure you never have any leftover unnecessary fields in your main "house" table.

the room table can have the descriptive info about the room, a unique id and a referntial id to the house it belongs to.

hope it helps!


------------------------
Julio

PHP | MySQL | DWMX

ICQ: 19735247
MSN:

Thanks a lot poolio - good thing is I already came to that solution & have implemented it & it works nicely.

Your suggestion means I can feel I did the right thing!

Good little beginner's learning curve for me.

Cheers