Is it 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."
These people have made the decision to use a hilo partitioning strategy ... I would hope they chose the partitioning strategy for a reason. Any reasonable person should be able to see that they made a tradeoff in the size/distribution of their key for concurrency and scalability. Greg On Fri, Apr 3, 2009 at 11:33 AM, John Morales <[email protected]> wrote: > 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 > > > > -- It is the mark of an educated mind to be able to entertain a thought without accepting it. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
