On 2016-05-28 12:49 PM, r.a.n...@gmail.com wrote:
@Daren
Any reasons for the thumbs down on MySQL? Their workbench is better that Toad
...
On May 27, 2016, at 10:00 PM, Darren Duncan <dar...@darrenduncan.net> wrote:
On 2016-05-27 2:28 PM, Balaji Ramanathan wrote:
But when I was debating between MySQL and
SQLite for my project, I almost didn't choose SQLite because of the archaic
look and feel of the sqlite.org website and support options available
there.
For the love of all that's good, don't choose MySQL for anything. If you want
something bigger than SQLite, look at Postgres instead of MySQL. As a bonus,
the Postgres documentation is much better. -- Darren Duncan
r.a.nagy,
My judgement is based primarily on the DBMS server itself, which is the product
being compared, not on separate client programs. (And each DBMS has multiple
clients that work with it.)
For practical decision purposes, Postgres and MySQL both compete in the same
space as each other, multi-user client-server DBMSs. This is a different space
than SQLite competes in. If you're doing a task appropriate to the space SQLite
is in, I recommend using SQLite. If you're doing a task appropriate to a
multi-user client-server DBMS, I recommend for Postgres and against MySQL.
Comparing the two...
Postgres is a high-quality project with a semi-regular predictable release
schedule and has a strong emphasis on good quality and good security, being as
bug-free as possible and in not losing data. Postgres has an order of magnitude
of more, useful, features, and gains a lot more that people can notice each
year. Its design decisions make more practical sense and it strives to be a lot
more compatible with the SQL standard where that makes sense. In summary, it
has tons more features people actually use and find valuable, and it has a
strong emphasis on keeping the quality up. When relatively rare bugs or
security issues do occur, they are fixed promptly and clear documentation is
given on how to mitigate or recover from the problem. Postgres also has better
general user documentation. Postgres even has useful features that Oracle
doesn't have. Postgres also has expert level support from multiple companies,
and its BSD license (almost like public domain but not quite) means it can be
used in any applications without a special license.
MySQL is a lower-quality project that has historically focused more on user
bases that don't put as much importance on the quality or persistence of their
data and want to use the DBMS more as a dumb data store with most work done
application-side. MySQL has an order of magnitude fewer useful features, often
lacking things that are quite valuable in practice, and a lot of the features it
does have carry various gotchas or strange behaviors. As such, performing a lot
of tasks is more difficult or not possible without excessive circumlocution, and
users are more likely to see wrong answers or data loss due to either unexpected
behaviors or bugs. MySQL is notorious for shipping half-baked code to
production, see version 5.1 in particular. MySQL is also notorious for going a
long time claiming that particular important features are not important. This
includes a number of features that even SQLite has long had. MySQL also has
gone a long time without perceptively adding new features with much
significance. Their main advance in features was between versions 3 and 5.1,
the last being a decade ago, and since then have mostly talked more about things
like speed enhancements and not much on interesting features. The MySQL
documentation isn't as good. MySQL has a twin GPL/proprietary license so you
need to pay Oracle lots of money if you want to use it in some applications, and
Oracle doesn't have as much motivation to make it a contender when they have
their other bread and butter DBMS to compete with.
So MySQL is decently suited say for running stuff like blogs or message boards,
while if you want to do something important like run a financial accounting
system or medical database, Postgres should be used instead.
This assumes applications warranting client-server. SQLite should also be used
instead where it makes more sense, and SQLite is much more thorough about
quality and being bug free than Postgres, with its 100% code coverage test suite
and all.
-- Darren Duncan
_______________________________________________
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
http://mailinglists.sqlite.org/cgi-bin/mailman/listinfo/sqlite-users
