Talk:Comparison of relational database management systems

From Wikipedia, the free encyclopedia

 This article is within the scope of WikiProject Databases.
??? This article has not yet received a rating on the assessment scale.
High rated as High-importance on the assessment scale
Archive
Archives

Contents

[edit] Transaction types support

This page definitely needs an overview of which transaction types the databases support. For many applications, it is important that you can start a transaction, make 100 select queries over a period of 10 minutes, and know that the first and last query will deliver the same result if they're identical, even if the database is being used and written to by other users in the same time period. It's needed because that's the only way you can make correct multi-query reports from production databases. For instance, Microsoft SQL Server 2000 doesn't support this. Also, it would be interesting to know what the default transaction type is - because that's typically the one that people use.87.63.152.70 (talk) 06:48, 1 May 2008 (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)
I agree, remove the footnotes, triggers do not qualify as a materialized view. However, if the DB implements materialized views by using triggers, and does so such that there are a few defects to the implementation, then I would side with a footnote, that revealed the difference. It just seems rather pointless to say, complex things can be borne from simplicity, or that triggers make a DB turing-complete. EvanCarroll 18:07, 31 May 2007 (UTC)

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


[edit] SQL compatibility

Would this be the right place to compare SQL compatibility with each database? Or is there another article that does this? For example, Interbase does not seem to support the MINUS operator (part of SQL). I was hoping to find a table listing tidbits like these. The management guys might also like a comparison of how "SQL-compliant" a database is, when it comes time to consider one. // Brick Thrower 15:00, 25 January 2007 (UTC)

Personally, I think this information would be too complex to reasonably add to this article. Neilc 04:35, 10 February 2007 (UTC)
I think otherwise, and so I've made an attempt, if people wish to detail the differences let's allow it.EvanCarroll 17:59, 31 May 2007 (UTC)

[edit] Abusing comparison

I can see the argument that an empty entry in a comparison table encourages people to fill them in, but it leaves the current state of the article appearing amateurish and silly. If so little is known about an entry as to make it useless for the purpose of comparison lets exclude it entirely, rather than insert a bunch of kludgy "?" reminding us of what we do not know. We can use the discussion area for notes until enough is known to make the addition useful. *Note* I have not taken the action of reverting anything. EvanCarroll 15:52, 26 July 2007 (UTC)

If you are suggesting (a) to remove a column full of "?" I agree - as long as the column does not contain anything else. If you are suggesting (b) to remove a row full of "?" I don't since the table contain a consistent list of DBMSes. Note that I am talking from my own readers perspective, not as an author. Semiliki 19:52, 30 August 2007 (UTC)

[edit] Additional information

A couple of other pieces of basic information about these databases would be useful.

A number of them, like Derby, are in-memory RDBMSes. This ought to be at least noted if not added as column of information. I'm not sure if there is some more general categorization of the RDBMS that this could be part of.

Are you talking about how Derby and Sqlite are embeddable inside of an application and are not meant to run as a separate server process? I think this would be a good column to put somewhere. --Krappie (talk) 00:49, 20 April 2008 (UTC)
Client-server vs in-process is an orthogonal issue to in-memory vs disk based. perhaps we should have an extra table to cover such issues as:
  • In-memory tables (where the master copy of the table is in-memory for speed of access); subsidiary questions relate to whether such tables are persistent (there is some way to preserve their contents in case of system failure) and/or replicated (eg, copied to a standby server, or to other nodes in a cluster, depending on the distribution model), and whether a mixture of disk-based and in-memory tables can be supported in a single database.
  • Client-server? in-process? (by in-process I mean that the database software is just a library that can be linked into an application, and runs in the same process as the user code; this is much faster, obviously, but a fault in the user code can corrupt the data structures used by the DBMS software, and such corruption might not be detected until very much later. Some in-process DBMSs are in-memory, others are disk-based. There is also a shared library + shared memory approach: multiple applications can have fast access to the data, especially if it is in-memory - but of course, the data vulnerability is increased.) A subsidiary question for client-server architectures is about remoteness and heterogeneity: can client and server be on different machines? Can they be on different operating systems? different underlying architectures (viz, x86 and PowerPC, with their different endianisms - for real fun, throw something like a VAX machine in the mix, with its curious floating point format!)?
  • Hot-standby capability? here a 2nd server keeps an up to date copy of the database, ready to take over at a moment's notice. Subsidiary question: is the standby updated synchronously or asynchronously? (The latter gives greater system performance, but decreases durability.) If asynchronous, can a client detect when its transaction is durable?
  • Cluster replication? here, the database is distributed on a cluster of 3 or more servers, in such a way that the failure of one node does not lose data nor does it break the overall service. This is different from partitioning, as each item of data has at least 2 homes. The distribution scheme may allow for partial replication, where a given server might only hold a selected subset of the overall database, or all nodes may hold identical data. Replication of this type requires n-way commits , and also complex logic to decide how to reconcile the data on the various nodes if connectivity has been broken. Ngpd (talk) 11:43, 21 April 2008 (UTC)

Nevermind the messy issue of SQL compatibility, but whether the interface to the RDBMS is SQL at all as opposed to something else should be noted. I believe Adabas is a non-SQL RDBMS, though there are SQL "gateways" that will translate SQL into a native Adabas query. There are also RDBMSes being developed (such as Rel and Muldis Rosetta) based on Date and Darwins 3rd Manifesto, which use implementations of Tutorial D instead of SQL. I think a column should be added title "Interface" or something similar, under which should be SQL for most RDBMSes, but may be other things. --Ericjs 17:06, 31 October 2007 (UTC)

ADABAS is not a RDBMS, so it is tempting to remove it from here. However, along with its add-on SQL gateway, as the ADABAS 2006 presentation paper at Software AG's says, perhaps the whole has many of the functionalities considered here. But so far, nothing has been filled in the tables for ADABAS, except for OS support and stored procedures (and i suppose that they're ADABAS-specific procedures anyway). So perhaps we could give it some more time, after which, if the desired info hasn't been added here, out it goes? Or, the other way around, whoever has the information will have to recreate the ADABAS rows in the tables? --Jerome Potts (talk) 06:32, 8 January 2008 (UTC)

[edit] Database Specific Proprietary Index schemes

The last two columns of the available indexes table, GiST and GIN are specific to just the one database. I'm sure that all databases have some such unique index schemes. I don't think that they really belong in this article. I propose removing these two columns. TallMagic (talk) 19:56, 1 May 2008 (UTC)