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


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

Re: Unique Constraint Based on Dual GUID

Newsgroups microsoft.public.sqlserver.programming
Date 2015-08-11 15:30 -0700
References <mqbsbp$9va$1@dont-email.me>
Message-ID <a6978bfd-b275-468c-9c7d-a4a64b2e9f4a@googlegroups.com> (permalink)
Subject Re: Unique Constraint Based on Dual GUID
From --CELKO-- <jcelko212@earthlink.net>

Show all headers | View raw


>> 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 attribute inside the schema. Since it is not an attribute of anything, it cannot be a key by definition. Keys are not created in RDBMS; they are discovered in the data itself.  

What you are doing is trying to mimic a 1970's network database with fake pointer chains. 

>> I also have a table to indicate links [sic] between records [sic] in this 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 pointer chains. Rows are nothing like records. Records are physical, have no constraints, 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 term! 

>> 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 also need to ensure that the link [sic] is not duplicated as B to A - the link [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. 

In SQL, we would have UNIQUE (a, b) and CHECK (a < b) instead. 

>>My idea was to include a calculated field [sic] of the two GUIDs XORed together, and place a constraint on this calculated field [sic]. Can anyone see 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 allocations.  

Everything you are doing is completely wrong, based on a lack of any understanding of RDBMS. Will your boss pay for an intro course of some kind? I miss the 1970's, too, but not IMS, IDMS, TOTAL, Image/300 and all the other zombie products you are trying to revive :) 

Back to microsoft.public.sqlserver.programming | Previous | NextPrevious in thread | Next 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