Re: range remove in BTree, or other table storage

On 25 fév, 04:38, "laurent" <laurento..._at_gmail.com> wrote:
> On Feb 24, 8:09 am, "Cimode" <cim..._at_hotmail.com> wrote:
>
>
>
> > On 24 fév, 01:40, paul c <toledobythe..._at_oohay.ac> wrote:
>
> > > Marshall wrote:
> > > > On Feb 23, 12:54 pm, "Cimode" <cim..._at_hotmail.com> wrote:
>
> > > >>On 23 fév, 19:54, "laurent" <laurento..._at_gmail.com> wrote:
>
> > > >>>Certainly reading books in an excellent method of education,
> > > >>>but I disagree that there is no educational value in using the
> > > >>>internet.
>
> > > >>Disagree with whom ?
>
> > > > With the guy who said "you will not get a serious database education
> > > > by using google or online questions". It was in the context of
> > > > my message but you snipped it.
>
> > > > Marshall
>
> > > just to get back on the topic, first, i don't have references but could
> > > care less about them when talking to somebody who's programmed a btree
> > > but I would think when applied to some level in the "tree" the removal
> > > of a very definite range should be very fast provided that the free list
> > > "underneath" it, if you will, is also physically organized with the same
> > > kind of structure as the tree itself.
>
> > > as far as physical IO's are concerned, only the nodes at the highest
> > > levels would have to change.
>
> > > bulk insert is another question. so is postponing the physical,
> > > conventional approaches for that would seem to require other components
> > > not to do with indexes, such as storage or concurrency managers.
>
> > > it all reminds me of auto carburetors for some reason i can't explain
> > > very well. separate circuits whose performance effects overlap at
> > > certain engine speeds.
>
> > > p
>
> > Btrees are just a modern reeminiscence of good old VSAM (OS390)
> > hierachical search accelerators indexing schemes. As all procedural
> > approaches they are inherently underoptimized by breaking rule of
> > independence between logical and physical. Their usage is at best
> > application specific for pulling out quiclky insert records...Anything
> > else added is superfluous. The fact that BULK INSERT is not practical
> > to do is a proof of what I say...(As BULK INSERTS were impractical
> > under VSAM).
>
> i think you made your point that you do not like b-trees, but sofar
> you have not suggested an alternative. do you know of one?
Check Tarin's transformation method implemented in transrelational model. DATE has a chapter that explains some of the basic principles in *Introduction to Databases Systems - 8th edition*

My liking or not of b-trees is not that important. Was trying to point out its limitations. Received on Sun Feb 25 2007 - 14:03:27 CET