Re: Denormalizing for form only


"Thomas Lake" <toml_12953@xxxxxxxxxxx> wrote in message
news:B84F3876-3A7E-4329-99E9-CA35FCA21AF6@xxxxxxxxxxxxxxxx


"Amy Blankenship" <Amy_nospam@xxxxxxxxxxxxxxxxxxxxxx> wrote in message
news:O0vzpdgsIHA.4492@xxxxxxxxxxxxxxxxxxxxxxx
Hi, all;

Many times I've answered questions like this in the queries and
tabledesign forum:

I have a table like this:

MyThing
==========
MyThingID
MyThingDesc
MyThingField1
MyThingField2
MyThingField3


Now, how do I query in such a way that Field1, Field2, Field3 are all
treated in essentially the same way? And of course what I tell them is
that they need a separate table, with MyThingField1, MyThingField2, and
MyThingField3 as separate records.

But there is a reason people keep asking questions like this, and it is
that Access does a much better job of making it easy to make data entry
forms with the structure above than with the "correct" structure. With
the "correct" structure, you have to use a Left Join on some other table
that will return you 3 records, and then you have to worry about a
frustrated join. You also may have to add extra code to make sure that
MyThingID gets into the MyNewThing table as a FK. And even then, your
users are dealing with a vertical structure when the horizontal one might
well be more user friendly.

Why limit yourself to Access input only? If users are more comfortable
with Excel-type input, let them use that. Then analyze the data in
Access.

The data needs to be in the database. Why is this concept so foreign?

The whole idea behind Microsoft Office is to be able to use a suite of
programs that interoperate. You can have the front end be an Excel
work*** while the back end is Access. I've also seen Word used to
create forms that created a data file for Excel or Access. Just as a
professional carpenter has many tools and many types of the same tool
to get a job done, so should we use all the tools we have!

Well, certainly I can write an import routine that can take a spread***
and split it out into the requisite records, but this thread is about trying
to get Access to allow input of data in the format that you're actually
supposed to use in Access. If you have to go outside Access to work with
data in a format that makes sense to users, then write a routine to fix it,
Access isn't really fit for the purpose it's advertised for. And that's
more money my client has to spend without a real understanding of why, or I
just have to eat.

I'm really tired of solving this problem over and over!


.

Loading