Hey Christian,

Just a thought.... maybe you could put the ID in the upper bits of
the ID instead of the lower bits? You would just have something
like:
GEN_ID(A_GENERATOR,1) + (USER_NUMBER * shift_amount)

Have been looking at doing something like this with 64 bit PKs...
segregating/partitioning the number space to have a separate
region for each database so that replication can proceed easily
without any PK conflicts -- wherever a record is inserted, it would
be guaranteed to have a unique PK across all databases. Simply
initializing all generators in a database before use with the
database identifier....
leading part +/- 0001 to 9222 x10^15 <=-database identifier
counting part 0 to 999,999,999,999,999

FWIW,
Corey.

======================================
Christian Mautendorfer wrote:

>
> At 21:33 09.02.2001, you wrote:
> > > >Just add an ID field to the record. It is a lot easier to manage. The
> > > >alternative
> > > >is to use the generator number, * 100 + User ID, but it is a lot easier
> > > >to find
> > > >all the mods done by ID=X if you can just filter on that field!
> >
> > > Why is this easier to manage?
> >For the reason stated - if you have a separate ID field you can filter
> >on that and find all the mods by user X. Trying to apply MOD in a filter
> >HAS to be slower.
>
> Yes, but I did mention that I would almost never need this but use the
> additional ID
> field I use to mark who edited the record last.
> It is just that I have this possiblity should I need it.
>
> > > And about the generator number * 100 + UserID... Why do you think that
> > > is any better or easier?
> >
> >Because you only increment the generator by one, and there is no chance
> >of it getting 'corrupted' by not being a multiple of 100.
>
> That is true. Generator corruption is the most dangerous thing I see in my
> model.
> That's why I need a clean application and no manual entry except where
> triggers fire.
> (For scripts this works great)
>
> > > The ID would give me an additional field and my pk would be 2 fields >
> > wide.
> > > Is the mod UDF so slow
> > > that it will seriously degrade performance if I ever need to check that?
> >
> >Anything that can not be indexed or easily filtered will be slow.
> >
> > > (Like I said there is more stuff to this peer to peer, I have a UserID
> > > field that is used on every Edit/Insert,
> > > but is changable so is not suitable for a PK, but is the only one I should
> > > be needing when updating)
> >
> >The PK is STILL the Generator output, you do not need to add the user ID
> >to it as only one user can add one number. If anything it prevents the
> >situation where you COULD have the same top number with different users.
> >123433 and 123444 are unique and will not be trapped by PK,
> >While 1234 ID 33 will prevent 1234 ID 44 from being allowed.
>
> Actually this states why your model won't work for me!
> 1234 ID 33 and 1234 ID 44 will not be allowed like you siad unless ID is part
> of the primary key. Now I want clean merges, so any value generated by any
> User should be allowed to merge. So this would work ONLY if ID was part of PK.
> Because the Key is the generator number + ID. That would be the only way to
> uniquly identify a record in the 'system' (=all peer to peer clients). And
> that is the
> criteria for a PK.
>
> Now to the big drawback with this model is that I would have to link all
> relations
> to 2 fields. Any yes I do have a lot of relations. Most of my tables have
> links to
> other tables and some have multiple FK's.
>
> So your point about Generator curruption is very true and well thken because a
> single corrupted generator could prevent clean merges. The rest I don't
> quite aggree with :)
>
> Still thanks for advice :)
>