[AccessD] Unifying Data

Why store it twice.  Just dim a DB or Connection to the mdb where the data 
resides and update in one place only.  Or, update one back end location only 
and take a dump of the data for read only purpose for ancilliary apps.

Divergent data is a potential nightmare and there is no need to risk it, 
never mind doubling up on storage.  With Access, you can even use the IN 
syntax in combo rowsource to specify an mdb file if you don't want to use a 
callback with a remote connection.  Or you could just link the data so you 
can use bound forms, combos lists and all.

Data need not reside 'in' the application and the beauty of Access is that a 
single data store can serve multiple applications, even if the data happens 
to be 'in' one of the applications.  Store the data in the application that 
has the most stringent relationship rules so as to minimize the number of 
inter database relationship integrity rules needed to be enforced in code.  
Depending on the structure of the data, this matter may prove determinative 
of the matters.

Hen


>From: "Susan Harkins" <harkins at iglou.com>
>Reply-To: accessd at databaseadvisors.com
>To: <accessd at databaseadvisors.com>
>Subject: Re: [AccessD] Unifying Data
>Date: Thu, 20 Feb 2003 17:13:57 -0500
>
>It depends on the data's purpose Charles -- if you'll looking at a little
>data, that takes just a little or almost no time to update and it works, 
>why
>invest the time in redoing it? You need a better reason than "because."
>
>Why would you spend hours of development time creating a new back end and
>interface for maintaining data that almost never gets changed and when it
>does, can be easily and quickly verified to make sure it's correct?
>
>I'm not saying a database full of ever-changing data should be handled this
>way -- but Martin didn't specify. He just asked if the data existed, would
>I -- and no, not necessarily is my answer and still is.
>
>Susan H.
>
>
> > Arthur,
> >
> > If you take it to the extreme, then you do get one db per entity.
> > However, what I was trying to get across was not to store the same data
> > in two dbs when it can be stored in one place and linked to the other
> > places that need it.  Just as it is bad design to store the same data in
> > two different tables in one db, it also is bad design to store the same
> > data in two different dbs.
> >
> > Charles Wortz
> > Software Development Division
> > Texas Education Agency
> > 1701 N. Congress Ave
> > Austin, TX 78701-1494
> > 512-463-9493
> > CWortz at tea.state.tx.us
> > (SELECT * FROM users WHERE clue > 0)
> >
> >
> > -----Original Message-----
> > From: Arthur Fuller [mailto:artful at rogers.com]
> > Sent: Thursday 2003 Feb 20 15:15
> > To: accessd at databaseadvisors.com
> > Subject: RE: [AccessD] Unifying Data
> > Importance: Low
> >
> >
> > Really? If I read you correctly, this logically leads to one database
> > per entity. Customers over there, employees over there, products over
> > there. Not to say that you're wrong, it simply never occurred to me.
> > I've always gone in the opposite direction, toward one database that
> > encompasses one instance of customer, one of product, one of employee
> > &c., using DTS or some such tool to inhale the data. ?
> >
> > -----Original Message-----
> > From: accessd-admin at databaseadvisors.com
> > [mailto:accessd-admin at databaseadvisors.com] On Behalf Of Wortz, Charles
> > Sent: February 20, 2003 12:12 PM
> > To: accessd at databaseadvisors.com
> > Subject: RE: [AccessD] Unifying Data
> >
> > Susan,
> >
> > I respectively have to disagree with you.  Unless either App A or App B
> > is a personnel app, then they both should draw their employee data from
> > a database that holds the employee data.  If even small amounts of
> > employee data are stored in two different apps, they can get out of
> > sync, the old inconsistent data problem of poor database design.
> >
> > Charles Wortz
> >
> >
> > -----Original Message-----
> > From: Susan Harkins [mailto:harkins at iglou.com]
> > Sent: Thursday 2003 Feb 20 09:20
> > To: accessd at databaseadvisors.com
> > Subject: Re: [AccessD] Unifying Data
> >
> > Only if there are a lot of employees and a lot of updates -- wouldn't be
> > worth it.
> >
> > Susan H.
> >
> >
> > > Two apps
> > >
> > > App A Application B
> > >
> > > Both apps contain employee data.
> > >
> > > Rather than maintain two sets of the same data in both apps how would
> > > you handle it? Export the employee data and anyother common data (if
> > > possible) out to App C and manage that via a different interface?
> > >
> > > Comments
> > >
> > > Martin WP Reid
> > > Information Services
> > > Queens University Belfast
> > >
> > > Tel: (02890) 273750
> > _______________________________________________
> > AccessD mailing list
> > AccessD at databaseadvisors.com
> > http://databaseadvisors.com/mailman/listinfo/accessd
> > Website: http://www.databaseadvisors.com
> >
> >
>
>_______________________________________________
>AccessD mailing list
>AccessD at databaseadvisors.com
>http://databaseadvisors.com/mailman/listinfo/accessd
>Website: http://www.databaseadvisors.com


_________________________________________________________________
The new MSN 8: smart spam protection and 2 months FREE*  
http://join.msn.com/?page=features/junkmail