Talk:B-tree

message: In the first case, joining will lead to disaster if the left and right subtrees are not leafs.
Example: for a B-Tree of max size of 2, insert values of 1 to 11 and then delete 4.  —Preceding unsigned comment added by 190.18.107.147 (talk) 04:52, 15 May 2009 (UTC)
thread_title:  Deletion from an internal node is NOT clear 

message: I deleted the sentence about the psuedo-code for deletion being in intro to algorithms because I have the newest edition of the
book and there is no psuedocode in the deletion section.
--Anon  —Preceding unsigned comment added by 70.226.19.144 (talk) 03:44, 21 July 2008 (UTC)
thread_title:  Intro to Algorithms 

message: I 'm wondering if the U (maximum of elements) in the article is not an 2L (minimum of elements).
:There may be a terminology problem here. The usage of L and U appears inconsistent below. For a simple definition, the number of elements (aka keys) should vary by a factor of 2 to allow splitting an merging to work. Comer uses d as the minimum number of keys in node, and 2d as the maximum number of keys. The number of children will vary from d+1 to 2d+1.  Some use U to be the maximum branching factor (max children) and other use it as the maximum number of keys in a node.Glrx (talk) 20:53, 18 August 2009 (UTC)
replies: text: Do L and U refer to limits on keys or the limits on branching? If they refer to keys, then setting t=1 would create a 1-key/2-key B-tree which would be the ordinary 2-3 B-tree.  It depends on the definition of "minimal degree".  CLRS may be using t in the same sense as Comer's d.Glrx (talk) 20:53, 18 August 2009 (UTC)

text: This would fit if Slady's "order" of a B-tree is Comer's d -- the minimum number of keys in a node. Then L=d+1 and U=2d+1. U will always be odd. Here L and U are refering to number of children/subnodes and not number of keys.Glrx (talk) 20:53, 18 August 2009 (UTC)

text: The above description is incorrect because a key must be promoted to the parent level during the split. We split a full node (with U-1 elements) only when inserting a new element (for a total of U elements). The result of the split will keep U-1 elements at the current level and promote one element to the parent level. If U is even, then one sibling has (U-2)/2 and the other (U)/2 elements. If U is odd, then both siblings have (U-1)/2 elements.Glrx (talk) 20:53, 18 August 2009 (UTC)
thread_title:  Nodes structure 

message: Should *this* article B-tree have a section that explains variants such as B*-tree, B+ tree, etc.?
Then I want a section that explains pros and cons -- why would someone use one variant instead of another, or instead of a simple binary tree ?
Some people find that preferable to having a bunch of very short stub articles that say "just like a B-tree except that ..." -- or, worse, a bunch of fully-fleshed out articles that repeat the preliminary explanation over and over.
--DavidCary 20:52, 30 July 2005 (UTC)
thread_title:  variants 

message: It appears that there is an error in the illustration. According to the text, all values in the leftmost subtree should be less than a1. In the illustration, however, the leftmost subtree contains the value 3, which is equal to a1.
----
I agree, from "Database Systems: The Complete Book"
   -- if j pointers are used then there will be j - 1 keys,
   e.g. K_1, K_2, ..., K_j-1
   so the first pointer points to a part of the B tree where some of the
   records with values < K_1 will be found; the second pointer points to
   where records with values >= K_1 and < K_2 will be found and so on.
132.205.155.150
-------
This ordering is also used in 'Silberschatz, Korth, Sudarshan: Database System Concepts, 4th Edition'.
Schmid 12:39, 13 August 2006 (UTC)
thread_title:  Error in illustration of B+ tree 

message: The paragraph at the end of the insertion section suggests that an improvement involves splitting nodes that might fill on a leaf node split on the way down the tree.  This buys nothing.  It only reduces 
the effective node size by one.
Unless the nodes are locked there is no guarantee the nodes will remain non-full on the way back up during a split.  To allow maximal concurrency, you don't want to lock nodes on the insert descent.
--Karl Malbrain 20:52, 18 May 2006 (UTC)
thread_title:  Concurrent access 

message: A lot of information is repeated redundantly throughout the article. Please consider rewriting it to make it a bit more concise.
--221.134.26.57 17:37, 21 May 2006 (UTC)
replies: text: I like the use of "repeated redundancy" - Yogi Berra would be proud.  The article is basically a joke, full of too many ambiguities and self-contradictions.    One problem that seems to occur in every Wikepedia article about trees is the failure to distinguish between "keys" and "values" - or state that the two terms are synonymous.   Here, that's just one factor that makes this article useless.  — Preceding unsigned comment added by 68.183.37.170 (talk) 18:32, 21 May 2014 (UTC)
thread_title:  Repeated info 

message: There has been quite a bit of work by Kim S Larsen and Rolf Fagerberg (e.g. http://citeseer.ist.psu.edu/51205.html ) showing how the balance of a btree can be maintained lazily with several benefits. For the purposes of elucidation relaxed balance is particularly good because you can describe insertion or deletion and separate the basic steps of the algorithm and the steps for the maintenance of balance. Another benefit is that all modifications to the structure of the tree are local, so concurrency is more easily exploited.
It'd be nice for the text to include a description of this work. 
Dr Tom Conway (talk) 01:20, 3 January 2008 (UTC)
thread_title:  Relaxed Balance 

message: I could be missing something obvious, but I don't see why tuning a B-tree to disk block sizes would result in a 257-513 B-tree. Shouldn't it be a 257-512 B-tree?  —Preceding unsigned comment added by 128.221.197.21 (talk) 12:47, 31 July 2008 (UTC)
thread_title:  Minor Quibble 

message: This depth will increase slowly as elements are added to the tree, but an increase in the overall depth is infrequent, and results in all leaf nodes being one more hop further removed from the root.
Is that "hop" just the writer's voice, or do people frequently use the word "hop" to describe that? I know there are a lot of terms used in computer science that don't sound nearly as technical as they are, but on the other hand, "hop" only occurs once in the entire page. (Not saying it's a problem and needs to be fixed, just wondering.) --146.187.184.231 (talk) 19:45, 6 November 2008 (UTC)
replies: text: It's a term borrowed from networking, apparently. I would use "one node," and have modified it accordingly. Dcoetzee 21:16, 6 November 2008 (UTC)
thread_title:  hop? 

message: There is a "citation needed" marked beside the word Boeing.
The citation is in the external link mentioned below, named
NIST's Dictionary of Algorithms and Data Structures: B-tree
at http://www.nist.gov/dads/HTML/btree.html
written as this:
Note:
:: The origin of "B-tree" has never been explained by the authors. ... "balanced," "broad," or "bushy" might apply. Others suggest that the "B" stands for Boeing. [Bayer and McCreight were at Boeing Scientific Research Labs in 1972.] Because of his contributions, however, it seems appropriate to think of B-trees as "Bayer"-trees.     
:::        -   Douglas Comer, The Ubiquitous B-Tree, Computing Surveys, 11(2):123, June 1979.
I am just not sure, how to edit links on the page...
~  —Preceding unsigned comment added by 195.146.109.168 (talk) 15:46, 13 November 2008 (UTC)
thread_title:  Boeing citation 

message: "can be done in O(log2N) comparisons. If the table had 1,000,000 records, then a specific record could be located with about 20 comparisons: log21,000,000 = 19.931". It's a detail, but that's not the meaning of the Big-Oh notation. Depending on the implementation it may need a million comparisons or even more. The big Oh notation only says something about how the performance scales as N increases. I understand, though, that this may be harder to explain in Layman's terms and that it might confuse readers who don't know about complexity analysis, but what is written now is just plain wrong. 84.194.88.199 (talk) 15:44, 8 May 2010 (UTC)
thread_title:  Big Oh notation 

message: I'll get right down to it.
===== Problem with definition =====
First, in the list of five Definition rules, the second rule is:
2.  Every node (except root) has at least  children.
But, leaf nodes have no children.  In defining the number of elements by
the number of children, the article later leaves ambiguous the number of
elements in leaf nodes.
Furthermore, the section decribing bulkloading uses a different set of rules where the leaf nodes and internal nodes have different maximum sizes, and seems to imply an expectation of the disconnection of the number of elements in leaf nodes from the number of elements in internal nodes.  However, the rest of the article above this section assumes leaf nodes have the same maximum number of elements as internal nodes (as I understand it).
Near the top of the article, some inconsistencies in terminology in the literature about B-trees are raised.  Perhaps this is at least part of the origin of some of these problems.  The article would be better if after expositing the variations in terminology, it would choose and assert definitions for a system of terms to be used at within the remainder of this article.  That would make the article clearer both in the minds of editors and to the reader, and would provide a framework on which judgements of correctness (by editors) and building of understanding (by interested end-user readers) could be based.
===== B-trees in filesystems and FAT filesystem =====
I have corrected an incorrect application of the terms "logical block" and "physical block" in the section of B-trees in file systems.  Almost nothing in modern file systems refers to physical blocks, as disks present an interface in terms of Logical Block Addresses (LBAs) or logical, not physical, CHS addresses.  (Floppy disks still use physical CHS addresses, but are becoming rarer and rarer.)  Furthermore, even DOS file systems like FAT12 and FAT16, considered primitive by most today, use logical addresses in the FAT which are relative to the data area of the file system volume and are not the physical addresses of the disk nor addresses relative to the start of the partition.
Therefore, I have changed this section of the article to use the terms "file block" and "disk block".  I think it is clearly enough implied that a file block is a block addressed relative to a file, and it is obvious that such a block address is logical, not physical, so I have not used the word "logical" with "file block", and I have not explicitly defined what a file block address is.  As for disk blocks, it is not really pertinent to the B-tree discussion whether they are physical or logical, so long as it is clear that disk block addresses address actual blocks on the disk, not abstract blocks in an abstract file, using an address scheme that is global over at least the part of the disk used by the file system.  Again, I think implication suffices to expose this; anyone who has a basic understanding of the purpose, nature, and rudimentary fucntion of a file system should understand this, and anyone who does not will not understand, or probably be interested in, the discussion of B-trees in file systems anyway.  The point is that file systems map file blocks--parts of a file--to disk blocks--units of storage on a disk--and that this is what B-trees (and File Allocation Tables, and other alternative concepts and structures) are used for in file systems.  The physical/logical dichotomy here is both incorrect and overly narrow so as to confuse or at least complicate the essential concepts about B-trees in file systems.
:I think that the term "Disk Block" is still very problematic for a number of reasons, starting with the fact that in most OS environments and jargon it has a very specific meaning that is different from how it is used here.  "File Block" is confusing because it is unfamiliar and unclear what it means.  The term actually used by almost all implementers, practitioners and analysts of extant B-Tree indexing is "Bucket".  This is the term that I would suggest be used in this article.  RBarryYoung (talk) 15:24, 28 February 2013 (UTC)
thread_title:  I fixed some things; more improvements needed 

message: I have corrected an incorrect application of the terms "logical block" and "physical block" in the section of B-trees in file systems.  Almost nothing in modern file systems refers to physical blocks, as disks present an interface in terms of Logical Block Addresses (LBAs) or logical, not physical, CHS addresses.  (Floppy disks still use physical CHS addresses, but are becoming rarer and rarer.)  Furthermore, even DOS file systems like FAT12 and FAT16, considered primitive by most today, use logical addresses in the FAT which are relative to the data area of the file system volume and are not the physical addresses of the disk nor addresses relative to the start of the partition.
Therefore, I have changed this section of the article to use the terms "file block" and "disk block".  I think it is clearly enough implied that a file block is a block addressed relative to a file, and it is obvious that such a block address is logical, not physical, so I have not used the word "logical" with "file block", and I have not explicitly defined what a file block address is.  As for disk blocks, it is not really pertinent to the B-tree discussion whether they are physical or logical, so long as it is clear that disk block addresses address actual blocks on the disk, not abstract blocks in an abstract file, using an address scheme that is global over at least the part of the disk used by the file system.  Again, I think implication suffices to expose this; anyone who has a basic understanding of the purpose, nature, and rudimentary fucntion of a file system should understand this, and anyone who does not will not understand, or probably be interested in, the discussion of B-trees in file systems anyway.  The point is that file systems map file blocks--parts of a file--to disk blocks--units of storage on a disk--and that this is what B-trees (and File Allocation Tables, and other alternative concepts and structures) are used for in file systems.  The physical/logical dichotomy here is both incorrect and overly narrow so as to confuse or at least complicate the essential concepts about B-trees in file systems.
:I think that the term "Disk Block" is still very problematic for a number of reasons, starting with the fact that in most OS environments and jargon it has a very specific meaning that is different from how it is used here.  "File Block" is confusing because it is unfamiliar and unclear what it means.  The term actually used by almost all implementers, practitioners and analysts of extant B-Tree indexing is "Bucket".  This is the term that I would suggest be used in this article.  RBarryYoung (talk) 15:24, 28 February 2013 (UTC)
thread_title:  [[B-tree#B-trees_in_filesystems|B-trees in filesystems]] and FAT filesystem 

message: I had made more improvements in this section, but all my work was unceremoniously reverted.  I've reinstated the parts I think actually weren't in dispute.  The other parts, in this section, really need improvements, as I think others above have said.  Anyway, my suggested edits are in the history, if someone wants to revive them.
–Stephen 141.158.233.114 (talk) 12:15, 23 July 2010 (UTC)
thread_title:  [[B-tree#Algorithms|Algorithms]] - deletion of a node 

message: I have many issues with these edits, and that is why I reverted all of them.
While there are some improvements (such as FAT12 being 4080-2), there are many inaccuracies. In the B-tree, entries are rotated. Entries are not duplicated. There are unwarranted claims about the size of a file. There are extraneous comments about disk utilities.
I have reverted one of the reinstatements. I am considering reverting the FAT edits again.
Glrx (talk) 16:08, 23 July 2010 (UTC)
thread_title: Comment

message: There is a nice table at the top for complexity reference in big O notation but...nothing there.66.14.187.7 (talk) 18:10, 1 October 2010 (UTC)
thread_title:  Where is the complexity? 

message: "The seek time may be 0 to 20 or more milliseconds..."
Everything takes 0 to 20 or more milliseconds.
Leegee23 (talk) 11:33, 12 December 2011 (UTC)
thread_title: English

message: I'm tempted to revert/modify this edit]. The edit uses another reference to overrule what is ostensibly Knuth's definition. The literature is troubled with differing terminology. See B-tree#Terminology. Knuth's terminology has an unusual bottom level of the tree -- leaves are below lowest keys. "Carry information" is also troubling; in some variations, the associated information is present above the leaves; in others, only key information is above the leaf; in still others, key information is copied above but retained below. Ordinary leaves, however, would have either the associated data or a pointer to that data and carry information. In Knuth's definition, the leaves appear to be the records -- and therefore carry information. Glrx (talk) 18:54, 28 December 2011 (UTC)
thread_title:  Recent edit to Knuth's description of a B-tree 

message: Under section 5.3.3 Rebalancing after deletion there are 
3. Append the first child of the right sibling as the last child of the deficient node
under
1. If the right sibling has more than the minimum number of elements
and
3. Insert the last child of the left sibling as the first child of the deficient node
under
2. Otherwise, if the left sibling has more than the minimum number of elements
From my understanding of B-Tree, these two steps make no sense as after you execute the first two steps described in that section. The separator and the first/last child of the sibling have been rotated. There should be no extra step to append or insert. I have no idea where this step comes from. But maybe I am wrong. I hope someone could further explain this.
Thank you.  — Preceding unsigned comment added by Johnmave126 (talk • contribs) 10:47, 6 May 2013 (UTC)
replies: text: The section appears to describe the operation for a B+-tree rather than a B-tree. In the former, the parent only has a copy of the separator; there is not a full rotation in the B-tree sense. I've changed the section to use the B-tree rotation (and suggest that a left or right sibling may not exist). Glrx (talk) 16:20, 6 May 2013 (UTC)
thread_title:  Request revision on the Rebalancing after deletion 

message: By the definition in the book Introduction to Algorithms, a B-tree of order t is such that its every non-root node contains at least t children, and every node contains at most 2t children. The reason for this is that splitting a node into two nodes is possible only if it contains at least 2t nodes. This is a fundamental requirement for the data-structure algorithms on B-tree to work. In particular then, a 2-3 tree is not a B-tree; it's algorithms are different than those of B-trees. The text currently uses 2-3 trees as a recurring example; those examples should be changed to refer to the 2-3-4-tree, the smallest example of a B-tree. What do you think? --Kaba3 (talk) 18:15, 26 September 2013 (UTC)
replies: text: A 2–3 tree is a B-tree; it fits Knuth's definition. There are many definitions of order and many variations of the B-tree, but the basic algorithms are similar. If I take your definition literally, a 2–3 tree is B-tree of order 2 because non-root nodes contain at least 2 children and every node contains at most 3 children (which is less than 2t but does not violate 2t). Your second sentence is not the driving force behind balancing the tree; if a node may have nmax children, then there is no reason to split that node. The node is happy as it stands. There is also a subtle issue about keys/separators and children; a node has one more child than it has keys. A 2–3 tree has either one or two keys in each internal node. If an internal node of a 2–3 tree has 2 keys (3 children) already and I need to add a third key (a 4th child), then I can split the node into two nodes with one key each (total of 4 children) and the remaining key to the parent. Glrx (talk) 22:48, 27 September 2013 (UTC)
thread_title:  Is 2-3 tree a B-tree? 

message: Hi. I am trying to develop a B-tree toy at . This article already has a link to an animation applet. Since applets are becoming unfashionable, I hope to replace this applet some day. I would appreciate it a lot if you would try out the toy and tell me how it can be improved. Maybe we could replace the applet linked then. --Ysangkok (talk) 13:41, 3 March 2014 (UTC)
thread_title:  Animation 

message: "In the B+-tree, copies of the keys are stored in the internal nodes; the keys and records are stored in leaves"
vs.
" The keys act as separation values which divide its subtrees"
Since a B+-tree is a B-tree, one must be incorrect.  The "copies" can't be in the internal nodes when the original keys are.  — Preceding unsigned comment added by 68.183.92.186 (talk) 22:38, 13 May 2014 (UTC)
thread_title:  key - copies contradiction 

message: "The B-tree uses all of the ideas described above." (What ideas?) "In particular, a B-tree:"
.
.
.
"keeps the index balanced with an elegant recursive algorithm" (where is balancing mentioned above?)
-- the above unsigned note was added on 14 May 2014‎ by 68.183.92.186 (talk)
:Balancing is not mentioned because there is no balancing. The tree is balanced when it gets created and it remains balanced during insertion and during deletion of data – the tree is inherently balanced. Just as it is said: the algorithm 'keeps it balanced', not '(re)balances it after the operation destroys the balance' (like in other balanced trees, e.g. AVL trees). --CiaPan (talk) 17:06, 4 January 2016 (UTC)
thread_title:  The B-tree uses all those 

message: "Overview":
"In B-trees, internal (non-leaf)" - 'non-leaf' is not mentioned in the referred to article. Could you please choose a different term than 'non-leaf', or define 'non-leaf' in the referred to article. i.e. In referring to something to explain something else, that something does not exist to be able to follow what is trying to be explained.
"within some pre-defined range." - range of what?
There is a basic problem here of a lack of definition of what a node is.  There is also a problem that "A node is a structure which may contain a value or condition, or represent a separate data structure (which could be a tree of its own)." is too vague or intangible to be meaningful. In particular, 'condition' above is gibberish (to the reader at this point in their reading). Better, a node [which has an address, i.e. a path (address) by which it can be found <- this 'address' is the missing piece or attribute of the explanation), contains a piece of data. That data could be a value (such as the number 4, or the word 'red'), or a pointer (address) of (i.e. to) another node. [Missing, or, unless, a btree node can (must?) contain at least a value, AND zero or more pointers - at most one to the left (by definition, decreasing?), AND (at most) one to the right (by definition, increasing?)]. So, more succinctly, a node (with/having an address) contains a piece of data. Which is to say, a node is an address/(data and/or left and right pointing) pair.
- now this (above) paragraph may be completely wrong, and that's fine, but in being wrong demonstrates that my (the reader's) purpose in coming to this article is not getting satisfied. Either the above is correct and the article does not so explain 'simplistically' (too conceptual / intangible too fast), or does not well explain soon and simplistically enough what is actually meant (is true / actually is).
"When data is inserted or removed from a node, its number of child nodes changes." is baffling. Probably because it is self-referencing. (It is becoming apparent to me that I don't understand the lingo, or at least the established/recognized lingo, and if I don't, then that says the lingo is not being well explained.) So this bit ("When data is inserted or removed from a node, its number of child nodes changes.") says to me that what should be said is a node is a address/data+pointer 'pair', and nodes (and this is the problem with the use of the same term 'node' twice) contain SETS of nodes (or node sets). Thus the referred to diagram does not make sense (node-wise) as written. However, if one says nodes contain sets of nodes, it starts to come together. (That one does not understand how a node could contain a set of nodes, being a circular description, is ok - one can suspend understanding, expecting such to be explained in subsequent text.) The basic problem with the diagram is that it does not show lines between the .#. pairs. Saying that differently - the 'problem' is either that the diagram is 'wrong' OR the explanation thus far is, since I don't understand / haven't followed.
- by the diagram, the above node = address/data+pointer pairs is wrong. By the diagram, it would appear more correct to say that nodes contain (ordered) sequences of data, WITH POINTERS BETWEEN EACH PAIR OF DATA TO NODES THAT DESCRIBE (COVER) the data/value space between those adjacent values.
So, said differently, one assumes, or soon comes to assume b-tree = binary-tree, which is to say, a node could have at most left and right pointers. By this diagram, a node could have many pointers, and this is not made clear enough early on. So, perhaps earlier in the article it can say a b-tree is not (necessarily) a tree of binary nodes, but a tree of nodes, period. Binary or otherwise. Saying (noting), although possibly considered as redundant, noting that being a tree, nodes have descendants, and by its address knows its ascendant (if the latter is true - does a node's address tell the node where its parent is?).
Summarizing all of the above - the article, within only a few sentences, is as clear as mud. Since the purpose of writing an article is to clear up the mud, perhaps some reworking could be done? [I came here to learn / read / understand, so I'm not the guy to do the rework. i.e. If I understood the material I could contribute to the material, but because I came here to learn the material I can't. I can say, having come here to learn the material - I don't understand. [Therefore purpose in being written hasn't been satisfied. (?)]
"but may waste some space, since nodes are not entirely full" - does not yet follow / make sense. One would assume that a node size is dynamic, therefore only as big as the data contained, and so can waste no space. For the statement to be true, nodes are of a pre-defined size - something that should be stated beforehand. That this is true in the diagram is only now apparent to me. Adding to the diagram, or it's description, '4-element nodes' would make grasping what's being said much more clear much more readily. (Assuming 'element' is the correct term, there.)
The '2–3_tree' diagram illustrates what I say above - there is a diagram depicting a node (to my mind). The diagram depicted within this (b-tree) article shows something (node) that I can't understand as being a node (as I can in the 2-3 article's diagram) - they appear different. Thus I have a mental image of two different things being called 'nodes', and I don't understand (it hasn't been explained in this article) how the term 'node' is accurate for both diagrams. ('One of these things is not like the other' - so, i.e., understanding is not present [same name for two obviously different things]).
 Bs27975 (talk) 18:39, 21 November 2014 (UTC)
replies: text:  Will be glad if someone takes care of these problems. 120.59.185.182 (talk) 07:32, 3 January 2016 (UTC)
thread_title:  2014-11-21 BS Comments 

message: It currently reads very informally and feels out of place with the rest of the article. I'd suggest it be condensed and then split into a pro/con type section. Possibly moved down the page. I'm going to try to formalize the language where I can, but I'm not familiar enough with B-trees to do the rest myself. TheWisestOfFools (talk) 17:03, 29 October 2015 (UTC)
thread_title: The "The Database Problem" section needs cleanup

message: Some examples -- 
pre-defined range, 
From the image it looks as if a single node can host a lot of data, a concept which the the article assumes that the reader knows about.
Joining or splitting of nodes is not defined. 120.59.185.182 (talk) 07:31, 3 January 2016 (UTC)
thread_title:  Undefined terms used in Overview 

message: I think it is not correct to call B-tree the generalization of a binary search tree, as the B-tree requires all the leafs to be at the same depth, and BST does not. So in this way the BST is the generalization of B-tree???
Skrew (talk) 07:38, 24 May 2016 (UTC)
thread_title:  Generalization? 

message: The introduction mentions that, unlike a binary search tree, a B-Tree's nodes can have multiple children. But surely it should also mention that each node can have multiple keys. The B-Tree chapter in CLRS doesn't mention that until its third paragraph, but it seems to be important. The wikipedia page for 2-3 Trees does mention this. I wonder if the 2-3 Tree page should be combined with the B-Tree page, or if they should at least reference each other more.  — Preceding unsigned comment added by Murraycu (talk • contribs) 12:02, 7 July 2016 (UTC)
thread_title:  Nodes can have multiple keys, not just >2 children 

message: I don't have the time to verify this, only got one's confirmation that i'm correct on this one - 
"maximum key length cannot be changed without completely rebuilding the database. This led to many database systems truncating full human names to 70 characters.", that is humbug!? Remove=  — Preceding unsigned comment added by 14.199.34.215 (talk) 09:04, 7 April 2017 (UTC)
thread_title: Disadvantages entry is humbug, remove?

message: The article uses what seems to be floor and ceiling symbols/brackets eg: ˥ ˩. But I don't see how you can have a floor or ceiling when there is only one value between these symbols.   Do these symbols have another meaning?  Or have I missed something? FreeFlow99 (talk) 11:08, 27 January 2024 (UTC)
replies: text: But why would you need more than one argument to Floor and ceiling functions??? --CiaPan (talk) 18:22, 27 January 2024 (UTC)
thread_title:  Floor and ceiling symbols