Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
Grading a Database
The reverse engineering log records details about primary keys, candidate keys, foreign keys, nulls, indexes, and the like. However, although these details are useful, the log alone does not convey the overall result of an assessment. I have found it helpful to quantify a database evaluation with a grade. The grade reflects the consistency of the database and the extent of design and modeling errors.
Table 3 quantifies the grading scale. "A" is the best grade, and "F" is the worst; "B," "C," and "D" denote intermediate quality. I normally assign grades only to vendor databases. In-house databases could also receive grades, but this might offend some developers. Furthermore, for an in-house database, the typical purpose is recovery of ideas and data—not assessment.
Table 3-Grading scale for databases. A grade reflects the consistency of the database and the extent of design and modeling errors.
|
Grade |
Explanation |
Examples of Flaws |
|
A |
Clean |
No major flaws. Uniform and reasonable style. |
|
B |
Structural flaws, but they do not affect the application |
Inconsistent data types. Null constraints, candidate keys, and enumerations are not defined. Cryptic column names. |
|
C |
Major flaws that affect the application (bugs, slow performance, lack of extensibility) |
Inconsistent identity. Haphazard indexing. Foreign keys have mismatched data types. |
|
D |
Severe flaws that compromise the application |
Primary keys are not readily apparent. Much unnecessary redundant data. |
|
F |
Appalling (the application does not run properly or runs only because of brute-force programming) |
Deep conceptual errors in underlying model, gross design errors, or both. |
There are several possible responses to a poor grade: Choose the vendor anyway and make the best of it, choose another vendor, forego the application, or build the software yourself.