Hi
I've posted a comprehensive free course on my site that will get you going with the principles of OOP along with good coding practice. Help yourself!
This is rule 2.3 in the design standard "Foreign keys always have exactly the same name as the related primary key". The rule works particularly well with rule 2-6 for the stated reasons.
I think I must stay focused in this thread but I would be obliged if you would advise (perhaps by private...
I think there's a danger of going off on a tangent here into naming conventions and that isn't what the thread is really about. My schema simply supports the assertion that whether one convention is more readable than the other isn't objectively debateable. I won't expand upon my naming...
You need to read my post again! Especially the line:
"I'll make my argument by considering the following schema (that meets my published design standards, a schema that didn't could well be more difficult to read)"
My design standard is holistic and the naming convention is, indeed, a major...
OK... I'll tell you (but I thought you'd have more fun discovering it yourself)!
The payroll_number and shift_type are both foreign keys in the EmployeeShift table. Together they make up the primary key of EmployeeShift. You need to go to table design for EmployeeShift, select BOTH FIELDS and...
Hi Kilfoil
Whether a schema is easier to understand is subjective. My opinion (as a professional educator) is that it is more difficult to understand a schema with meaningful primary keys ... but as that is subjective too it is arguable. I'll make my argument by considering the following...
Your present schema allows any number of shifts to be attached to an employee but I think you now want to model the idea of the same shift being attached to many employees. For example: Joe works 9-5 on monday and 12-5 on Tuesday. The same 9-5 shift is also worked by fred and bill on Monday...
I think you are agreeing that for every case there is a best approach. Quantifying the pros and cons of each approach will help others to quickly identify the best approach for a given set of circumstances. This is what I hope to achieve in this thread.
This issue we're discussing here is...
Hi Doc Man
I thought you'd appreciate a point-by-point examination of the issues you raise:
I think this is a re-statement of advantage 2 for meaningful keys?
A business consists of entities and the relationships between them along with attributes of the entities, of course. But the keys...
Hi again Doc Man
What I'm trying to establish in this thread are demonstrable advantages to the use of the meaninful/meaningless paradigm. So far we've identified all of the advantages and disadvantages mentioned by many people (in the summary at the beginning of this thread). Once there are...
Hi Kilfoil
I completely agree with you and the points you make. The key words in your statement above are "forseeable circumstances".
I thought you'd enjoy the following anecdote showing how some very clever people (who had even been to university)! managed to get things very, very wrong over...
Dear Doc Man
Thank you for your interesting and well presented post.
If primary keys are meaningless they are always invisible to the user of the system. In this context there is no look or feel. I understand that your comment relates to the presentation to the user of the data contained...
Download the quality standard from my site, read it carefully and then re-name your fields/tables as recommended. If you do that and then post back your revised schema I'd be happy to give you more input.
Dear Rainman
You've done a great job with the re-design, the schema is starting to look good.
The only things I'd change are: Employees and Tasks tables (name in the singular).
Now back to design issues.
One Case has many Expenses (good)
One Client has many Cases (good)
One Task may have...