× The internal search function is temporarily non-functional. The current search engine is no longer viable and we are researching alternatives.
As a stop gap measure, we are using Google's custom search engine service.
If you know of an easy to use, open source, search engine ... please contact support@midrange.com.



Since there was another thread on auto-incrementing keys I thought I would throw out a discussion question on new DB design.

If you are doing a new database would you use an auto-incrementing primary key or GUID for a unique identifier as a primary key ?

There seem to be reasons for both if you google this topic on the web.

Couple initial thoughts.

Auto-incrementing number as primary key

Auto-incrementing key for:
-Easy to set up and next number just happens

Potential con:
-It seems that renumbering or collissions can possibly occur when replicating or copying tables which seems like it could mess up table joins to related files.
-If you use the key value in a URL link without obfuscation or encryption, your app could potentially be easily hacked by modifying URL entries.

GUID/UUID as key

Using GUID/UUID for:
-Appears to be unique across systems
-Should be replicable without key collisions
-Harder to hijack an app URL with the key in it.

Potential con:
-Not sequential and 32 bytes so supposedly can cause indexing performance issues. (At least purportedly on SQL Server)
-More disk space
-Harder to debug app code or data issues because of long key values.

Looking forward to your insight.

Regards,

Richard Schoen | Director of Document Management Technologies, HelpSystems
T: + 1 952-486-6802
RJS Software Systems | A Division of HelpSystems
richard.schoen@xxxxxxxxxxxxxxx<mailto:richard.schoen@xxxxxxxxxxxxxxx>
www.rjssoftware.com<http://www.rjssoftware.com/>
Visit me on: Twitter<https://twitter.com/richardschoen> | LinkedIn<http://www.linkedin.com/in/richardschoen>


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Follow-Ups:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].

Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.