One big table or several small ones

#1

I'm in the process of converting a VFP 7.0 app to Sql Server back end.
Right now the app has 5 separate tables, one page of each on a
different page in a pageframe. There are maybe 100 fields all
together, one being a memo field.

I am debating combining the whole thing into one large table. Makes
programming, formatting, etc WAY easier and keeps data integrity
cleanup easier also since there are no more orphan child records
floating about, etc.

Does anyone see any negatives on doing this?

Thanks.

Monica

#2

monica (AT) datashark (DOT) net (Monica J. Braverman) wrote in
news:d70cd025.0308061223.562ef93a (AT) posting (DOT) google.com:

Quote:

I'm in the process of converting a VFP 7.0 app to Sql Server back end.
Right now the app has 5 separate tables, one page of each on a
different page in a pageframe. There are maybe 100 fields all
together, one being a memo field.

I am debating combining the whole thing into one large table. Makes
programming, formatting, etc WAY easier and keeps data integrity
cleanup easier also since there are no more orphan child records
floating about, etc.

Does anyone see any negatives on doing this?

Thanks.

Monica

Well, it pretty much depends on the data design. A big honkin' table might
make programming and formatting "way easier" (although I can't see how) but
it will most likely blow your normalization and referential integrity all
to hell.

What kind of data?

#3

monica (AT) datashark (DOT) net (Monica J. Braverman) wrote in
news:d70cd025.0308201007.2374b25a (AT) posting (DOT) google.com:

Quote:

Well, it pretty much depends on the data design. A big honkin' table
might make programming and formatting "way easier" (although I can't
see how) but it will most likely blow your normalization and
referential integrity all to hell.

What kind of data?

Almost all character data. One memo field. Couple dates. And it is
absolutely related info. Like a rolodex with a lot of fields...couple
bells and whistle triggers, but data-wise, pretty straightforward
stuff. I can't come up with any negatives on slathering it across a
page frame.

Except, as I said before, you will blow your referential integrity all to
hell.

Check out http://builder.com.com/5100-6388-1045284.html for a good
explanation of why you should normalize your databases.

Some people have a hard time visualizing this and why it's good. I,
luckily or no, have sort of an instinct for when something's normalized.
If you want me to demonstrate how to normalize a table, send me a doc
file detailing the structure of your database and I'll show you how to
normalize it.

#4

monica (AT) datashark (DOT) net (Monica J. Braverman) wrote in
news:d70cd025.0308231402.5a73c5f7 (AT) posting (DOT) google.com:

Quote:

I know how to normalize tables. Not the issue. And since they are all
actually related fields and not parent/child relationships unless I
force them to be (all 1:1, not 1:many), referential integrity isn't a
problem. I was just curious if there is a downside of having that
many fields in a table.

I guess not... in FP 2.x versions there was a practical upper limit to the
number of attributes in a table, but I'm not sure if the VFP products made
that limit large enough to not worry about or not. I would suppose so.

Thread Tools
Show Printable Version Email this Page
Display Modes
Linear Mode Switch to Hybrid Mode Switch to Threaded Mode

One big table or several small ones

comp.databases.xbase.fox comp.databases.xbase.fox

One big table or several small ones - 08-06-2003 , 03:23 PM

Re: One big table or several small ones - 08-06-2003 , 09:12 PM

Re: One big table or several small ones - 08-20-2003 , 11:49 PM

Re: One big table or several small ones - 08-24-2003 , 09:54 PM