[plug] Recommending a SQL server

[Leon Brooks]

John Summerfield wrote:
>> How do you mean 'Its not relational'

> Codd & Date outlined the criteria which a DBMS had to meet to be
> relational; PG doesn't meet them and the lack of these means extra work
> for the programmers.

> A relational DBMS will allow you to define a relationship between
> employees and location such that you cannot create an employee row for a
> non-existent location. Neither can you delete a location for which
> employee rows exist.

> The checking's done in one location; the RDBMS. If you use PG, you need to
> check this rule in your code, at the points where you insert employee
> rows, at the points where you remove locations: potentially in many places
> in the code and many opportunities to add a few bugs.

>> PostgresSQL runs like a lame dog when compared to MySQL (so do a lot of
>> SQL engines).

> PostgresSQL runs like a lame dog PERIOD. I have observed PostgresSQL doing
> absolutely stupid things such as using disk files (and big ones) to sort
> data that would comfortably fit in (virtual) memory and be sorted in one
> hundredth of the time.

This is so. I guess it comes from being written in the days when there
was no virtual memory, or precious little of it. I understand that as
well as adding gee-whiz new features like their locking-avoidance
scheme, the PostGreSQL crew are working to optimize out these sorts of
archaia.

MySQL seems quite proud of being compliant to various SQL specs, yet you
rejected it out of hand. Is this a simple case of them majoring in the
minors, or is there more to it than that?

I notice that the MySQL test website fails a lot of functions under
PostGreSQL, and since it marks as "not present" a lot of functionality
which _is_ present in PostGreSQL I am wondering about its integrity -
but it might have marked them "in absentia" for a variety of reasons.
Have you looked at that at all?

Since you don't rate with PGSQL or MySQL very highly, are there any SQL
engines that you _do_ like?