Hello

I am trying to learn standard SQL 99 (SQL3), but it is not very fun to
do when I have no RDBMS that implements it to play with .

Is there a newsgroup that discusses standard SQL ?

What DBMS would implement most (or at least enough) of the SQL-99 ?

What free or open-source DBMS would implement most of the SQL-99 ?

Thank you,
Timothy Madden

On Apr 19, 5:15*pm, Timothy Madden <terminato... (AT) gmail (DOT) com> wrote:

This is the right group for discussion of the SQL standard, IMO.
(there isn't a comp.databases.sql group, but I did not check the
comp.lang.* branch of groups.)

I haven't checked their compliance, but you can look at Oracle's web
site. That might actually be a good exercise: try SQL 99 command
syntax in an Oracle DBMS and report on the compliance you find. You
can download the Oracle DBMS for learning purposes for free. Just make
sure to follow their installation instructions.

HTH,
Ed

On 19 Apr, 23:15, Timothy Madden <terminato... (AT) gmail (DOT) com> wrote:
Not that I'm aware of. Troels Arvin has a page where he compares
different implementations that you might find interest in:

http://troels.arvin.dk/db/rdbms/

I would guess on the following three: DB2, MsSQL and Oracle. I believe
you can download all of them for free.

Guessing again, Postgres


/Lennart

Timothy Madden, 19.04.2009 23:15:

You learn to use one RDBMS (and getting to know a single RDBMS is complicated enough), and its SQL implementation. In most of the cases you will find that the vendor specific extension are sometimes a lot better than the "standard".

Btw: the SQL 99 standard defines a lot of optional features, so the vendors are free to leave them out (or implemement them in a different manner), which makes things even more complicated.

What use is it to practise something that is not completely available?

I think in the OpenSource world, PostgreSQL and Firebird are probably the closest you can get.

Thomas

Timothy Madden <terminatorul (AT) gmail (DOT) com> wrote in news:49eb946e$0$90272
$14726298 (AT) news (DOT) sunsite.dk:


Hi,

An easy way to verify SQL-99 syntax is to use the SQL Validator,
http://developer.mimer.com/validator/parser99/

An online tool available for SQL-92, SQL-99, and SQL-2003.


/Jarl

Jarl Hermansson wrote:
Great tool Jarl!
Didn't know about it.
Do you know more, like a pretty-print application for SQL ?

Thank you,
Timothy Madden

Yes, you can!

IBM DB 2 Express
http://www.ibm.com/software/data/db2.../download.html
(should have a good standards compatibility)

MS SQL Server 2008 Express
http://www.microsoft.com/express/sql...d/default.aspx

Oracle
http://www.oracle.com/technology/pro.../xe/index.html

complicated enough), and its SQL implementation. In most of the cases
you will find that the vendor specific extension are sometimes a lot
better than the "standard". <

I guess if one would like to learn the basis for all of them, it is a
good start to begin with the standard. Often you have both options to
use - either something vendor specific, or the one which is in the
standard. Some, which come to my mind from the Microsoft world:

ISNULL => COALESCE
MONEY => DECIMAL
GETDATE() => CURRENT_TIMESTAMP
CONVERT => CAST

There are certainly more of those... (anyone has a list?)

I would assume that it will give the developer an advantage if he/she
does not lock himself into a specific RDBMS only - where yes, it means
a lot of work to learn the vendor specifc options also.

brgds

Philipp Post

Thomas Kellerer wrote:
Thank you.

I am a C++ programmer who's in the habit of writing portable code every
time, everywhere.

I am much surprised to find that in the SQL world, folks do not worry
too much about portability, if at all.

For example as programmer I much prefer PostgreSQL as my database;
however my clients do not share the same feeling with me and they trust
mysql more for some stupid marketing reasons I don't want to think
about. So sometimes I get to work with Postgres, sometimes I have to
work with mysql. In this situation I would like my queries to be
portable and allow me to switch the DBMS when I need.

When I needed an emmbeded database in some application I had to use MS
Access as the DBMS my entire team could also work with. Later on I
decided I do not trust it for large databases that are important to my
client, so I tried to switch to SQLite, but in the end I choosed
Firebird. Once again in such a situation I would like my queries to be
portable and allow me to switch the DBMS when I need.

It is like portability gives my freedom of choice, it make my
application independent of the underlaying DBMS. And if I use ODBC
changing the DBMS is a matter of changing the connection string.

The other reason for learning SQL-3 is to protect the investment in my
time . Sooner or later the SQL-3 features will be there in all DBMS
products, while vendor-specific extensions will be less and less important.

Yes, I know vendor-specific extensions are so great and they give you
this and that advantage that is not provided in the standard. I am
perfectly aware that a database with no index at all (indexes are not
provided for in SQL-3, at least not at the user-level) is of little use
in a real application, and I would not try to use one like this. As a
C++ programmer I am used with the system-specific features being so cool
compared to what the standard provides, which looks really basic, if not
dull. Still I would like to at least separate the SQL I know should be
portable from the SQL I know _will not work_ should I ever change the
DBMS. In short in my view any vendor-specific extensions should be used
as no more than optimizations in ay SQL application.

As unsupported as it is, there is also a good book about SQL-3 standard,
"SQL-99 Complete, Really" by Peter Gulutzan and Trudy Pelzer, and I am
now finding that there is also an online validator for it

Thank you,
Timothy Madden

Lennart wrote:
Thank you.

I already got DB2, Oracle XE and Postgres. I am surprized to see that

SELECT * FROM INFORMATION_SCHEMA.CHARACTER_SETS;

returns an error in all 3 of them !
Actually DB2 and Oracle seem to have no INFORMATION_SCHEMA at all !

Timothy Madden

Timothy Madden, 20.04.2009 14:34:

The problem is, that the difference in SQL is only a minor aspect. The difference in behaviour when it comes to concurrent reads and writes are much bigger and thus an application that runs fast on PostgreSQL or Oracle might come to a stand-still with SQL Server or MySQL. The same is true when moving applications from SQL Server to Oracle (those examples are simply taken from my experience with those RDBMS, I'm pretty sure that if you throw DB2, Informix, Firebird and Ingres into the discussion similar things will arise)

The difference in syntax is the smallest thing to think about...

Regards
Thomas