OT: Database Design

  • Thread starter Thread starter slonocode
  • Start date Start date
S

slonocode

I am trying to make sure I'm using best practice for an Access table.
If I have a table that has 100 discrete colums. Is it best to just keep
the table with so many columns or to split it into a few other tables.

The 100 columns are indeed discrete so splitting them isn't going to
reduce any duplication of data.
 
IMHO - there's probably some grouping that you can do in there somewhere but
even if there isn't, working with 100 columns is a total pain in the butt if
for no other reason than UI manipulation.

But lets say that you do in fact need all 100 in one table - but most of the
time you only need 10 of those fields of some number < 100. In all
likelihood it's going to be a lot easier to work with the critical pieces
and only grab the other ones when they are needed.

I definitely have seen plenty of 50+ column tables in my life (way too many)
but i don't think I've ever seen one that should have been ;-)
 
I am trying to make sure I'm using best practice for an Access table.
If I have a table that has 100 discrete colums. Is it best to just keep
the table with so many columns or to split it into a few other tables.

The 100 columns are indeed discrete so splitting them isn't going to
reduce any duplication of data.
Click to expand...

If those 100 columns are really truly not dependant on one another,
e.g. don't violate any of the basic rules of Third Normal Form, then
there's usually no point in splitting them up. You gotta store those
100 attributes somewhere, one way or another.....

Marc
================================================================
Marc Scheuner May The Source Be With You!
Bern, Switzerland m.scheuner(at)inova.ch
 
I've never seen a table with 100 columns that wasn't due to poor or
non-existent normalization. It sounds like you have a disaster in the
making. It isn't that you need to "split" the columns or the tables, it's
that you need to work your way through the normalization process, which will
in turn show you how to structure the tables and their relationships. Once
you are finished, you will likely have many tables and many fewer fields per
table. If you don't have a good book on database design, buy one.
 
Slonocode,

For me it is in this important if you have more programs that access your
database, by instance access itself, when that is as that you have almost no
possibilities, because than you have to recreate all those orther use of the
database as well.

When not and it is really as I understand that you write, it should in my
opinion even be possible to bring them back to one column in your database
by serializing/deserializing. This by creating an object with those 100
fields which has as wel the methods in it to serializing/deserializing and
even to compress and set them in a blob field. That makes datahandling very
easy in my opinion and makes it very fast.

However just my thought,

Cor
 
Back
Top