How would you design for all the other fields besides dates? Fields that have to do with the client, like:
Active (y/n)
Years of service (number)
assets ($)
preparer (text)
They have lots of data like this with all different data types. They use these fields sometimes as report filters, sometimes as report columns along with the dates as columns, and sometimes they just want a field like preparer on a report just to reference in the header (so you'd have client name and preparer in the header and the dates as the columns)
Thanks.
--- In MS_Access_Professionals@yahoogroups.com, John Viescas <JohnV@...> wrote:
>
> Elizabeth-
>
> Better to properly normalize the design. Putting a string of date fields in the
> Client table would violate first normal form (repeating groups).
>
> John Viescas, author
> Microsoft Office Access 2010 Inside Out
> Microsoft Office Access 2007 Inside Out
> Building Microsoft Access Applications
> Microsoft Office Access 2003 Inside Out
> SQL Queries for Mere Mortals
> http://www.viescas.com/
> (Paris, France)
>
> -----------------------------
>
> From: MS_Access_Professionals@yahoogroups.com
> [mailto:MS_Access_Professionals@yahoogroups.com] On Behalf Of glcass58
> Sent: Monday, April 30, 2012 9:14 PM
> To: MS_Access_Professionals@yahoogroups.com
> Subject: Re: [MS_AccessPros] table design
>
>
> Yes, my question is on the attributes. Is it better to have a narrow table of
> client_id and client name with one to one relationships by client_id to many
> subject-matter attribute tables? Or is it better to have one wide attribute
> table? thanks
>
> --- In MS_Access_Professionals@yahoogroups.com, John Viescas <JohnV@> wrote:
> >
> > Elizabeth-
> >
> > So the related table is Client? That should give you a 1-M relationship to
> this
> > table as long as you include ClientID. Each client will have multiple events
> > consisting of an EventID and the date the event occurred.
> >
> > John Viescas, author
> > Microsoft Office Access 2010 Inside Out
> > Microsoft Office Access 2007 Inside Out
> > Building Microsoft Access Applications
> > Microsoft Office Access 2003 Inside Out
> > SQL Queries for Mere Mortals
> > http://www.viescas.com/
> > (Paris, France)
> >
> > ---------------------------------
> >
> > From: MS_Access_Professionals@yahoogroups.com
> > [mailto:MS_Access_Professionals@yahoogroups.com] On Behalf Of glcass58
> > Sent: Monday, April 30, 2012 8:45 PM
> > To: MS_Access_Professionals@yahoogroups.com
> > Subject: Re: [MS_AccessPros] table design
> >
> >
> > The dates are when forms are sent to clients and received back from clients. I
> > was going to have them in one table
> > ID
> > Event_ID (key to the event description, i.e. Form "A" Sent Date)
> > Date
> >
> > The attributes are about the client. Do you need more info? Thanks for your
> > help.
> >
> > --- In MS_Access_Professionals@yahoogroups.com, John Viescas <JohnV@> wrote:
> > >
> > > Elizabeth-
> > >
> > > Need more info. What are these "dates" related to? Why aren't they in their
> > > related table(s)? One-one joins are a pain the patootie.
> > >
> > > John Viescas, author
> > > Microsoft Office Access 2010 Inside Out
> > > Microsoft Office Access 2007 Inside Out
> > > Building Microsoft Access Applications
> > > Microsoft Office Access 2003 Inside Out
> > > SQL Queries for Mere Mortals
> > > http://www.viescas.com/
> > > (Paris, France)
> > >
> > > -----------------------------
> > >
> > > From: MS_Access_Professionals@yahoogroups.com
> > > [mailto:MS_Access_Professionals@yahoogroups.com] On Behalf Of glcass58
> > > Sent: Monday, April 30, 2012 5:36 PM
> > > To: MS_Access_Professionals@yahoogroups.com
> > > Subject: [MS_AccessPros] table design
> > >
> > >
> > > Hi there-
> > >
> > > I have many, many attributes and a factless fact table (dates of events). My
> > > first thought is that I'd like to put the attributes in separate tables by
> > > subject matter and have one to one joins. But then I thought I better ask
> you
> > > all if you thought Access would run faster if the attributes were in one
> wide
> > > table.
> > >
> > > Thanks,
> > > Elizabeth
> > >
> >
>
Tidak ada komentar:
Posting Komentar