- Site menu:
- Latest Discussions
- Latest Newswire
- Archives
- Submit Story
- Story HOWTO
- Syndicate
- E-mail Alerts
Recover a MySQL Table with Zmanda Recovery Manager
|
|
|
Comments (10)
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?
Does anybody have a book recommendation for the SQL newbie, be it MySQL or PostgreSQL?
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.
@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.
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.
@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.
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/
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/
Consistency?
Transactions?
Nah...
http://www.infoq.com/news/2008/03/ebaybase
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.
@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.
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.
@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.)
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.)
Post a comment
A free account is needed to post. Write your comment here first: your text is kept in this browser while you sign up or log in, and is waiting for you when you come back.
Your message:Markdown: **bold**, *italic*, [text](https://link), - lists, > quotes, $x^2$ for math. Formatting help
Sign up and post (it is free) or Log in and post
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:
And here is a big reason I will not use MySQL on projects: