View Single Post
Old February 25th, 2010, 12:04 AM posted to microsoft.public.access.tablesdbdesign
Rick Brandt
external usenet poster
Posts: 4,354
Default I was told "Fields are expensive, records are cheap"

Dennis wrote:


I just have a self education question.

In response to one of my questions I stated that I added a lot of fields
lot was 30 fields) to my table. The initial implementation was so
successful, the user requested quite a few more enhancements resulting in
the addition of 30 additional fields.

One MVP who responded stated "Fields are expensive, records are cheap".
currious about his statement. I'm new to Access (less than a year) but I
have over 30 years experience with relational databased on multiple
platforms. I've always been taught the exact opposite - that "Fields are
cheap, records are expensive" since going to disk is so slow versus
accessing data in memory.

So you think rows are on the disk but fields are in RAM? Data has to be
retrieved from and written to disk regardless of this difference.

Is there something different about Access where the statement "Fields are
expense, records are cheap" is true. I'm using Access on local machine
where the front and backs end reside on the same machine as well as having
front ends on each client's machine tied into the back end which resides
a file server. We have a hardwired ethernet cat5 cable network.

This is not specific to Access. It is a "best practice" in all relational
databases to have a normalized data design. This generally results in
taller, narrower tables as opposed to wider, shallower tables.

When table modifications call for lots of new fields it often means that a
one-to-many relationship that ought to be set up in multiple tables is being
shoe-horned into a single table.