No, you are introducing what your customer need as OrderConfirmationNumber that should be unique with rules defined by your customer. Today he can accept a sequential-number, tomorrow he want something with a number and the day of the orther, after tomorrow he can accept a Guid... with all this possibilities do you really want use it as PK ?I don't, thanks. Do you want to be sure that it is unique ? ok, you can use a unique index but you don't need it as PK (note PK is used as foreign key). If you want usage something as PK you should be absolutely sure that it never change its type, for this simple reason we prefer no business meaning PK.
2009/4/16 Caio Kinzel Filho <cai...@gmail.com> > > Fabio, > > Are you suggesting to use a GUID PK + the > OrderdConfirmationNumberGenerator? > > As I have to make the OrderdConfirmationNumberGenerator to generate > globally unique ids, that way I only introduce another PK (relative to > what we were talking in the above messages), isn't it? > > Thanks, > Caio > > On Thu, Apr 16, 2009 at 1:28 AM, Fabio Maulo <fabioma...@gmail.com> wrote: > > 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 > > > > > > > > > > > -- 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 -~----------~----~----~----~------~----~------~--~---
