[AccessD] Unifying Data

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
>
>