Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]
Groups > microsoft.public.sqlserver.programming > #31273
| From | Michael Cole <invalid@invalid.com> |
|---|---|
| Newsgroups | microsoft.public.sqlserver.programming |
| Subject | Re: Unique Constraint Based on Dual GUID |
| Date | 2015-08-13 11:59 +1000 |
| Organization | A noiseless patient Spider |
| Message-ID | <mqgtju$ep$1@dont-email.me> (permalink) |
| References | <mqbsbp$9va$1@dont-email.me> <122678eb-cdfc-4e2b-82b6-e43945887545@googlegroups.com> |
--CELKO-- formulated the question : > You missed my point! GUIDs are not for keys; they are locators for external > global resources. This guy wants to use them for pointers like we did in the > 1970'd network databases. > > If you use an actual compound key (a,b), then either they are drawn from two > different domains that are independent (longitude, latitude), two different > domains that are dependent (clothing size, colors), or the same domain (first > color and second color). In the final case, the constraint (a < b) prevents > (b,a), (a,a), and (b,b) Which means that the two-tone clothing item is only > shown one way and really has two tones to it. Except that sometimes you need to use artificial keys, either due to the data itself does not lend itself to a nice easy compound key or becuse the number of fields to be included in the compound key would be enourmous. In this particular case, the table is for connections between entity roles. There is no way of uniquely identifying an entity - they can be combinations of first, middle and last names, or legal or trading names, and without an artificial key, it would be unworkable. We then add into this mix that each entity could be performing multiple roles, and that their role allocation may change over time - it gets rather complicated. Particularly given that the roles that they may be performing will most likely be different for the different clients that they have. We then get to the final piece of the puzzle which is that an entity performing a specific role may then require a connection to another entity perfoming a role. Not everything is as simple as you make out. Regardless of your critisisms of my terminology, I am developing software for actual usage, and whilst it may not be perfect, my boss is more concerned with it being productive and useful. And no, he's probably not going to pay for an intro course of some kind. Our clients don't pay for terminology. Now you are very knowledgable, and there are useful bits in what you say, but not everything is as pristine as you would like it to be, and the general lecturing tone does not help. -- Michael Cole
Back to microsoft.public.sqlserver.programming | Previous | Next — Previous in thread | Find similar
Unique Constraint Based on Dual GUID Michael Cole <invalid@invalid.com> - 2015-08-11 14:07 +1000
Re: Unique Constraint Based on Dual GUID Erland Sommarskog <esquel@sommarskog.se> - 2015-08-11 21:35 +0200
Re: Unique Constraint Based on Dual GUID rpresser <rpresser@gmail.com> - 2015-08-11 12:46 -0700
Re: Unique Constraint Based on Dual GUID --CELKO-- <jcelko212@earthlink.net> - 2015-08-11 15:30 -0700
Re: Unique Constraint Based on Dual GUID rpresser <rpresser@gmail.com> - 2015-08-11 20:13 -0700
Re: Unique Constraint Based on Dual GUID --CELKO-- <jcelko212@earthlink.net> - 2015-08-12 18:26 -0700
Re: Unique Constraint Based on Dual GUID Michael Cole <invalid@invalid.com> - 2015-08-13 11:59 +1000
csiph-web