IMO you should use a OrderdConfirmationNumberGenerator for the need of your business maintaining the PK as a no-business-meaning POID.OrderdConfirmationNumberGenerator may be a GUID, a progressive number (generated from some table using pessimistic lock), a combination of various data (timestamp, orderdnumber, customer e-mail), a crypt of combination of various data... and so on.
2009/4/15 Jean-Francois Cantin <jfcan...@gmail.com> > Greg, > > So in your scenario, do you keep the PK as GUID and use another column for > the "application Id" checkout? > > Jean-François > > > On Wed, Apr 15, 2009 at 11:18 AM, 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. >> >> >> > > > > -- Fabio Maulo --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
