Search results

  1. M

    object oriented progrming - need to learn

    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!
  2. M

    Meaningless vs Meaningful Primary Keys

    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...
  3. M

    Meaningless vs Meaningful Primary Keys

    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...
  4. M

    Meaningless vs Meaningful Primary Keys

    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...
  5. M

    Database Design - Entities in Access

    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...
  6. M

    Database Design - Entities in Access

    Constrain the shift/EmployeeShift relationship and the error should be apparent.
  7. M

    Meaningless vs Meaningful Primary Keys

    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...
  8. M

    Database Design - Entities in Access

    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...
  9. M

    Meaningless vs Meaningful Primary Keys

    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...
  10. M

    Meaningless vs Meaningful Primary Keys

    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...
  11. M

    Meaningless vs Meaningful Primary 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...
  12. M

    Meaningless vs Meaningful Primary Keys

    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...
  13. M

    Meaningless vs Meaningful Primary Keys

    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...
  14. M

    Database Design - Entities in Access

    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.
  15. M

    addition to table messes up query

    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...
  16. M

    Database Design - Entities in Access

    Dear Mosh Your schema is a lot better now. I'd still like to see you do something about your field and table naming but you shouldn't have any problems reporting anything you want from your present schema. By "derived" attributes I'm assuming that you mean calculated fields in your queries...
  17. M

    addition to table messes up query

    There might be but there's always potential for future problems if you don't get the schema design right before you start writing the queries, forms and reports. In the real world a large number of people that take my advanced Access course are jumping through hoops to try to overcome design...
  18. M

    addition to table messes up query

    I sort of thought that might be the case. In other words it is a "one-to-one" relationship. Your first instincts were right, the time information should simply be expressed as fields in the expense table and you'll find that you can then simply create any query you can describe in words...
  19. M

    Recommended Reading List

    Tutorials is probably best. I've been very encouraged by the number of people that have downloaded the free course this week - and no negative feedback (yet)!
  20. M

    addition to table messes up query

    The one that is missing is: One expense is associated with zero one or more time entries (one to many) OR is it: One expense is associated with one and only one time entry. That's the key to your problem I think. Use this real world example to illustrate your answer if there is any...
Top Bottom