Question : Working with Legacy Systems and Users (Database Design)

I'm working on an Access Database that has been in place for almost 10 years.

We have a little more than 5000 inventory records stored in a single table. These records include pumps, engines, air compressors, gas compressors, clutches, and a variety of minor miscellaneous pieces. The only thing not included is small items such as parts.

Each entry has an EquipType assigned to it. The person who originally designed this database didn't know very much about good design. They chose to assign a single letter or two letter EquipType to each item. For example:

P=Pump, Single Acting
PD=Pump, Double-Acting
PT=Pump, Centrifugal

ED=Engine, Diesel
EG=Engine, Gas
EX=Exchangers, Radiators & Coolers
EM=Electric Motors, etc.

CA=Compressors, Air
CG=Compressors, Gas
CL=Clutches

There are more but I have enough here now to present the problem. The users here have gotten accustomed to using this system. They know what each single letter or two letter EquipType means so we don't even use combos or lookups in the database (new users are forced to learn this system). This same data is transferred to our website where we display our inventory items. Each different equipment type (such as engines) has certain fields that I show to the user. I show different fields for each equipment group. However, our current system is faulty. Not all "P" items are Pumps and not all E items are Engines. Not all C items are Compressors. I've worked around this but it has created some additional coding and headache for me.

Here's my questions:
1) How do you change the mindset or culture within a company to allow for more efficiency and more correct database design? Is it always feasible to believe that you can change it? When do you just accept it and work around their mindset with extra fields and/or coding?

2) Is it smart to use short codes that carry lots of meaning or better to put that meaning in separate fields? For example, I could change it so that a Pump, Reciprocating, Single-Acting, Triplex (3 cylinders) becomes a PRS3. On the other hand I could create a field to hold the the top-level classification of Pump, a subclassification field to store "Reciprocating", another to hold "Single-Acting", and yet another to hold the quantity of cylinders (which would tell me if the pump is simplex, duplex, triplex or quintuplex). Each of these separate fields could carry single letter designations which has nothing to do with my question, really. Is it better to break out this information into separate fields or store it all in a single "code" field? In this case, either way requires a change and I'm getting a lot of resistance to changing something that "has worked for the last 10 years".

Answer : Working with Legacy Systems and Users (Database Design)

From a DB design standpoint you are correct.  Having all this information encoded in some cryptic 3-digit field is a bad design.  A better design would be to have a XREF table with all these codes in them.  Then in that XRef table you could add your 'cylinders', 'type' (pump, engine, etc - this could actually be another XRef table) etc.

Practically however, making a design change just for the sake of change, even to clean up a database design, is probably going to fail.  You will just tick off your users.  Unless your users will get some kind of measurable (and significant) benefit out of a design change, making them change the way they do things will generally fail.

As an alternative you could make the design change behind the scenes but let the users keep working the way they work now, so they don't even notice the change.  This will be harder to do, but will give you the best of both worlds.