|
|
Posted by --CELKO-- on 12/01/06 19:06
This is a mess. I woudl start over and get it right.
1) Why do you use all uppercase letters? It is a screaming bitch to
read and we did this because we had no choice in the 1950's with
punch cards.
2) Why do you have no keys in any table? Most columns are NULL-able, a
sure sign that you have a rotten data model (if you have one at all).
.. In fact you have more NULLs than the entire database for a major
automobile company.
3) Why are you storing computable totals in a table? That is how we
did it with file systems; in SQL, we use a VIEW. Or we use a front-end
report application.
4) Why did you pick the unreadable alphabetic aliases? That is, why
does CC remind the reader that the base table is "D_Bi_Student"?
5) Why did you use a "_key" suffix? That tells us HOW an attribute
is use, not what the data element IS. Also, think about how stupid
"unique_key" is - are there any non-unique keys???
6) Is "curr_ind" actually a flag? We do not write with assembly
level bit flags in SQL. It is redundant in a properly designed schema.
The status is computed from the current state of the basic data.
7) Why did you use so many proprietary data types?
8) Why did you mix summary data and base data in the same table? Do
you know what 1NF and the definition of a table are?
9) Having both "session_dt" and "session_day" is a bit
redundant.
10) Why are you keeping captions in a table with the data? A caption
is part of a display and display is done in the front end, never in the
database.
11) Why are so many of your codes VARCHAR(n)? Most codes are fixed
length.
12) It looks like you need to split up your tables and normalize the
schema. Think about the basic entities with which you are working -
students, candidates, admissions personnel, etc. and then once those
are in tables, think about their relationships.
Navigation:
[Reply to this message]
|