--- In flexcoders@yahoogroups.com, "scott_flex" <[EMAIL PROTECTED]> wrote: > > Shaun, > > Thanks for the reply, good to hear some strong objections. > > First, i'm 99.9% sure this is the only app that will be generating > ids for this database, but i do agree with that point. I have full > control over all apps that would ever generate PKs for my db, i can > make sure they won't conflict. > > I guess the point of a GUID is that I won't have collisions, or the > possibility is so small, i'll take my chances, i'm not talking about > millions of transactions. > > I did think about creating a temp id and the translating when it > comes back down... but i'm trying to avoid having to send someting > back down after i post and save my xml to the database. > > Another thought is that when my app loads, i'll just download X > number of new ids that are available so i know (since the server gave > them to me) they are unused, no collisions. >
This is exactly what I do. I have a pool of ids that get loaded when the client logs into the app. Then as I use up id's a get more when the pool get's too small. Our app can consume more than a dozen of id's at one time so our pool is quite large, but it has yet to fail for me. I was going to suggest this after reading that you were using these as Primary Keys. I should note that we don't use our guids/uuids as Primary keys, they are secondary keys. Our database maintains it's own primary key. I forget what it's called but it's one of those database design patterns that good database admins are supposed to use. Paul > I would say the stragety i'm trying to accomplish is not great for > large teams, but in this case, i'm one developer, one database. If > this product takes off and makes a ton of money it can always be > redesiged later... for now, i'm trying to cut a layer out of all the > server side to client ui mapping for sake of development time. > > --Scott > >
