Talk:Comparison of relational database management systems

From Wikipedia, the free encyclopedia

Comparison of user interfaces to database management systems??

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

Contents 1 Useless columns 1.1 Revert index 2 Question 3 OS support 4 Index organized tables 5 Features in beta versions 6 Bitmap indexes 7 B-tree or R-tree? 8 Fundamental RDBMS Features vs. Implementation Details 9 Stored procedures vs. user defined functions 10 Release date 11 Wow 12 Informix? 13 Informix Added 14 MySQL update suggestions 15 Creator? 16 ANTs Data Server 17 Why have both MaxDB and SapDB 18 SQL isn't relational 19 JDBC and isolation level support 20 Unix? 21 Requested move 22 Unicode support 23 Page move 24 mysql functions 25 Cleanup needed 26 Adaptive Server Anywhere 27 Tables and views 28 A function by any other name 29 Add section on XML indexing and other native XML capabilities? 30 GiN 31 Domain 32 Strange Choice of Databases?

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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.

[edit] 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)

[edit] Bitmap indexes

The DB2 support for bitmapped indexes is questionable, see [this usenet discussion]. TroelsArvin 13:06, 9 Mar 2005 (UTC)

It seems like the same discussion applies to PostGreSQL - from what I understood so far, DB2 and PostGreSQL both create the bitmap-indices during runtime in memory only instead of storing the index persistantly, as it is done by Oracle. I have to admit though, that I have no deeper understanding how this works. Can anybody contribute to this? Maybe the distinction between temporary/ersitant can be added as footnote? -- Semiliki 12:10, 7 July 2006 (UTC)

[edit] 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)

[edit] 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)

[edit] Stored procedures vs. user defined functions

The page currently has a "User defined functions" column and a "Stored procedure" column. If we want to distinguish between user defined functions and user defined procedures, then the "Stored procedure" column should be renamed. But before I do that: Does anyone know why both columns are there? TroelsArvin 18:41, 9 Mar 2005 (UTC)

A stored procedures is usually PL/SQL (or similar languages); while a user defined function is not (e.g. linking to host language like PHP, or object files like .obj. --Minghong 10:24, 10 Mar 2005 (UTC)

In SQL, there are two types of "SQL-invoked routines": Functions and procedures. They are almost identical, except for details of how they are invoked and how data are returned. DBMS suport is a bit different for the two routine types, by the way (PostgreSQL supports functions, not procedures, for example). I think you are talking about "external routines" which are routines (functions or procedures) executed by code written in a non-SQL language. What I find interesting to list is:

• trigger support
• support for SQL-routines (whatever kind)
• what external languages are supported
• support for user defined types

TroelsArvin 10:58, 10 Mar 2005 (UTC)

Not sure about standard SQL. But I'm talking about UDF in Firebird [3] and SQLite [4]. Maybe CREATE FUNCTION is not creating a UDF? I thought it was the same. --Minghong 11:04, 10 Mar 2005 (UTC)

The terminology I've used matches standard SQL. And the same terminology is used in the Oracle, PostgreSQL and DB2 documentation. TroelsArvin 11:21, 10 Mar 2005 (UTC)

I've tried unifying the "Stored procedures" and "User defined functions" columns. TroelsArvin 12:40, 10 Mar 2005 (UTC)

Minghong, you have undone my unification, and then introduced two errors, and general confusion:

• Error 1: The page currently says: "User defined function refers to external routines written in the host languages, such as C, Java, Cobol, etc.". This is wrong: A user defined function can be written in either SQL or an external language. If we want to display the difference between functions written in SQL and external binaries/scripts, then the term "external" needs to be emphasized, as "user defined function" is too vague.
• Error 2: The page now states that PostgreSQL supports procedures - which is wrong (PostgreSQL has no 'CALL ...' construct). My previous edit removed that error.
• Worse: The page now has columns for both functions and procedures (in addition to "User defined function"). Why have both, when the difference really is minimal (see my previous comment). And, if both are retained: At least, you need to specify the difference, if you introduce the separation of concepts.

TroelsArvin 14:26, 10 Mar 2005 (UTC)

Sorry for undoing your change. But unification makes it ambiguous. Procedure and Function are two things as there are 2 statements: CREATE PROCEDURE and CREATE FUNCTION (there are more, like packages, rountine, etc, but these are not common). If the differences are really that minimal, maybe combine the 2 columns. For the team UDF, checkout the SQLite, Firebird, MySQL, and PostgreSQL manuals. They consistently use the term "UDF" for external functions (well, DB2 seems not to follow this convention). OK, my fault, PostgreSQL does not support procedures (that's why 2 columns is better than 1 column: we can show that difference). --Minghong 15:24, 10 Mar 2005 (UTC)

I'm not sure it's very informative to say that PostgreSQL does not support stored procedures. Sure, it does not implement CREATE PROCEDURE, but that is mere syntax — functions in PostgreSQL can do much (although not all) of what can be done using stored procedures in other database systems. Not supporting "CALL", for example, is trivial -- it would merely be syntax sugar for SELECT some_func(). I think we need to decide on a clear definition of what the distinction between a "stored procedure" and a "function" is. Neilc 03:20, 19 Mar 2005 (UTC)

Meanwhile, MySQL supports all three types of routines discussed here. The table now posits that "functions" are unsupported. --Juha001 11:11, 7 April 2006 (UTC)

[edit] Release date

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

[edit] 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)

[edit] 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)

[edit] 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)

[edit] MySQL update suggestions

In Fundamental Features, MySQL support for ACID, Referential Integrity and Transactions is "Depends' with a note that the default table type doesn't support them. This is now less true: On Windows the installer will ask if you want transactions and if you do, the default database is set to InnoDB. *nix still ships defaulting to MyISAM. It might be more appropriate to make this a yes with note than a depends with note. Either way, the note needs updating. Anyone who wants transactions will be using InnoDB, so it seems unhelpful to say maybe.

In Indexes, Hash is described as for Heap only. Heap is now called Memory and InnoDB, while it can't have an explicit heap index, automatically creates internal hashed indexes based on its analysis of the need for them. The Memory(formerly heap) engine supports btree indexes now. [5] Partial as no seems simply inaccurate, since you can use partial indexes.[6]

In partitioning, you can place InnoDB tables into their own tablespace from 4.1 on. Seems a "table-based" column may be useful in this section, since the PG v MySQL v. Commercial external link article simply says "yes" to MySQL supporting partitioning. Jamesday 8 July 2005 06:22 (UTC)

About the ACID aspect: I believe that "depends" is still the best and most correct way to characterize MySQL's transaction support. As a developer, it's important that when you code your app for MySQL, you can't count on having transactional behaviour. TroelsArvin 8 July 2005 06:48 (UTC)

As a developer, if you don't know what tools or languages you are working with, you can't count on having any specific behaviour at all, can you? --Juha001 11:00, 7 April 2006 (UTC)

It's included in all of the 4.0 and later builds MySQL distributes, so it's a completely standard feature. Jamesday 13:28, 17 July 2005 (UTC)

Have MySQL 4.x's (and 5.x's) MyISAM tables suddenly become transactional? TroelsArvin 14:56, 17 July 2005 (UTC)

Agree, that doesn't sound right. --minghong 15:54, 19 July 2005 (UTC)

About partial indexes, at least according to that link MySQL implements a rather different and more limited concept of "partial indexes" than does Postgres. In Postgres, a partial index is defined on an arbitrary predicate (e.g. CREATE INDEX foo_bar_idx ON foo (bar) WHERE (bar > 3)); that index can be used for a query if the index's predicate includes the query's predicate (e.g. SELECT * FROM foo WHERE bar = 5; would use the index, whereas WHERE bar = 2 would not). I'm not sure if there is a standard definition of "partial indexes", but certainly just adding "Yes" for MySQL would be misleading.

As for partitioning, the ability to place tables in a particular tablespace is not partitioning. It might be worth having a separate item for "tablespace support", though. Neilc 00:40, 20 July 2005 (UTC)

According to this link then MySQL can do partitioning.

That's 5.1. What just came out is 5.0. Turnstep 20:29, 24 October 2005 (UTC)

MySQL does support functions, but doesn't support external routines...The table should be updated

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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.

[edit] 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)

[edit] 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)

[edit] 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)

[edit] 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)

[edit] mysql functions

As I keep having to change this, though I'd explain things here: mysql does not currently have an internal procedural language equivalent to pl/sql, pl/pgsql, or transact-sql. What it does have is the ability to create functions by linking to a shared object created using C or C++ [7]. Turnstep 23:19, 12 November 2005 (UTC)

No — MySQL 5 supports a subset of SQL/PSM, which is functionally similar to pl/sql and pl/pgsql. I've updated MySQL's entry to say it supports "procedures", but not "functions", although I'm not sure there is a universally agreed-upon definition of the difference between the two. Neilc 23:59, 12 November 2005 (UTC)

Looks like someone changed it back again if you did. I think the section on functions, procedures, and external could use a lot more clarification myself. As it stands, there is not much point in differentiating between the three if enough wiggle room exists for everyone to put a "Yes". :) I'll revert the MySQL/function thing at least. Turnstep 14:16, 7 March 2006 (UTC)

[edit] Cleanup needed

This article needs some encyclopedic context; what is the importance of the software being compared? Why are these particular aspects being compared, and not others? In particular, why the listed operating systems and not more or fewer? Most importantly, what distinguishes a "truly relational database" from a "relational database", other than POV? The existence of [[Comparison of truly relational database management systems" seems odd. —donhalcon^╤ 21:28, 7 March 2006 (UTC)

See the articles on RDBMS and company for an explanation of the significance of "truly". Turnstep 19:07, 19 March 2006 (UTC)

[edit] Adaptive Server Anywhere

I've removed Adaptive Server Anywhere, as it only appeared in the top table, and a comparison page really needs each item to appear in each section. I could have left it in, but removing it seemed better than adding many rows full of question marks. If anyone has information on it, please feel free to add it back in. Turnstep 19:07, 19 March 2006 (UTC)

[edit] Tables and views

So Postgres doesn't have materialized views but gets away with a "it can be done with triggers"? In that case, the same should go for MySQL. Just do a search on "materialized views mysql" and you will get similiar solutions that use stored procedures and triggers. The implementation referred to in the footnote doesn't utilize any functionality specific to Postgres. --Juha001 11:26, 7 April 2006 (UTC)

Be bold and make the change! Find one of the solutions and make a footnote to it. Turnstep 15:39, 7 April 2006 (UTC)

I think we can't fairly say that either Postgres or MySQL "implements materialized views"; they can be crudely emulated with triggers and a procedural language, but that is hardly the same as a proper materialized view implementation. Therefore I've changed both table entries to "No", but kept the footnotes. Neilc 16:55, 5 September 2006 (UTC)

Are even the footnotes worth keeping? If so, that note should go on every DB server which has procedures and triggers. --Craig Stuntz 19:00, 5 September 2006 (UTC)

Why are Microsoft SQL Server's indexed views only "similar" to a materialized view? -- A.M. 14 April 2006

[edit] A function by any other name

Barring any objection, I'm going to merge the Function and Procedure into a single column, as there seems to be no clear distinction made between the two for the purposes of this article, and it just makes the table that much wider without really adding more information. Turnstep 15:45, 7 April 2006 (UTC)

[edit] Add section on XML indexing and other native XML capabilities?

I'm only familiar with SQL Server in this area; can others fill in data for other DBMSs?

[edit] GiN

I removed the GiN column, on the grounds that no released DBMS actually implements this feature, even PostgreSQL. Even so, it is just an idea that a few Postgres hackers came up with, it's hardly a proper index type that other databases could reasonably be expected to implement. It might make sense to have a column for full-text indexing, however. Neilc 05:12, 28 August 2006 (UTC)

Hmmmm ... maybe one column on full-text indexes, and another on on "other" indexes? The Other column would have to be a list or a number rather than yes/no. In addition to GIN, there's GiST (and both of those are algorithms, so other databases could implement them) Spatial, R-Tree, XQuery, etc. Jberkus 19:47, 23 September 2006 (UTC)

Nobody else has done anything about this, so I'm going to clean it up per my suggestion above. It's silly to have an index type column supported by only one database. Of course, I'm going to need other people to fill in the exotic index types supported by DBs other than PostgreSQL, since I don't know them. Jberkus 07:29, 16 December 2006 (UTC)

[edit] Domain

Not a specialist myself, I'd like to know what the “domain” object is (in paragraph Other objects). Is it data domain? If yes, can anybody add a link to this article, or I can do it myself, as soon as I'm sure it's the right “domain”. --Olivier Debre 19:34, 24 September 2006 (UTC)

A domain is basically a simple user-defined type: it includes a base type and some optional associated constraints (e.g. NOT NULL, CHECK, foreign key). It's not the same as a "data domain", AFAICS. See CREATE DOMAIN for PG's syntax and some examples. Neilc 20:14, 24 September 2006 (UTC)

Thanks! --Olivier Debre 10:29, 25 September 2006 (UTC)

[edit] Strange Choice of Databases?

Currently, this page contains the following database systems which I've never heard of before (given 12 years as a DBA) and suspect of having miniscule-to-nonexistant user bases: Pyrrho DBMS, H2, OpenLink Virtuoso, SmallSQL, WX2, SUPRA SQL. On the other hand, it omits the following DBMSes which have had wide usage for years: PervasiveSQL, Progress, MS Access, Adabas and FrontBase (there's probably others, too). Are we aiming to include everything, or are there criteria for inclusion/exclusion? Jberkus 07:46, 16 December 2006 (UTC)