Re[2]: [PHP-DB] Re: MySql or postgre? From: Bob Hall (bobhall <email protected>)
Date: 11/30/00

>Greetings, Bob!
>
>At 28.11.2000, 18:20, you wrote:
> >>BH> harder to learn. Earlier versions had a reputation for corrupting
> >>BH> tables every few months under steady use. Whether this problem
> >>BH> continues in the current version, I haven't heard.
> >> 7.0.* don't corrupt anything anymore...
>BH> Glad to hear it. Can you be more specific?
>::shrug::
>Well, there was that specific point about not checking tuples which
>are too long. I've recently tried to load a DB dump from MySQL where some
>of the tuples were longer than 8kb into Pg 7.0.3... It complained,
>aborted transaction and didn't even try to corrupt anything...

I pointed out that I had heard of pgsql tables getting corrupted
under hard, steady use that continued over several months. I'm hoping
to hear from people who have had that problem and have solved it by
upgrading to a newer version. One person has responded that he solved
the problem by limiting row size on INSERT and UPDATE. That's good to
hear about, but some applications involve large rows. Problems that
occur during batch inserts can be identified and managed more easily
than corruption that accumulates over time, and causes unscheduled
downtime.

BTW, I'm not trying to argue a point here; this is a sincere request
for information.

> >>besides,
> >>its documentation is far more adequate than MySQL's.
>BH> I don't have any problem getting excellent documentation for MySQL.
>::shrug::
>Yup, "Reasons NOT to use foreign keys" is my all-time favourite, too.
>I've already raised that point on this list, I believe...

You've got me on that one, sir. There is some confusion over the
meaning "foreign key", "atomicity", and "transaction". However, most
people use the documentation to learn how to use MySQL, rather than
for instruction in database concepts. For this, the documentation is
very good.

>
> >> The problem is that MySQL's target auditory is the same as (f.e.)
> >>M$ Access' - people who wanna use 'nifty database thingies'
>without investing
> >>too much time into learning.
>
>BH> No sir, that's not the target audience. The target market is people
>BH> who only need a subset of the capabilities that Oracle offers.
> Let's be a lil' wee bit more honest: a very small subset of what
>SQL standard offers...

No RDBMS uses standard SQL, or offers all the functionality in the
SQL standard. The MySQL developers started with the most useful parts
of SQL and are adding other parts over time. All RDBMS developers
have done and are doing this. Most of the complaints about MySQL's
limitations involve problems that actually can be solved with MySQL
SQL. I'm used to a richer SQL set, but I don't have much problem
doing what I want to do with MySQL.

> The most annoying part of MySQL is that misapplied 'SQL' part in its
>name...

'SELECT * FROM table;' isn't SQL? If an RDBMS used SQL as its
interface, where is the misapplication?

> >> I'm afraid, MySQL is just that - a spherical horse in vacuum. It
> >>is quite fast while performing its own benchmarks, but may choke on
> >>realworld tasks.
>
>BH> It will choke on realworld tasks if you use if for tasks it wasn't
>BH> designed to perform. It does very well with realworld tasks it was
>BH> designed to perform. Its benchmarks are intended to highlight its
>BH> ability to perform the tasks it was designed to perform.
> Seems we have reached a consensus. Original poster has to review
>MySQL benchmarks and decide, will his applications be limited to what
>is done in them, or will he be doing something more complex.

I would say, a prospective RDBMS user should look at MySQL
functionality and see if it offers what is needed. Then, and only
then, should he compare benchmarks, keeping in mind that relative
speeds will differ, depending on the peculiarities of the application.

> >> Well, a metaphor once again:
> >> "Second parties adding transactions and row-level locking to the
> >>RDBMS" is like "Second parties are adding 3D engine to Quake". It means one
> >>thing: program's own developers are INCOMPETENT.
>
>BH> Not in the least. It means outside developers want to use the
>BH> software for purposes the original developers didn't have in mind.
>BH> Since it is open source, they can do that. The fact that outside
>BH> developers consider MySQL a good base for further development is
>BH> testament to the original developers competence.
>::shrug::
>Transactions are a vital part of RDBMS. If its developers fail to
>understand this (or fail to implement them) - then...

Transactions are a vital part of some applications. I've done many
projects where transactions would have been a waste of time.
Transactions, and ACIDity in general, are necessary for OLTP. There
are many business applications that require an RDBMS but don't need
mutli-query atomicity, isolation, and so on. Transactions weren't
part of the first SQL standard, so apparently the authors didn't
think they were vital.

A relational database is a database that consists of normalized
tables. An RDBMS is a DBMS that can be used to set up, maintain, and
retrieve data from a database of normalized tables. Whether the DBMS
operations that retrieve data or alter the state of the database are
ACID or not is another issue.

Bob Hall

Know thyself? Absurd direction!
Bubbles bear no introspection. -Khushhal Khan Khatak 

-- 
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, e-mail: php-db-unsubscribe <email protected>
For additional commands, e-mail: php-db-help <email protected>
To contact the list administrators, e-mail: php-list-admin <email protected>