Whether it's irrelevant is another question, but I think there might be other people concerned when a table only contains a few 100k worth of records yet the id's are in the billions.
I agree that for the most part the surrogate key value is a minor implementation issue, and you're right that int64, or better yet a decimal type backed by oracle number(28) which allows in the precision to octillion values, running out of space is while not impossible, is incredibly hard... As for user visible, no it's not a issue for the user, while they might see the id in the query string there is no real need for them to know this surrogate key value. I guess I'm to set in if a human readable and somewhat logical 1-to-1 on amount of records and id values.... Oskar does bring up a good point of being able to pull up the record in a query tool becomes tedious. The problem with GUIDS from IIRC is the size of the index, the fragmentation, and the human reability. All I'm stating is that in ASP.NET applications the HILO generator suffers the same flaws... John On Fri, Apr 3, 2009 at 10:53 AM, Greg Young <[email protected]> wrote: > > Who cares what the ids are? what is the % of space remaining in the int64?! > > I mean seriously wtf are you taking hilo ids and showing them to users? > > Greg > > On Fri, Apr 3, 2009 at 8:37 AM, John Morales <[email protected]> wrote: > > While you're right, it's quite possible to avoid reaching the upper limit > on > > of the data size limit, if this is what you consider good design, then > good > > luck to you. > > > > John > > > > On Fri, Apr 3, 2009 at 8:34 AM, John Morales <[email protected]> wrote: > >> > >> A more realistic example. > >> > >> 3 web servers 200 tables, app reseting 5 times a day > >> > >> 3 * 5 * 200 = 3000 high values a day > >> > >> the high value is multiplied by the max_lo so in just 1 year your id's > >> will be in the 190 billion range.. > >> > >> > >> While your' > >> > >> > >> On Thu, Apr 2, 2009 at 9:04 PM, Erik Lundby <[email protected]> wrote: > >>> > >>> <snip> > >>> > >>> . those reserved ranges are lost forever, which is wasteful > >>> > >>> </snip> > >>> > >>> > >>> > >>> But what are you wasting? With an int64 id and that default int16 max > >>> low you are talking about, wouldn’t you have something like 140 > trillion > >>> high values? > >>> > >>> So if you have 100 web servers resetting 3 times an hour, you will get > >>> 7200 high values used a day. > >>> > >>> > >>> > >>> In 19 billion years you can probably just switch to int128. J > >>> > >>> > >>> > >>> Erik > >>> > >>> > >>> > >>> From: [email protected] [mailto:[email protected]] On > >>> Behalf Of John Morales > >>> Sent: Thursday, April 02, 2009 4:39 PM > >>> To: [email protected] > >>> Subject: [nhusers] Re: table hilo and application restarts/asp.net > >>> > >>> > >>> > >>> Yeah, the increment generator does not support more than 1 concurrent > >>> session factory per database, which right now is all I need... And I > guess I > >>> should re-evaluate this decision, this is one of those times where > YAGNI > >>> isn't the best strategy as I might very well need to support scaling > out. > >>> > >>> IMO, the concurrent sessionfactory support hilo has using reserved > blocks > >>> of id's is inefficient, contrary to what the documentation says. Once > the > >>> session factory is terminated. those reserved ranges are lost forever, > which > >>> is wasteful. With the only option is to reduce the max_lo range cap, > which > >>> just reduces the amount of potential waste. A more efficient generator > that > >>> reuses those unused ranges while allowing a clustered environment is > what I > >>> truly need. > >>> > >>> If I have some time I might help out with this. > >>> > >>> John > >>> > >>> On Thu, Apr 2, 2009 at 7:03 PM, Fabio Maulo <[email protected]> > wrote: > >>> > >>> 2009/4/2 John Morales <[email protected]> > >>> > >>> > >>> > >>> While looking into the source I saw that the increment generator does > >>> exactly what I need, it uses a cached copy of the max id for each table > on > >>> appdomain start and assigns id's as necessary. Without having to hit > the > >>> database for each insert. > >>> > >>> > >>> > >>> > >>> > >>> mmmm... take care with it... what happen when you have 2 webserver ? or > >>> two application instance ? > >>> -- > >>> Fabio Maulo > >>> > >>> > >>> > >>> > >>> -- > >>> > >>> This signature is intentionally left blank > >>> > >>> > >>> > >> > >> > >> > >> -- > >> This signature is intentionally left blank > > > > > > > > -- > > This signature is intentionally left blank > > > > > > > > > > > -- > It is the mark of an educated mind to be able to entertain a thought > without accepting it. > > > > -- This signature is intentionally left blank --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "nhusers" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/nhusers?hl=en -~----------~----~----~----~------~----~------~--~---
