*I want not IDs generated from the RDBMS because it does a hard a system
distributed, if were necessary. Instead, I use GUIDs because I want a
global identifier for that can be merged the users' table from different
services, when it is necessary.*
That's not, strictly, a reason to avoid the RDBMS' auto increment values.
Depending on which db you're using, you can create an index that's (shard,
id) where the ID is automatically incremented and is unique to the shard.
You still have an index that's unique, but you don't have to agree on what
ID is inserted next between the different shards. In fact, that's largely
what noeqd is doing for you.
On Sun, Dec 2, 2012 at 4:48 PM, Patrick Mylund Nielsen wrote:
Sequential allows you to do binary search, and at least gives databases a
way to make guesses about where to seek. It also makes insertion faster
when the number is unique/the primary key.
Oh, I have no arguments that an *indexed* column is a good thing when you
will be using it as a lookup key. Having the items that go into that column
be sequential by insertion order is orthogonal to that. Databases often
use b-trees for indexes (though you can often customize that if you know
something interesting about the indexed data beforehand), so it's often
somewhat better than binary search. When you have indices, insertion will
take longer regardless of what's being inserted in the row, so and the
uniqueness checks are subject to much the same performance dynamic as
lookup in terms of indexing.
I guess the easy answer is if you need to coordinate the generation, but
don't want to, use UUIDv4s. When storing a large number of rows on
different systems, I would only do that if the occasional collision is no
On Sun, Dec 2, 2012 at 10:15 PM, Kyle Lemons wrote:
You haven't provided us with nearly enough information to answer your
question. What kind of table? Is your system distributed? What kind of
ordering requirements do you (not) need? Why do you need GUIDs (i.e. can
you use your database's automatic row numbering mechanism)? I'm not sure I
agree with your premise that sequential IDs will result in faster lookups
in a table.
On Sun, Dec 2, 2012 at 8:03 AM, Archos wrote:
Do you think that would be right to use a generator (noeqd) for each
different table where it's needed a GUID or is it too overkill?
I question it because every generator would get a sequential number so
it would allow faster lookups into a table.
Thanks in advance!