Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]


Groups > microsoft.public.sqlserver.programming > #31273

Re: Unique Constraint Based on Dual GUID

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>

Show all headers | View raw


--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 | NextPrevious in thread | Find similar


Thread

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