JWColby
jwcolby at colbyconsulting.com
Fri May 4 15:27:31 CDT 2007
LOL, aren't you glad I warned you? John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Elizabeth.J.Doering at wellsfargo.com Sent: Friday, May 04, 2007 4:17 PM To: accessd at databaseadvisors.com Subject: Re: [AccessD] When to Use a Junction Table Most of your gloomy prognostications have come true already this afternoon--they 'discovered' that there are really 8 groups! Fortunately without malice. Thanks, Liz -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of JWColby Sent: Friday, May 04, 2007 10:11 AM To: 'Access Developers discussion and problem solving' Subject: Re: [AccessD] When to Use a Junction Table "There will never be another (your choice of objects here" means that there absolutely will be another such object. When that new object will come into existence is dependent on your choice of implementation. If you choose the right way, you will never even know that the new object came along because someone will just add it to the table and you will be blissfully unaware that it even happened. That may be tomorrow or 5 years from now. If you choose the lazy way, the object will pop into existence several months after you have finished all coding on this part of the project and have forgotten all details of how you did it. Furthermore, you will be embedded deeply in the next "Rush, gotta have it yesterday" project. Furthermore, the new object will be critical to the very existence of the institution. And finally, you will be upbraided caustically and with truckloads of malice for your short sightedness for not preparing for this eventuality, which EVERYONE KNOWS (except YOU apparently!!!) was bound to happen. You might even be short tracked to the dump heap of the incompetents who will never advance in the company because of their obvious shortcomings. John W. Colby Colby Consulting www.ColbyConsulting.com -----Original Message----- From: accessd-bounces at databaseadvisors.com [mailto:accessd-bounces at databaseadvisors.com] On Behalf Of Elizabeth.J.Doering at wellsfargo.com Sent: Friday, May 04, 2007 10:36 AM To: accessd at databaseadvisors.com Subject: [AccessD] When to Use a Junction Table Hullo Gurus! I'm trying to decide if I am just lazy since it is Friday. Or if this will come around later to haunt me ..... A bank has a call center for handling people who have questions about their credit cards. Call center workers are divided into groups which have slightly different permissions to give certain kinds of credits. The list of groups is very limited--three groups--and the list of credits is pretty limited as well, perhaps 35. The right way to structure tables so that I can look up to see if a certain user in a certain group has a certain permission is absolutely to have a table Credit and another table Group and a junction table Permission with foreign keys CreditID and GroupID (and a primary key of PermissionID.) The lazy way causes me less grief in the short term: I make one table Credit, with three additional true/false fields for the three Groups. This way, I spent less time today documenting tables and sprocs to make officialdom happy. In the long run however, I have more grief if a new Group is added. Of course, everyone swears there will never be a new Group. In all of your combined experience, does "there will never be a new Group" mean, "there will be a new Group next week" or "there will be a new Group, but not for years and years" ? How would you structure this? Thanks, Liz Liz Doering elizabeth.j.doering at wellsfargo.com 612.667.2447 "This message may contain confidential and/or privileged information. If you are not the addressee or authorized to receive this for the addressee, you must not use, copy, disclose, or take any action based on this message or any information herein. If you have received this message in error, please advise the sender immediately by reply e-mail and delete this message. Thank you for your cooperation" -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com -- AccessD mailing list AccessD at databaseadvisors.com http://databaseadvisors.com/mailman/listinfo/accessd Website: http://www.databaseadvisors.com