Sample Data would be
1 | CRYS | CRYSTAL STAIRS
2 | MAOF | MEXICAN AMERICAN FOUNDATION
3 | PATH | PATHWAYS
4 | CCRC | CHILD CARE RESOURCE CENTER
5 | CHSC | CHILDREN'S HOME SOCIETY OF CALIFORNIA
THE REMAINING "FKs" FROM SCHOOL ARE SIMILAR, as is other tables and their relationships. The design of the foreign keys were made using sql and the keyword "REFERENCES" and "FOREIGN KEY."
My questions are:
(1) Is the use of FK as a Constraint any different than using an INDEX and how?
(2) Should I Alter the Tables to include CASCADING Up/Down?
(3) Are the use of CHARs Ok for the Keys?
(4) Have I over/under-normalized any of the relationships?
(oddity) Sorry about the TYPO, the PK for table.participants is CHAR(10) as shown as a FK in table.enrollhist
(blindman) The instances when I use CHAR(1) is truly not scalable, but the chances of the keys needing 2+ chars are slim to none. But, in the optimum chance of meeting that slim probability, I would have to agree with you.
I also have an additional question regarding the schema I have for the enrollhist table. Does anyone see any flaws in its design.
The implementation I want is to have the enrollmode and effective date (forgot the column for effective date in the schema listed [effdate datetime]) stored whenever there is a change in the status of the participant. The previous database had each of the modes as a column of the participants table. This is a no-no in my book!