X-Received: by 10.70.41.102 with SMTP id e6mr27055563pdl.10.1439332219311; Tue, 11 Aug 2015 15:30:19 -0700 (PDT) X-Received: by 10.182.116.197 with SMTP id jy5mr136238obb.24.1439332219216; Tue, 11 Aug 2015 15:30:19 -0700 (PDT) Path: csiph.com!xmission!news.glorb.com!se8no2190908igc.0!news-out.google.com!nt1ni5857igb.0!nntp.google.com!se8no2190897igc.0!postnews.google.com!glegroupsg2000goo.googlegroups.com!not-for-mail Newsgroups: microsoft.public.sqlserver.programming Date: Tue, 11 Aug 2015 15:30:18 -0700 (PDT) In-Reply-To: Complaints-To: groups-abuse@google.com Injection-Info: glegroupsg2000goo.googlegroups.com; posting-host=2602:306:bcf4:c240:4d2:5906:583:81f3; posting-account=eTE9_AoAAAD1dS9O9Ccywd_vfKFzS40A NNTP-Posting-Host: 2602:306:bcf4:c240:4d2:5906:583:81f3 References: User-Agent: G2/1.0 MIME-Version: 1.0 Message-ID: Subject: Re: Unique Constraint Based on Dual GUID From: --CELKO-- Injection-Date: Tue, 11 Aug 2015 22:30:19 +0000 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable Xref: csiph.com microsoft.public.sqlserver.programming:31270 >> I have a table with a GUID as PK (created via NewId()) << The purpose of a GUID is to locate a GLOBAL resource, not to serve as an at= tribute inside the schema. Since it is not an attribute of anything, it can= not be a key by definition. Keys are not created in RDBMS; they are discove= red in the data itself. =20 What you are doing is trying to mimic a 1970's network database with fake p= ointer chains.=20 >> I also have a table to indicate links [sic] between records [sic] in thi= s table, with a dual [sic: compound?] PK of GUIDS (for the two records [sic= ] that connect [sic: we reference] to each other)<< In RDBMS, we have references, not links. That is more terminology from poin= ter chains. Rows are nothing like records. Records are physical, have no co= nstraints, etc. Rows are logical and might not be physical at all, have DRI= and CHECK() constraints, etc. Event eh term "connect" is a pointer chain t= erm!=20 >> Putting a constraint on these two fields [sic] will limit it to only one= combination of the two fields [sic], i.e., a link [sic] of A to B, but I a= lso need to ensure that the link [sic] is not duplicated as B to A - the li= nk [sic] is non-directional. << Again, fields are nothing like columns. It is that "physical versus logical= " concept again. There is no direction in SQL; it is based on sets and not = pointer chains or vectors.=20 In SQL, we would have UNIQUE (a, b) and CHECK (a < b) instead.=20 >>My idea was to include a calculated field [sic] of the two GUIDs XORed to= gether, and place a constraint on this calculated field [sic]. Can anyone s= ee any issues with this idea? << This is even bad from a network database model. The first rule was never do= pointer arithmetic; always let the DB handle housekeeping and pointer allo= cations. =20 Everything you are doing is completely wrong, based on a lack of any unders= tanding of RDBMS. Will your boss pay for an intro course of some kind? I mi= ss the 1970's, too, but not IMS, IDMS, TOTAL, Image/300 and all the other z= ombie products you are trying to revive :)=20