Re: ​Re: UUID vs Longint primary key

> This all started with David making a broad blanket statement about "data > integrity" and "row duplication" and how using "synthetic" record ID keys > ruined the ability to automatically​ ​filter out "dupes". (I _think_ that > was your point David. Please correct me if not.) And in that strict

Re: ​Re: UUID vs Longint primary key

ok - I'm confused. what is the difference between a display only field showing an internal ID number, and a duplicate, display only ID number showing on the entry form? On Tue, 8 Aug 2017 08:07:00 -0600, npdennis wrote: >> I find that by placing the internal linking value (non-editable) on an

Re: ​Re: UUID vs Longint primary key

David, how do you tell these two issues apart: Customer name : John Smith Customer Name : John Smyth is this a typo (one should be Smyth and is not, or one should be Smith and is not)? is it real (2 John Smiths with different spellings) I see this problem with a 'free form' entry inventory

Re: ​Re: UUID vs Longint primary key

> I find that by placing the internal linking value (non-editable) on an > entry form > GREATLY enhances the ability/simplicity of tracking down data issues. This same thing can also be done by adding the same field to the same table but not linking off of it internally :) -- Neil Dennis 4D

Re: ​Re: UUID vs Longint primary key

yes, BUT - I find that by placing the internal linking value (non-editable) on an entry form GREATLY enhances the ability/simplicity of tracking down data issues. ex (without viewable internal key): user: "... customer John Smith does not show the correct invoice(s) Dev/Sys admim: John Smith..

Re: ​Re: UUID vs Longint primary key

Since it sounds like pretty much everyone uses UUIDs for links (me too, although I may not have an actual arrow drawn), maybe se can turn this thread in a different direction? Given that random synthetic keys do nothing to avoid duplicate rows - and may actually make duplicate rows more likely -

Re: ​Re: UUID vs Longint primary key

It might be my memory, but I do not think that is how it worked in the beginning I was working on relational model dbs before SQL was a language Rdb at DEC for example. That was one of the ket differences between model types how you created and maintained the relations. I do not believe that

Re: ​Re: UUID vs Longint primary key

On Sun, Aug 6, 2017 at 5:33 PM, steve simpson via 4D_Tech < 4d_tech@lists.4d.com> wrote: > David and Chuck, point taken about "rows" being unique because of and > created with the containing data of each row -- up to a ... well "a point". The misunderstand of relational theory, design and

Re: ​Re: UUID vs Longint primary key

> Relational model databases by definition are not supposed to use keys that have no meaning. On Sun, Aug 6, 2017 at 12:08 PM, npdennis via 4D_Tech <4d_tech@lists.4d.com> wrote: > You may have stated that backwards… Nope, that's exactly what I meant. But apologies for not making the point more

Re: ​Re: UUID vs Longint primary key

> Relational model databases by definition are not supposed to use keys that > have no meaning. You may have stated that backwards… relational model databases by design should never, never, never use business data for keys. This was the number one rule drilled into me by my college relational

Re: ​Re: UUID vs Longint primary key

On Sun, Aug 6, 2017 at 7:47 AM, steve simpson via 4D_Tech < 4d_tech@lists.4d.com> wrote: > On Fri, 4 Aug 2017 12:52:28 -0700 > ​ > David Adams > ​ wrote:​ > > > > > ​[snip] ​ > > 4D's UUIDs function as globally unique row *serial numbers*. That's great > > for backups and

Re: ​Re: UUID vs Longint primary key

I am not David but I agree with his assessment. Relational model databases by definition are not supposed to use keys that have no meaning. They are supposed to create relations that have meaning. Even the use of numbers breaks the theoretical rule. The problem is that we have pushed all to use