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: UUID vs Longint primary key

On Tue, Aug 8, 2017 at 11:00 AM, ​ Chip Scheide <4d_o...@pghrepository.org> wrote: > > Worse, I've found that the same product, from the same vendor in > differing purchase amounts (1 vs case) is the same part number, but > different pricing! So.. even a check on part numbers is insufficient to >

Re: Preventing Duplicate Data WAS UUID vs Longint primary key

Chip: I have always tried doing at the point of data entry. Obviously no code is perfect, and either is the object between the keyboard and the chair. My experience is that few Administrators would take the time to filter through duplicates. Getting them to do system maintenance was almost

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: Preventing Duplicate Data WAS UUID vs Longint primary key

Jody, what are your normal duplicate reducing/removal technic(s)? On Mon, 7 Aug 2017 12:28:21 -0600, Jody Bevan via 4D_Tech wrote: > John: > > Thanks for sharing this. I had not thought of this way after all > these years. I will take the idea and apply where appropriate, in > addition to my

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: Preventing Duplicate Data WAS UUID vs Longint primary key

I've found that after hours "helper" routines that fire off and run in the > background working through data to flag dupes for admin oversight next day is > popular with some managers who prefer to make their own decision about whether > some stuff really is a dupe or not. Some duplicate data has

​Re: Preventing Duplicate Data WAS UUID vs Longint primary key

On Mon, Aug 7, 2017 at 3:00 PM, ​ ​ David Adams wrote: > > > > How do you deal with that problem (Preventing duplicate data) > Definitely ​ "Carefully program your system to detect and prevent duplicate rows" as appropriate. Generally such a Dupe Check can take many forms

Re: Preventing Duplicate Data WAS UUID vs Longint primary key

As a variant on John's technique, I'll combine fields into a single text block that I then run through a fast hashing algorithm that returns a longint. What good is that longint? It helps in two cases: * If you're comparing two copies of the same record during an update/sync, etc., then you can

Re: Preventing Duplicate Data WAS UUID vs Longint primary key

John: Thanks for sharing this. I had not thought of this way after all these years. I will take the idea and apply where appropriate, in addition to my normal code to reduce duplicates. Jody Bevan ARGUS Productions Inc. Developer Argus Productions Inc.

Re: Preventing Duplicate Data WAS UUID vs Longint primary key

What I have done is to have a field in the table that contains the keys that make the record unique with all spaces, special characters, and vowels removed, as well as eliminating any consecutive consonants . See my example below. So far this has worked pretty well for me and I guess would

Re: Preventing Duplicate Data WAS UUID vs Longint primary key

perhaps you can use sounded and store that in a hidden field. Regards Chuck Chuck Miller Voice: (617) 739-0306 Informed Solutions, Inc. Fax: (617) 232-1064

Preventing Duplicate Data WAS UUID vs Longint primary key

> How do you deal with that problem (Preventing duplicate data) When unique data is required because of a business need, I do implement one of your suggested methods: "Carefully program your system to detect and prevent duplicate rows." I would suggest not doing this in a trigger, but instead

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: UUID vs Longint primary key

On Mon, Aug 7, 2017 at 11:51 AM, < ​ <4d_tech-requ...@lists.4d.com> ​ npden...@greatext.com> wrote: > > ​[snip] > > On the other hand, you do model the data after business relations, but the > keys that tie that relation data need/should never be seen in a well > designed system. If a user

Re: UUID vs Longint primary key

> "Yes, use UUIDs in a 4D context rather than SeqNos. And, by the way, the way 4D implemented these > UUIDs - I don't approve with it." Not really. The difference between sequence numbers (your own or 4D's) and UUIDs isn't something I addressed. Don't care. Whatever is better in your system -

Re: UUID vs Longint primary key

David, in short, you are answering the OP's question as: "Yes, use UUIDs in a 4D context rather than SeqNos. And, by the way, the way 4D implemented these UUIDs - I don't approve with it." Fine :-) Marcus MacStrass - Marcus Straßmann Softwareentwicklung und Beratung Auf der Markscheide 35

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: UUID vs Longint primary key

uced with data mergers. Just another "user comprehension data integrity" task. Steve Simpson ​Cimarron Software On Sun, Aug 6, 2017 at 3:00 PM, <4d_tech-requ...@lists.4d.com> wrote: > > > Message: 3 > Date: Sun, 6 Aug 2017 11:03:57 -0400 >

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

​Re: UUID vs Longint primary key

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 convenient for physical relations, but it has exactly zero > to do with a real "primary key" or relational

Re: UUID vs Longint primary key

+2 Nigel Greenlee > On 4 Aug 2017, at 12:09, Marcus Straßmann via 4D_Tech <4d_tech@lists.4d.com> > wrote: > > +1 > > > MacStrass - Marcus Straßmann > Softwareentwicklung und Beratung > Auf der Markscheide 35 > D-44807 Bochum > > Mobil: +49 (173) 374 39 92 > eMail: macstr...@macstrass.de >

Re: UUID vs Longint primary key

+1 MacStrass - Marcus Straßmann Softwareentwicklung und Beratung Auf der Markscheide 35 D-44807 Bochum Mobil: +49 (173) 374 39 92 eMail: macstr...@macstrass.de Am 04.08.2017 um 10:39 schrieb Herr Alexander Heintz via 4D_Tech <4d_tech@lists.4d.com>: >> Someone can explain when is better use

Re: UUID vs Longint primary key

I'll add my vote to Jody's approach. I prefer UUIDs for primary keys for all the reasons mentioned. Having a longint index field is useful as well but for different reasons as Jody explains. My most common use is to be able to quickly sort a table in the order records were created. And it is

Re: UUID vs Longint primary key

So what might be not so good with UUIDs? After watching how people work with our systems for 26 years (most of it without UUID capability) I noticed that they often referred to the record by the Unique LongInt we created for each record. For the first year we hid our unique ID - why would

Re: UUID vs Longint primary key

> I can’t speak to any performance differences when using them as indexed key > fields for searches … they likely have similar performance, but that’s just a > guess. I can speak to the performance, they are not the same. UUID is faster. 4D uses BTrees (binary trees or sometimes called

Re: UUID vs Longint primary key

I can’t speak to any performance differences when using them as indexed key fields for searches … they likely have similar performance, but that’s just a guess. But here’s one situation where UUID has an advantage. We historically used the Sequence Number (a longint) as the primary key, until

UUID vs Longint primary key

Hi All, Someone can explain when is better use UUID and when Longint field in primary key? Thanks Ferdinando ** 4D Internet Users Group (4D iNUG) FAQ: http://lists.4d.com/faqnug.html Archive: