2 replies to this topic

[BASHERS33]

I have a table with about 150 fields. Depending on the type of procedure you're doing it may use every field or it may have 100+ not even used.

Currently I just have a lot of fields default as NULL because it's convenient having all data in onee table. I wonder if this is acceptable or if I should end up using multiple tables (I would have to use probably 7-10 tables instead of 1 though!) and only have the fields which are definitely going to be used for those 7-10 procedure types.

Basically it's sports teams in contests. I know other ways to do it with maybe only 1 extra table too, but it would be mighty annoying to display what's needed to be displayed as you'd have to have several queries instead of one, for example. Also I hate to change it so majorly since it will take a while to test again.

I guess I'll think about it, but just seeing what anyone says. There's no great way to do it really. But this table will likely rarely be used anyway so I figured having a lot of hardcoded field names such as team1, team2, team3, etc... would be an ok way to do it in this situation rather than putting the teams and winners in other tables, but we shall see as I think mroe about it.

[WingedPanther]

It really depends on the details. I've seen it done both ways. Usually, if there is a one-one relationship between data in two tables, I consider making them one table.

[Orjan]

There is a possibility to do this other ways too. Everything depends on what you need to store.
Instead of many many columns in a table, you could actually use one table with id, field, data; where you add all data to the id as one row each. that way, you don't use more than needed, but on the other hand you might need to use loads of rows in this table...

I wrote some about this in a tutorial:
http://forum.codecal...parameters.html
it's named configuration parameters, but it can actually be of any sort of information... you can see a post's data as the posts config parameters etc...