Config tables should have two fields
Databases should be easy to read and understand. However, with all the tables in Config, we're only allowed a single field for entry. A more proper db approach would be to allow two(2) fields. Field one(1) would be the 'short description'/'abbreviation' or 'code', while field two(2) would be the long description thus allowing to 'document' what field one(1) means.
For example, State (example only) - most everyone knows that "TX" stands for 'Texas', but is "CO" 'Colorado' or 'Connecticut.
For maybe a more practical example - Major.
- MATH = Mathematics, but what does MAED stand for (Mathematics Education...elementary ed majors).
- PHED...is this Physical Education or Physics Education
- What is "THCY"
While one could certainly keep a list (electronic or paper) on hand to refer to, it would be better for the db to be self-documenting, and the user could decide to display the 'code' or the 'description'.
As for the lengths of the fields, the 'code' field should be short - no more than 12 characters, probably only 8 while the 'description' field should be at minimum 25 but would prefer 50-80.
Think how much easier it would be to train new people or to even understand your own db when decisions made 5 years ago are long forgotten and everyone is trying to decipher what the heck that field means.
-
Guest
- Aug 27 2015
Related ideas
Specifically, this assists with integration/imports from other systems. Our registrar's office uses major codes that do not change, but the way they store the description is not always helpful for us.
As an example, the registrar has a different major code for each concentration in a major, so the major description would reference the general program such as "Engineering" for the 10+ different codes. Their system would then reference an additional field that contains the concentrations (ex: "Electrical", "Mechanical", "Geological", "Mechanical/Geological", etc.). There is no easy way to translate what they mean to RE without using the codes themselves which are too cumbersome for most of our users as mentioned above and the fields for many of these are too long to simply concatenate together to create a unique description with those fields. Additionally, those descriptions have changed in the past specifically as they've implemented online registration & graduation check systems to make their wording "friendlier" to students. That is an ongoing process, so I would not want to count on editable fields remaining the same over time.
Having the 2 fields for all code tables is essential for the future as integrated systems are becoming the expectation of constituents regardless of the internal organizational structure of that particular organization and software solutions.
Oh, YES! I hate trying to delve into archives to figure out what in the world THCY stands for.