Comments on: Using GUIDs as row identifiers

By: slamcool

slamcool — Sun, 05 Apr 2009 19:12:01 +0000

I read most of people’s feedback here plus made some tests on some DBMS.

Guid are a 128bit integer. Behind it is an algorithm that obviously will be slower than old standard sequential/smaller integers. But, on the contrary to some here, I believe this actually boost up the relational concept all together if you implement this in large scale.

I’ve tested a similar concept with IBM’s DB2 token datatype on a huge os/390 mainframe. This has proven very powerful in sharing/replicating data in between mainframes across the world. Since it gives you a very high potential of IDs to be globally unique.

This ROW id technique is being used now in between some govs I worked for. It’s perfect to create entities and link them with a bunch of other “sattelite” information coming from other external systems and building up a huge database of links in between entities.

That’s my opinion.

By: George

George — Wed, 07 Nov 2007 22:17:46 +0000

@Robert: I knew I would drag it out of you if I just kept at it! Thanks for the lesson, I get it now :)

By: robert

robert — Wed, 07 Nov 2007 19:38:37 +0000

@George: No, a Primary Key is not just some unique string. Unless either a) you don’t care if you get duplicates or b) some other unique string Really identifies the thing. The point of the contemplation is that a true RDBMS models, in the fulsome mathematical sense, whereas IMS/XML/OODBMS/etc. do not. With solid state machines, there is no advantage to using clunky non-relational, redundant type datastores; such are thought to be faster since they don’t join. With solid state machines, use the Relational Model as Codd intended, and present the data as redundantly to the user as the user desires. Just know enough not to impose such on the datastore. Or the relational mantra: one fact, one place, one time. Or its lemma: storing a fact twice doesn’t make it twice as true.

> Machines don’t care. They use pointers

And that’s quite the point: IMS/XML style datastores REQUIRE the coder to manage said pointers.

Quote:
Whereas Codasyl [IDS, 1964] was based on a network model of data, IBM’s database [IMS, 1968] used a hierarchical structure. …Both the IBM and the Codasyl products were sometimes called navigational databases because they required the user to program or navigate around a data set. Bachman’s Turing Award lecture in 1973, in fact, was entitled “The Programmer as Navigator” (Bachman, 1973; Cardenas, 1979)
-National Research Council/1999

I suggest Celko’s book, then Elmasri, then Date.

By: George

George — Wed, 07 Nov 2007 16:29:56 +0000

@robert: I’m slow again today (2-days in a row! Maybe I should see a doctor…) I read the posts you recommended – twice. Not sure why you directed me over there. It seems to be making my point. Memory, solid state or otherwise, is getting cheaper and cheaper, faster and faster. GUIDs are big, long, and ugly – to humans. Machines don’t care. They use pointers. A primary key is a primary key: a way of uniquely identifying a row in a table. What’s an “intelligent” primary key? Speaking of referential integrity, I’m old enough to remember the guy in the office next to me getting chewed out by the boss for using a varchar column instead of an int column for his primary key in the Inventory database. This is the same argument today, only its with GUIDs vs. ints. Times have changed… They will continue to change. Ask most 22 year old programmers today if using GUIDs are bad because of performance penalties and they’ll look at you funny. Some of them are even ballsy enough to reply, “You think Google sticks with ints for PKs in their databases?” ;)

By: Dave

Dave — Wed, 07 Nov 2007 10:57:02 +0000

I have seen decimals used to get around the merge problem (on oracle) (e.g. all ids on a database are x.1, all on another are x.2) It seemed to work well (I’m not a DBA though)

By: Rich

Rich — Wed, 07 Nov 2007 08:32:33 +0000

I commented with pretty much the same view yesterday, which also hasn’t turned up. The only differences were that I said point 4 looked to me like it was the same as point 2 and actually still wasn’t preferable over just bumping up the keys on one machine by X million if you know you’re going to merge data.

Also the possibility of collisions just isn’t good enough in certain domains.

By: Censored Poster

Censored Poster — Wed, 07 Nov 2007 04:45:28 +0000

I too posted some counter-arguments to one of his points and never saw my post show up…maybe someone should try posting in favor and see if their comment is allowed in :)

By: robert

robert — Tue, 06 Nov 2007 21:37:17 +0000

@George:

The contemplation -
http://groups.google.com/group/comp.databases.theory/browse_thread/thread/a11dc89d00073757/03fa754c9393f185?hl=en&lnk=raot#03fa754c9393f185

Start with CELKO’s first post.

Surrogate primary keys (whether GUID or otherwise) are consumate evil; they turn a RDBMS into just a filesystem datastore. The reason being that without intelligent PKs, there is no hope of defining RI. And so on.

By: George

George — Tue, 06 Nov 2007 21:27:37 +0000

@Robert – I must be slow today… I’ve comtemplated for about a minute and I still don’t get your “True RDBMS” approach… [insert confused look here]

@steve et al: I wanted to point out that one thing that GUID’s work great for is in mobile/disconnected apps where you need to create rows on the local disconnected database (SQL CE) and then add them to the server store when synchronizing later. This is a case where you want to create your new ID’s because you are persisting them locally. The GUIDs allow you to easily insert/merge records from many occasionally connected mobile devices with the server.

By: Keith

Keith — Tue, 06 Nov 2007 20:19:26 +0000

I tried submitting a number of counter points to his post as well and they never appeared. Being DBA with warehousing experience, Steve had it right, I would rip his nuts off.