Talk:Comparison of relational database management systems/Archive 2005

Comparison of user interfaces to database management systems??

has anyone got a comparison of the user interfaces to these management systems?

Useless columns

The price column is kind of useless because 1) DB server prices vary widely based on edition, number of users, etc., and are too complicated to go in a table cell by themselves and difficult to compare with other servers due to not being "apples-to-apples," 2) most of the "prices" are question marks, 3) even if they were filled in they would be obsolete quickly, and 4) the header says USD but the only actual price listed is in Euros.

ISTM the point of the author was to distinguish free vs. non-free (beer) DBs, but the licensing column already does that.

Also, I have NPOV concerns about "Proprietary" due to the content of the linked article. I'm not sure what a better link would be, however.

-Craig Stuntz

I agree, let's remove it. And we should consider moving the "Index" and "Table" columns of the "Database object" table, since all RDBMSes support them. TroelsArvin 10:15, 8 Mar 2005 (UTC)

Regarding indexes, there could be a single column listing which index types are supported, I guess, but even that suggests that more types are better, which isn't (IMHO) necessarily the case, especially when viewed from a usability point of view. I'd be OK with dropping the columns. -Craig Stuntz

Another concern I have is with "schema." This term is vague (it can mean a specific server feature or just a database's metadata), which makes the column useless. -Craig Stuntz

Schema refers to the ability to create database schema, i.e. CREATE SCHEMA / CREATE DATABASE. While most RDBMS supports this, some don't. Anyway, probably not that useful, may drop it as well. --Minghong 09:28, 9 Mar 2005 (UTC)

I regret that the schema column was removed. I've seen rather ugly DB designs which would have been nicer if schemas were used. TroelsArvin 11:39, 9 Mar 2005 (UTC)

Nobody seems to oppose removing the price column. I'll remove it shortly, if noone steps up and complains. TroelsArvin 19:15, 9 Mar 2005 (UTC)

Revert index

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)

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)

Ah, a reverse index. I've changed the page. TroelsArvin 18:31, 9 Mar 2005 (UTC)

Oops, sorry for the typo. --Minghong 11:01, 10 Mar 2005 (UTC)

Question

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)

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)

What about MaxDB? (see i.e.: http://www.torsten-horn.de/techdocs/sql.htm#Vergleich-MySQL-PostgreSQL-MaxDB https://www.sdn.sap.com/irj/servlet/prt/portal/prtroot/com.sap.km.cm.docs/documents/a1-8-4/MaxDB%20-%20An%20Enterprise%20Open%20Source%20Database.article)

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

OS support

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)

Does that mean FreeBSD support should be "No" for Sybase and Oracle? --Minghong 15:37, 9 Mar 2005 (UTC)

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)

Index organized tables

I noticed that index organized tables (IOTs) were introduced, and then removed again. The reason for removal was that only Oracle supports them. This is wrong: "Clustering indexes" are a commonly known DBMS concept, and PostgreSQL (and probably others) supports them via the CLUSTER command. In PostgreSQL, however, row changes (including insertions/deletions) don't reorganize the table automatically (potentially a very I/O-intensive operation), so the CLUSTER-command needs to be re-executed when relevant. I also think that InnoDB tables in MySQL are implicitly index-organized (around the primary key, if nothing else is specified). TroelsArvin 12:46, 9 Mar 2005 (UTC)

Are they the same thing? Even so, the name is different, making it hard to be compared. --Minghong 15:37, 9 Mar 2005 (UTC)

Vendors use lots of different terms for the same concepts; one has to get used to that. However, I don't think that clustering index support is important. TroelsArvin 18:31, 9 Mar 2005 (UTC)

Sybase has clustered indexes too. That is on index creation (or reorg rebuild) the data is moved into the same order as defined by the index. During normal insert/update operations the ordering is skipped, so that the table gets fragmented.

Features in beta versions

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)

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)

Anything can happen really soon. TroelsArvin 18:31, 9 Mar 2005 (UTC)

B-tree or R-tree?

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)

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)

I've added a column for support of indexing of geometrical data. TroelsArvin 09:26, 10 Mar 2005 (UTC)

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)

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)

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)

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)

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)

Geometric is not specific enough, and R-tree is not just for geometric data. Unless there is an index type called "geometric", I don't think it should be used. Perheps a new column called "GIT" (DB2) [1] or "GiST" (PostgreSQL) [2]? --Minghong 11:35, 10 Mar 2005 (UTC)

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)

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)

Fundamental RDBMS Features vs. Implementation Details

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)

Release date

Some digging in Google turned up 1997 as the first release of mysql. Turnstep 20:28, Mar 25, 2005 (UTC)

Wow

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)

Informix?

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)

Informix Added

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)

Creator?

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)

ANTs Data Server

It appears that whoever added this has just gone through and checked "yes" for everything without explanation, even though the web site for the product would lead one to believe that this is incorrect. For example, ANTs is listed as supporting MacOS and BSD here, but the manufacturer's site doesn't list those OSs as supported platforms. Either the original poster needs to fix the discrepencies and verify the rest of the claims made about ANTs in this article or the article should be reverted to the pre-ANTs version. Incorrect information is worse than no mentions at all. --Craig Stuntz 14:29, 19 August 2005 (UTC)

I went ahead and removed ANTs. If someone wishes to do research and either (1) put correct information on the page instead of just ticking "yes" for everything, including stuff the ANTs web site doesn't claim to support, or (2) explain why the ANTs web site is wrong and "yes" for everything is in fact correct then they can put it back. But do note that this isn't the only case where shenanigans have been observed for ANTs. There would be no problem with factual information about ANTs here, but simply ticking yes for everything looks like spam to me.--Craig Stuntz 20:51, 25 August 2005 (UTC)

Once again an anonymous IP user added ANTs, simply ticking yes for every item and stomping over Turnstep's wikification of index types in the process. Thank you, ClementSeveillac for fixing the spam/vandalism. Again, there is no problem with having ANTs on the page, but if you're going to add it please research the facts before posting and be a good Wikipedia citizen and don't remove the work of others. Thanks! --Craig Stuntz 18:25, 28 August 2005 (UTC)

I don't know what kind of DB server is ANT, but on a first look, I noticed that they have contradictions/lies right on their features page:

ADS has achieved compatibility with the stored-procedure languages of Oracle, Microsoft, and Sybase, dramatically easing your application ports

The ANTs Stored Procedure Language is similar to a subset of Oracle PL/SQL and is designed to make porting to and from PL/SQL straight forward and easy.

If it is only "similar to a subset of PL/SQL", it cannot be compatible.

Anyway, their site is annoying for being full of *hype* and *buzzwords*. Probably its intended audience is made out of PHBs. :-) bogdan | ^Talk 16:55, 30 August 2005 (UTC)

I found more info here Manifoldtop 17:47, 30 August 2005 (UTC)

Note that sqlboy, who was created a week ago and makes threatening comments in revision comments, has cut and pasted the user page of another user, Michael Hardy into his own user page (it's blanked now, but look at history). --Craig Stuntz 19:05, 30 August 2005 (UTC)

Manifoldtop is playing the same games with his user page (look at history). Gee, you think he's the same person as sqlboy? --Craig Stuntz 19:15, 30 August 2005 (UTC)

Before this edit, ANTs basically had Yes for every possible feature, don't you find that fishy? ;) (it still has many Yeses for me BTW) --ClementSeveillac 07:06, 31 August 2005 (UTC)

Why have both MaxDB and SapDB

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)

SQL isn't relational

'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)

Agree. The original classification is easier to understand. --minghong 06:54, 24 September 2005 (UTC)

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)

I'd love to see them merged back together. --minghong 10:08, 17 October 2005 (UTC)

Me too. Rhobite 15:52, 18 October 2005 (UTC)

JDBC and isolation level support

It would be nice to see for each database if JDBC drivers are available and if isolation levels supported. Otherwise this is a great resource.

Unix?

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)

Requested move

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)

---

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)

Unicode support

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)

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)

Page move

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)