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


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