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