[AccessD] Unifying Data

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