× 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.



Hi,

For tables that do not need to have universally unique Ids, we use Identity
Columns.
For tables that need universally unique Ids (unique over multiple systems,
wie use the SQL function GENERATE_UNIQUE, which includes among other
information the internal form of the Universal Time, Coordinated (UTC) and
the system serial number.

Mit freundlichen Grüßen / Best regards

Birgitta Hauser

"Shoot for the moon, even if you miss, you'll land among the stars." (Les
Brown)
"If you think education is expensive, try ignorance." (Derek Bok)
"What is worse than training your staff and losing them? Not training them
and keeping them!"


-----Ursprüngliche Nachricht-----
Von: MIDRANGE-L [mailto:midrange-l-bounces@xxxxxxxxxxxx] Im Auftrag von
Richard Schoen
Gesendet: Monday, 25.1 2016 22:28
An: midrange-l@xxxxxxxxxxxx
Betreff: Auto-incrementing key or GUID for new DB ?

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>

--
This is the Midrange Systems Technical Discussion (MIDRANGE-L) mailing list
To post a message email: MIDRANGE-L@xxxxxxxxxxxx To subscribe, unsubscribe,
or change list options,
visit: http://lists.midrange.com/mailman/listinfo/midrange-l
or email: MIDRANGE-L-request@xxxxxxxxxxxx Before posting, please take a
moment to review the archives at http://archive.midrange.com/midrange-l.

Please contact support@xxxxxxxxxxxx for any subscription related questions.


As an Amazon Associate we earn from qualifying purchases.

This thread ...

Replies:

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.