Talk:Comparison of relational database management systems/Archive 2005

message: Indexes: R-/R+ Trees
I was under the impression that both Oracle and DB2 offered this "functionality" through their spatial extension offerings. Spatial Cartridge is the name used by Oracle I believe, and Spatial Extender for DB2. For MS SQL Server, you get similar functionality using 3rd party extensions (ArcSDE by ESRI for example, which also works with DB2, Oracle, Informix and Ingres I believe). Please note also that the Open GIS Consortium has defined some standards the vendors need to follow to be fully "spatial" in the past. Not sure if anyone supports them other and PostGIS (Postgre) and ArcSDE. 
What's a "revert index"? TroelsArvin 13:02, 9 Mar 2005 (UTC)
replies: text: Revert index is available in Oracle. "Creating a reverse key index reverses the bytes of each column key value, keeping the column order in case of a composite key". For example, the value of the primary key ranges from 7000 to 8000. If a regular index is used, the B-tree (or R-tree) will be unbalanced. If they are reverted, i.e. 0008, 9997, .... 0007, the tree will be more balanced. --Minghong 15:29, 9 Mar 2005 (UTC)
replies: text: Ah, a reverse index. I've changed the page. TroelsArvin 18:31, 9 Mar 2005 (UTC)
replies: text: Oops, sorry for the typo. --Minghong 11:01, 10 Mar 2005 (UTC)
thread_title:  Revert index 

message: Nice work! Do you have any plans to include information on scalability, replication, clustering and back-ups? For an example of a DB comparison structure see also: http://det-dbalice.if.pw.edu.pl/ttraczyk/db_compare/db_compare.html (if the link doesn't work see Google Cache).
:Need to do some research first. :-P --Minghong 09:28, 9 Mar 2005 (UTC)
replies: text: Some of these concepts are rather ambiguous (e.g., replication isn't just "replication", but includes variants such as synchronous/asynchronous), and some of the features are available only in an "enterprise"-edition of a DBMS, or as add-ons. I don't think that this page should be filled with debatable features. TroelsArvin 11:39, 9 Mar 2005 (UTC)

text: Nobody would object to that, but someone has to do the work. TroelsArvin 11:39, 9 Mar 2005 (UTC)
thread_title:  Question 

message: The OS support matrix plots support for un-emulated OS support. Sybase explicitly mentions that it needs to be run with the Linux ABI FreeBSD add-on. In some definitions of "emulation", that would exclude Sybase on FreeBSD. Parts of FreeBSD's documentation [use the word "emulator"] for the Linux ABI support. TroelsArvin 11:39, 9 Mar 2005 (UTC)
replies: text: Does that mean FreeBSD support should be "No" for Sybase and Oracle? --Minghong 15:37, 9 Mar 2005 (UTC)
replies: text: I have already set BSD support to "no" for Oracle, because Oracle doesn't mention BSD as a supported platform. For Sybase, I'm less sure: Sybase runs on FreeBSD through the Linux ABI compatibility libraries, so one might call it emulation. However, as Sybase officially mentions FreeBSD as supported, I'm inclined to let it stay as "yes". TroelsArvin 18:31, 9 Mar 2005 (UTC)
thread_title:  OS support 

message: I think it's disturbing that some features are mentioned as being available, but only in experimental versions. We are basically talking about the future (not facts) when planned features are mentioned. DBMS vendors are constantly working on new features, so the page could turn into a jungle of footnotes. Also: Planned features don't always turn into implemented features, as initially expected.
If the page keeps notes about version differences, it would be much more useful to introduce notes about when a certain feature was added (i.e. notes about the past). TroelsArvin 12:58, 9 Mar 2005 (UTC)
replies: text: The table will be based on the fact in the latest stable version. But footnote is free to list any version (so as to tell others than "it will have that feature really soon". --Minghong 15:37, 9 Mar 2005 (UTC)
replies: text: Anything can happen really soon. TroelsArvin 18:31, 9 Mar 2005 (UTC)
thread_title:  Features in beta versions 

message: While B-tree (or B+-tree) is the simplest kind of index, I think most non-toy RDBMS would use R-tree instead. That's why I haven't specify whether it is B+-tree or R-tree. --Minghong 15:20, 9 Mar 2005 (UTC)
replies: text: R-tree indexes are used for geometric data. It doesn't make sense to call it a "basic" index type. Actually, it would be relevant to add a column marking R-tree support in the different DBMSes. TroelsArvin 18:31, 9 Mar 2005 (UTC)
replies: text: I've added a column for support of indexing of geometrical data. TroelsArvin 09:26, 10 Mar 2005 (UTC)

text: Really? Isn't multi-column index a R-tree (as R-tree, in simple terms, multi-dimensional B-tree)? e.g. CREATE UNIQUE INDEX emp_pk_idx ON emp( dept_id, staff_id ); I think that's a fundamental data structure, not necessary related to geometric data (although it certainly helps). --Minghong 10:18, 10 Mar 2005 (UTC)
replies: text: It's true that an R-tree an be seen as a generalization of B-trees. But that doesn't mean that an index covering multiple columns is automatically an R-tree, as far as I know.TroelsArvin 10:47, 10 Mar 2005 (UTC)
replies: text: Alright, it seems that some RDBMSes uses B-tree even when the index involves multiple columns. (I just wonder how... Multiple B-trees? B-tree is single dimension only...) P.S. I've added hash index since it is the most fundamental index. --Minghong 10:55, 10 Mar 2005 (UTC)
replies: text: Regarding multi-column btree indexes, as far as I know it is almost universal practice to implement an index on multiple (scalar) columns via a B+-tree. That's because a multi-column index is not multi-dimensional. Neilc 03:16, 19 Mar 2005 (UTC)

text: You changed my "Geometric" index type to "R-tree". I disagree with that change. DB2, for example, has an index type for geometric data, but it's not strictly R-tree based (as far as I know). What's interesting is if the DBMS offers (at least one) multidimensional index type.TroelsArvin 11:09, 10 Mar 2005 (UTC)

text: I have yet to see DBMS documentation mention R-trees in other contexts than geometry. I really think that the "R-tree" column is uninteresting in itself now, (and I suggest that it be removed). Exactly like I wouldn't care exactly which index type and implementation a DBMS uses for full-text indexing, as long as it supports efficient full-text index based queries. (A relevant column-addition candidate, by the way.)TroelsArvin 12:00, 10 Mar 2005 (UTC)
replies: text: I'm aware of full-text indexing. However there is no index type known as "full-text", i.e. CREATE FULLTEXT INDEX... or CREATE INDEX ... FULLTEXT ...? It should be put under "special features" or "other features" instead. --Minghong 12:30, 10 Mar 2005 (UTC)
thread_title:  B-tree or R-tree? 

message: I have a general concern about listing implementation details such as index types and partitioning in a comparison article. Features like conformity to the relational model, SQL support, etc., are fundamental properties of RDBMSs and should be listed here. Partitioning, OTOH, is a kludge required because some DB servers can't perform acceptably (use whatever definition of "acceptably" you care to, here) without using it in some cases. People don't choose a DB server because it supports partitioning, they choose it because it allows them to quickly and concurrently manage data. If partitioning helps, that's fine, but you can't tell from looking at a chart indicating whether partitioning is supported and know whether it's required to get acceptable performance from that particular server. 
In short, I think the most valuable comparison is one which sticks to the issues which affect all servers, such as price, licensing, relational model features, standard interface support (e.g., JDBC, ODBC, ADO.NET, etc.).
-Craig Stuntz
:I had thought about those programming interfaces. But since most possible all of them (except ADO.NET), there is no point listing them. --Minghong 10:24, 10 Mar 2005 (UTC)
thread_title:  Fundamental RDBMS Features vs. Implementation Details 

message: The duplicate header rows for such small tables are incredibly silly.  Oh well.  There's no point in instructing Wikipedians proper practice in technical communication.  You'll just blow it off as "elitist/vague."  At least Apple understands concise interface design.  No duplicate elements, because the user is not retarded.
:Other comparison pages are also following this convention. --minghong 17:35, 11 May 2005 (UTC)
thread_title:  Wow 

message: While I am an Informix user, I don't have enough infomration to answer all of the questions here. Would it be appropriate to add Informix when I get additional information?
:I find Informix rather interesting from a technical point of view. Some might think it's dead, because another major DB vendor bought it. However, it seems that updates for Informix (not just bug-fixes) are still being developed, so I find it OK to add Informix. TroelsArvin 07:43, 24 May 2005 (UTC)
thread_title:  Informix? 

message: I added the Informix RDBS to the tables. I am a regular user, but *not* a Guru on it, so some questions I was unable to answer. Hoping others will check. Naraht 14:30, 24 May 2005 (UTC)
thread_title:  Informix Added 

message: In the first table, the "Creator" column is not quite right, as most of those are not "created" by the named entity, but I'm not sure what else to use. "Owner" is not right, and "producer" sounds funny. Suggestions? Turnstep 13:32, July 19, 2005 (UTC)
:Barring any suggestions, I changed the word to "maintainer" which seems more appropriate. Turnstep 17:37, 1 October 2005 (UTC)
thread_title:  Creator? 

message: Wikipedia's article about MaxDB/SapDB (same page) clearly states, that MaxDB is the new name for SapDB. Thus, SapDB can be seen as the name for an older version of MaxDB. In that case, there is no reason why this comparison page is cluttered with information about SapDB. Would anyone be sorry if I removed SapDB? TroelsArvin 08:58, 9 September 2005 (UTC)
thread_title:  Why have both MaxDB and SapDB 

message: 'nuff said.  I'm reverting to my edits.
:You'll have to say a little more than that. RDBMS purists may take issue with current implementations, but outside of academia the current batch of SQL products are commonly referred to as "relational". I'm probably going to revert this back. Academic theorists don't get to rewrite common definitions. Rhobite 18:41, 21 September 2005 (UTC)
replies: text: Agree. The original classification is easier to understand. --minghong 06:54, 24 September 2005 (UTC)

text: It looks as though someone is "correcting" the SQL/relational split on many pages, including this one. While (very) technically correct, it seems a little silly to draw such a distinction here. Anyone want to comment on this? Turnstep 01:01, 6 October 2005 (UTC)
replies: text: I'd love to see them merged back together. --minghong 10:08, 17 October 2005 (UTC)
replies: text: Me too. Rhobite 15:52, 18 October 2005 (UTC)
thread_title:  SQL isn't relational 

message: Hmm.  Mac OS X, Linux, BSD, and...Unix?  What the hell is "Unix"?  Seriously, most often when I see "Unix" referred to as an OS, it's Solaris they mean.  Is this the case here?
83.226.9.240 06:23, 20 October 2005 (UTC)
thread_title:  Unix? 

message: This is a vote to restore this page to what it once was, "Comparison of relational database management systems", rather than calling this page "Comparison of SQL database management systems."
Turnstep 15:50, 18 October 2005 (UTC)
replies: text: Add *Support or *Oppose followed by an optional one sentence explanation, then sign your vote with ~~~~
* Support - It was a mistake to create a new phrase "SQL database managment system" and cause all this confusion. Turnstep 20:41, 24 October 2005 (UTC)
thread_title: Requested move

message: PostgreSQL 8.1 is just getting 4byte unicode support, MySQL doesn't yet have support beyond the BMP. Where do other databases stand and how can we get this into the article? --Gmaxwell 07:34, 26 October 2005 (UTC)
replies: text: You could always make a footnote next to the column that explains just what the table means by Unicode support. Alternatively, you could show the type in each row, rather than "yes" and "no" Turnstep 23:19, 26 October 2005 (UTC)
thread_title: Unicode support

message: The page move request has been performed based on the comments written by minghong, Rhobite and Turnstep. No other edits to this talk page appear to addres the page move, and since the comments were written well over 2 weeks ago, it seems reasonable to say that a consenus was reached on the move. Happy Wiki-ing! --HappyCamper 00:43, 5 November 2005 (UTC)
thread_title:  Page move