Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Auto incr number or GUID?
Message
From
27/10/2003 11:52:59
Cetin Basoz
Engineerica Inc.
Izmir, Turkey
 
 
To
27/10/2003 11:44:09
General information
Forum:
Visual FoxPro
Category:
Databases,Tables, Views, Indexing and SQL syntax
Miscellaneous
Thread ID:
00842581
Message ID:
00843027
Views:
25
Hey Nancy,
I could never summarize its benefits as neatly as you did in your email :) I should copy it for a reference.
Cetin

>>Hi,
>>I am designing database for my new application. I think to use AutoNumber as PK, however, it will cause problem while replication. Do you think combination of AutoNumber and BrandID as PK is a good solution? Will it complicated coding? how about GUID?
>>
>>Thank you
>
>Here are a couple of more links that might be of interest to you.
>
>http://support.microsoft.com/support/kb/articles/Q269/3/87.asp
>http://fox.wikis.com/wc.dll?Wiki~GUID~VFP
>
>I like GUIDs for a few reasons. Here's a summary of an email I wrote recently to a client.
>
>The two facts about GUIDs are that 1) they are (practically) guaranteed unique across all computers, and 2) there are many more possible keys than integer keys (2^128 possibilities for a 16-byte key). These two facts have the following benefits:
>
>a. You can safely integrate disconnected (offline) data sets. Having integrated data, usually by writing an import routine, this is significant. It’s not difficult, but it is tedious and prone to error to import records that you first have to check for duplicate keys in.
>
>b. You don’t have to check the uniqueness of a key before using or, nor do you have to maintain a lookup table of “next keys.”
>
>c. The OS is responsible for the algorithm
>
>d. You don’t have to worry about reusing keys in case you run out integer keys.
>
>e. You don’t have to worry about boundary conditions on the key.
>
>f. GUIDs are becoming a de facto standard in data management, so it’s just one more bit that’s compatible with other systems.
>
>The bulk of your data will be in fields other than the key, so the GUID will be a small proportion (given today’s huge and cheap hard drives). I added a GUID field to the largest of a client’s table, which has 1,346,687 records (I really need to write them an archiving routine!). Before adding the GUID, the table was 106MB. Afterwards it was 120 MB. A select on the integer key took as long as a select on the GUID. There will be more data coming across the wire when you do your selects, but, again, a judicious and careful use of views will mitigate performance issues, I believe. I say that because you’ll be working in an environment with high throughput networking, no doubt. If you were going to be using wireless devices, I’d be more concerned. On the other hand, in that case, I’d be using disconnected data sets.
>
>***************************************************************************************************************
>
>Using Çetin's code as a basis, here's a form that you could use as a basis for benchmarking differences.
>
>PUBLIC oform1
>
>oform1=NEWOBJECT("form1")
>oform1.SHOW
>RETURN
>
>
>DEFINE CLASS form1 AS FORM
>
>  DATASESSION = 2
>  TOP = 0
>  LEFT = 0
>  HEIGHT = 254
>  WIDTH = 375
>  DOCREATE = .T.
>  CAPTION = "Form1"
>  NAME = "Form1"
>
>  ADD OBJECT grid1 AS GRID WITH ;
>    HEIGHT = 203, ;
>    LEFT = 0, ;
>    TOP = 48, ;
>    WIDTH = 373, ;
>    NAME = "Grid1"
>
>  ADD OBJECT command1 AS COMMANDBUTTON WITH ;
>    TOP = 10, ;
>    LEFT = 145, ;
>    HEIGHT = 27, ;
>    WIDTH = 84, ;
>    CAPTION = "Click Me!", ;
>    NAME = "Command1"
>
>  PROCEDURE guid16tostr
>    LPARAMETERS tcGUID16
>    LOCAL lcGUID
>    lcGUID=REPLICATE(CHR(0),80)
>    StringFromGUID2(tcGUID16,@lcGUID,40)
>    RETURN STRCONV(LEFT(lcGUID,76),6)
>  ENDPROC
>
>  PROCEDURE getguid16
>    LOCAL lcGUID
>    lcGUID=REPLICATE(CHR(0),16)
>    UuidCreate(@lcGUID)
>    RETURN lcGUID
>  ENDPROC
>
>  PROCEDURE RESIZE
>    THIS.grid1.WIDTH = THIS.WIDTH
>    THIS.grid1.HEIGHT = THIS.HEIGHT - THIS.grid1.TOP
>  ENDPROC
>
>
>  PROCEDURE DESTROY
>    CLOSE DATABASES ALL
>  ENDPROC
>
>
>  PROCEDURE INIT
>    DECLARE INTEGER UuidCreate IN 'RPCRT4.dll' STRING @pGUID
>
>    DECLARE INTEGER CoCreateGUID IN 'Ole32.dll' ;
>      STRING @pGUID
>
>    DECLARE INTEGER StringFromGUID2 IN 'Ole32.dll' ;
>      STRING rGUID, STRING @lpsz, INTEGER cchMax
>
>    DECLARE RtlMoveMemory IN WIN32API ;
>      INTEGER @DestNumeric, ;
>      STRING @pVoidSource, ;
>      INTEGER nLength
>  ENDPROC
>
>
>  PROCEDURE command1.CLICK
>    LOCAL lni, lnS, lcBCID, lcID
>    CREATE CURSOR crsrGUIDS (BCID C(16) NOCPTRANS NOT NULL, cID C(38))
>    lnS = SECONDS()
>    FOR lni = 1 TO 10000
>      lcBCID = THISFORM.getguid16()
>      INSERT INTO crsrGUIDS (BCID) VALUES (lcBCID)
>    NEXT lni
>    DEBUGOUT SECONDS()-lnS
>    REPLACE ALL cID WITH THISFORM.guid16tostr(BCID)
>    GO TOP IN crsrGUIDS
>    THISFORM.grid1.RECORDSOURCE = 'crsrGUIDs'
>  ENDPROC
>
>
>ENDDEFINE
>
>
Çetin Basöz

The way to Go
Flutter - For mobile, web and desktop.
World's most advanced open source relational database.
.Net for foxheads - Blog (main)
FoxSharp - Blog (mirror)
Welcome to FoxyClasses

LinqPad - C#,VB,F#,SQL,eSQL ... scratchpad
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform