I am looking at some consulting work for a company with 20+ data base
libraries, each one containing the same files (different data).

The DB setup is like if Walmart had a different library for each retail
store, although the file structure within each lib is the same.

For example there is a customer file for each lib, a vendor file for each
lib, etc.

And cust 123 in one lib is a different entity from cust 123 in the other
libs.

Has anyone had any experience with going into a rats nest like this and
consolidating the files into one?  For example, 20+ item master files into
one, 20+ vendor files into one, etc.

And of course it is not simply adding a company key to the front of the key
list.  For an item master file and a customer file (and most of the other
files), one would NOT want the company number in the file at all.

Any ideas how to approach?

Also, I have heard it said that if a DB is setup properly, then the program
development is fairly straightforward.

The converse must also be true, correct?  If a DB is a mess, then the
programming must be complex and extraordinarly difficult (and costly),
correct?

Any metaphors or examples to promote DB simplification and consolidation to
mgmt?

TIA


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.