You could also consider constructing your own unique identifier, e.g. a sequence number combined with an idenfitier of your operator. There's some good arguments to try and avoid using the database as the source of unique identifiers.
You also might not need to have this identifier as the primary key on your table. For example, do you (or might you) want to persist orders without creating an order number? Cheers, John On Apr 15, 6:45 pm, Caio Kinzel Filho <cai...@gmail.com> wrote: > Hm... I see... > > Thanks for the idea. > > > > On Wed, Apr 15, 2009 at 2:41 PM, Greg Young <gregoryyou...@gmail.com> wrote: > > > no hilo and that are two different methods ... but you could pretty > > easily put them together ... > > > hilo generates a base 2 number (usually displayed as a base 10 number) > > just make it base 36 .... > > > Cheers, > > > Greg > > > On Wed, Apr 15, 2009 at 1:37 PM, Caio Kinzel Filho <cai...@gmail.com> wrote: > > >> Is there a way I ensure that HiLo will generate for the 80bit key, > >> only combinations of letters/numbers? > > >> On Wed, Apr 15, 2009 at 2:18 PM, Greg Young <gregoryyou...@gmail.com> > >> wrote: > > >>> Assuming this is all so you can be occasionally connected and still > >>> generate an id > > >>> do id checkouts ... say each occasionally connected client has 1000 > >>> ids and when they run out they check out new ones ... > > >>> use things with enough randomness ... using letters helps with > >>> representing these ... you can fit a random 80 bit number into a much > >>> smaller character field (numbers/characters). Your chance of collision > >>> at 1/2^80 is small enough for most systems ... > > >>> use something similar to nhibernate's hilo generator. > > >>> Greg > > >>> On Wed, Apr 15, 2009 at 1:12 PM, Caio Kinzel Filho <cai...@gmail.com> > >>> wrote: > > >>>> I agree with you on "generally they receive an id when they reach a > >>>> central system", > > >>>> but my scenario is a little bit different: > >>>> The "user" actually is a company operator, placing orders received by > >>>> phone for a customer. > >>>> The customer must receive an order id, for tracking purposes, etc > >>>> The order is placed but its state is not yet "Confirmed" ( _that_ will > >>>> happen when the order is processed by the central system) > > >>>> On Wed, Apr 15, 2009 at 2:02 PM, Greg Young <gregoryyou...@gmail.com> > >>>> wrote: > > >>>>> Thsoe types of numbers are not generally created assigned in an > >>>>> occasionally connected system ... maybe I am misunderstanding you ... > >>>>> generally they receive an id when they reach a central system. > > >>>>> On Wed, Apr 15, 2009 at 1:00 PM, Caio Kinzel Filho <cai...@gmail.com> > >>>>> wrote: > > >>>>>> One scenario: > >>>>>> A user post an order, and receives as a confirmation, an order number > >>>>>> (which must be unique and so, it's my primary key). > >>>>>> It would be akward to see something like: > > >>>>>> "Your order is: 3F2504E0-4F89-11D3-9A0C-0305E82C3301" > > >>>>>> On Wed, Apr 15, 2009 at 1:56 PM, Greg Young <gregoryyou...@gmail.com> > >>>>>> wrote: > > >>>>>>> Why do you want human readable keys? > > >>>>>>> On Wed, Apr 15, 2009 at 12:53 PM, caiokf <cai...@gmail.com> wrote: > > >>>>>>>> Hi, > > >>>>>>>> Which approach do you guys suggest to handle Primary Keys in an > >>>>>>>> occasionally connected system? > > >>>>>>>> In my understanding, the options are: > > >>>>>>>> - GUIDs/UUIDs : which present a non-human readable key, which I want > >>>>>>>> to avoid. > >>>>>>>> - AppID, ID: difficult to mantain the AppID for all the clients, and > >>>>>>>> I > >>>>>>>> think it kind of polute my domain. > >>>>>>>> - Some sort of Primary Key Pool: how could I integrate that with > >>>>>>>> NHibernate in a (most) transparent way (as possible)? > > >>>>>>>> If someone has some other suggestion or stories about that matter, it > >>>>>>>> would be very helpfull. > > >>>>>>>> Thanks, > >>>>>>>> Caio > > >>>>>>> -- > >>>>>>> It is the mark of an educated mind to be able to entertain a thought > >>>>>>> without accepting it. > > >>>>> -- > >>>>> It is the mark of an educated mind to be able to entertain a thought > >>>>> without accepting it. > > >>> -- > >>> It is the mark of an educated mind to be able to entertain a thought > >>> without accepting it. > > > -- > > It is the mark of an educated mind to be able to entertain a thought > > without accepting it.- Hide quoted text - > > - Show quoted text - --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to nhusers@googlegroups.com To unsubscribe from this group, send email to nhusers+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
