On 20 October 2010 17:50, Steve Holdoway <[email protected]> wrote:
> On Wed, 2010-10-20 at 17:16 +1300, Kent Fredric wrote:
>>
>> I troll a bit, but please, don't subject me to using MySQL, its horrible. :/
>>
>> I would sooner use MSSQL. True story.
>>
> OK, I would have agreed with you at MySQL 3, where we didn't even have
> views, but the mainstream are now at version 5.1.
>
> There are things that MySQL can do that Postgres cannot - multimaster
> replication for a start. And it can perform just as well... as long as
> you tune it properly and rebuild the indexes regularly in a high churn
> environment.
Postgresql prides itself on being the most advanced, and prioritised
features and "Doing things right" over speed, in early days. This has
resulted in Postgres not winning the early adoption department, but
however, as time has progressed, doing things right has lead it to be
fast also, in ways MySQL just cannot compete with.
Postgres *can* do multimaster replication. Its not *stock* but its
designed with the capacity to be extensible. ( And its moving into
stock installs already ).
In databasing, speed is *NOT* the priority, the priorities are
1) Keeping your data intact ( something mysql does poorly )
2) accessing your data in the most maintainable way,
3) ????
4) Speed
5) Profit.
Simply put, something that keeps the data intact but is slow is far
far more important than something that just throws it away, really
fast.
Another thing that bothers me is MySQL's hideously brain-damaged data types.
http://sql-info.de/mysql/gotchas.html # A good list of scary things
mysql <5 did. Many still relevant for >5
Some are design "features" and will always be that way or become
completely backwards incompatible.
Sure, postgres is not without its quirks either:
http://sql-info.de/postgresql/postgres-gotchas.html
But much less of them are of the "Oh that is horribly scary" nature.
Something else I never even knew was a problem that existed was until
after I was forced to use MySQL having used Postgresql for a few
years: Nested queries.
In PG, I pretty much was the master of nested queries, and use them a
ridiculous amount, because they're much easier to aggregate and
assemble in code. This is not a problem, as the PG optimiser just
works out the best way to do what you wrote, and it JustWorks(TM).
However, when I tried doing the same thing in MySQL, to my horror, I
found it not only performed it the wrong way, but some of the simplest
nested queries would bloat mysql till it OOM'd, or go out to lunch for
the better part of an hour, and I had to learn the art of
re-organising queries into much more perverse and hard to understand
variations of the theme, that I'd hate for any maintenance programmer
to try understand, just so they were usable, and this is something I
believe is not my responsibility to solve ( part 2 of my maxims of
"access the data in the most maintainable way" ) . When I worked out
why, I found it was creating complete in-memory copies of tables,
despite the fact it could have easily just merged it into a join
constraint.
And lets not even start embarking on the amount of crap you need to do
in the event you want *2* automatically incrementing fields in 1
table, or you want to span 1 sequence of values across 2 tables. (
Something that is easy to do ). MYSQL seem to think that sort of stuff
should be done in software, but that is a complete failure of a
concept, I may as well ditch MySQL and do my data in software too!,
because that will be more maintainable with alternative clients.
And let me not even embark on the whole problem of "If you use MySQL,
you have to choose a backend, and one backend willl give you an
almost-real database, and the other will give you FTS and certain
index types, sorry, can't have both".
Sure, to some people none of this is a problem, but to me, I'd rather
make my bed across 2 railway tracks.
> I've used both ( and Informix, Ingres, Oracle back when it actually was
> a RDBMS ) for a long time, and would prefer to use Postgres, all things
> considered - especially with Larry around. However, if you've got a
> single box and limited resources and need to run a MySQL based product
> ( WordPress for example ), as well as other back end databases, I
> wouldn't consider running multiple database systems for a second...
> MySQL all the way.
Perhaps, but in my experience, postgres does a BETTER job of eating
less resources than mysql. Mostly because it relies a lot on the Host
OS to dynamically allocate resources and memory.
The MySQL daemon on my laptop that I have no choice *NOT* to run (
because Kde and amarok both seem to need it these days ) , is using
185M of ram, and postgres, about half that!
>
> If people like Google rely on MySQL, then I think it may be time you
> revisited MySQL... (:
No offence to Google, but they make some dumb decisions too. Revisit
MySQL? I have a problem avoiding it as it is, and I do my best to, but
things keep using the sodding thing :<. If I could remove it from my
system completely I would, but I cannot right now.
--
Kent
perl -e "print substr( \"edrgmaM SPA nocomil.i...@tfrken\", \$_ * 3,
3 ) for ( 9,8,0,7,1,6,5,4,3,2 );"
http://kent-fredric.fox.geek.nz
_______________________________________________
Linux-users mailing list
[email protected]
http://lists.canterbury.ac.nz/mailman/listinfo/linux-users
