And for PostgreSQL ...

Story: Recover a MySQL Table with Zmanda Recovery ManagerTotal Replies: 9
Author Content
DarrenR114

May 12, 2008
12:52 PM EDT
You simply need to make use of the Write Ahead Logs (WAL) as described here: http://www.postgresql.org/docs/8.2/static/continuous-archivi...

I still don't get why anyone who values their data would use MySQL. Especially after reading this comparison of the two: http://www.wikivs.com/wiki/MySQL_vs_PostgreSQL

One particularly interesting quote:
Quoting: Also, the speed comparisions are mainly between MyISAM and PostgreSQL engines. If the comparison is between the latest versions of InnoDB and PostgreSQL, PostgreSQL is often faster.


And here is a big reason I will not use MySQL on projects:
Quoting:MySQL triggers are activated by SQL statements only. They are not activated by changes in tables made by APIs that do not transmit SQL statements to the MySQL Server; in particular, they are not activated by updates made using the NDB API.
Steven_Rosenber

May 12, 2008
1:18 PM EDT
I'm way back on the road as far as SQL databases go. I managed to create a MySQL database for a project, and to secure the root account, but as far as I'm concerned, both the MySQL and PostgreSQL online docs leave a lot to be desired.

Does anybody have a book recommendation for the SQL newbie, be it MySQL or PostgreSQL?
dinotrac

May 12, 2008
4:25 PM EDT
I don't have a recommendation for newbies, but once you get up to snuff, I am very fond of my SQL for Smarties book by Joe Cecko.
hughesjr

May 12, 2008
5:24 PM EDT
@DarrenR114

If you need real database functionality with real triggers, then sure MySQL is not the best database (at least not until 5.1 goes GA) ... postgresql or firebird would be much better.

However, most web applications do not need that functionality. MySQL is where they are for a reason, so while I would agree with you that more complex databases might be better served with a different product, mysql is more than enough for most web apps.
DarrenR114

May 13, 2008
10:17 AM EDT
@hughesjr My suspicion is that MySQL is where they are simply because of the early widespread propagation of PHP (which I suspect happened because of the early emergence of the apache mod that lets you embed PHP code into HTML pages) which did not include good support for anything but MySQL until the last couple of years.
number6x

May 13, 2008
1:30 PM EDT
I don' know much about MySQL, and yet even I know it supports transactions so I wouldn't base your decision to avoid MySQL on a seemingly out of date wiki.

MySQL does support transactions with the InnoDB engine. InnoDB is now the standard default in MySQL. The Wiki comparison seems to comparing a pre 5.0 version to Postgres. http://dev.mysql.com/doc/refman/5.0/en/ansi-diff-transaction...

But even before InnoDB was the default, it was still available when building tables in pre 5 versions. It was definitely an option before I ever heard of the term 'wiki'. I don't know if the wiki authors are being disingenuous and specifically comparing the deprecated myIsam based MySQL with Postgres in order to maximize the differences, or if they are just ignorant of MySQL features.

Both mysql and postgres are good products. Postgres definitely aims to more of a competitor with Oracle and DB2 UDB, and in doing so is superior to MySQL in some ways, but there are trade offs. MySQL really seems to appeal to the smaller projects and the individual developer. Programmers with MySQL experience are relatively common, and for many applications it is a good fit, but Postgres isn't substantially more difficult than MySQL. They are on the same order of magnitude to use.

I think that Postgres has somehow gained an undeserved reputation for being more difficult. It is not.

I like the Postgres documentation. It is very thorough: http://www.postgresql.org/docs/8.2/interactive/index.html http://www.postgresql.org/docs/manuals/

If you are compiling or administering Postgres they are invaluable.

I have a copy of PostgreSQL Developer's Library: http://www.amazon.com/PostgreSQL-Developers-Library-Korry-Do... I have not read it, but often (almost daily) refer to it.

I did not learn Postgres from any book, just by using it. I wish I could recommend a good book. I would probably benefit from reading one!

Here is a list of books about Postgres: http://www.postgresql.org/docs/books/
jezuch

May 13, 2008
4:10 PM EDT
Consistency? Transactions? Nah... http://www.infoq.com/news/2008/03/ebaybase
pat

May 13, 2008
5:12 PM EDT
The Celko book is great. The only sql server I've found that really sucks is the one from Microsoft. I think we can all agree on that.
gus3

May 13, 2008
8:42 PM EDT
@pat:

Anecdote time about SQL Server.

A guy at my church is a type-A who borders on "super genius." He is always getting ideas, trying them out , fine-tuning them. He conceived a GUI for creating SQL queries, which on the back-end optimized them via stored statements, reducing network I/O to anywhere from 1/3 to 1/10.

Anyway, after his company decided to become Microsoft [TOS violation deleted], he started finding ways to speed up SQL Server. When he hit pay dirt, he shocked himself and the company with the simplicity: every query generates a temporary index on the "where" clause, if it doesn't already exist. A query's first run might not have such an index, but all subsequent runs will, until the server re-starts. And the longer the server runs, the faster it responds.

Until... he found a bug in SQL Server.

Yes, M$ fixed it, but only after three guys in black suits came to visit.

But in the face of this incredible tweak that turned SQL Server into greased lightning, Redmond wasn't interested. Maybe they didn't want to be shown up by "some guy from the sticks" or they're holding on to the idea until they think the market is "ready" (whatever that means).

And the company my friend worked for, just couldn't cram their COBOL-based product onto a Windows platform. They ended up getting bought out and subsumed. My friend is now a teacher and tinkerer, and loving it.
DarrenR114

May 15, 2008
8:02 AM EDT
@number6x,

My thing against MySQL is NOT about transactions (yes I know that MySQL does support transactions in a limited manner) but about the incompetent way MySQL supports TRIGGERS.

Basically, MySQL triggers are useless in the enterprise world since real IT departments looking for the most efficient code with the least execution time will go through APIs. And in the real world, the best way to ensure data integrity is through triggers.

BTW - that Wiki page is NOT so "out of date" as you imply - it also mentions MySQL support for transactions (as limited as it is.)

Posting in this forum is limited to members of the group: [ForumMods, SITEADMINS, MEMBERS.]

Becoming a member of LXer is easy and free. Join Us!