Boston Linux & Unix (BLU) Home | Calendar | Mail Lists | List Archives | Desktop SIG | Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings
Linux Cafe | Meeting Notes | Blog | Linux Links | Bling | About BLU

BLU Discuss list archive


[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

MySQL Discussion



> markw-FJ05HQ0HCKaWd6l5hS35sQ at public.gmane.org wrote:
>> Read some detailed text about database theory that discusses the various
>> algorithms for accessing data that does not focus on any single
>> database.
>> Get a grip on the whole of the subject.
>
> I'm fairly familiar with the underlying general database principles (and
> gained my foundation in databases on servers predating MySQL). The
> information I lack is the extent to which MySQL, and the likely
> alternatives, adhere to those principles. (I'd like to find a resource
> more convenient than sifting through the source code myself.)

The MySQL technical docs are pretty truthful, which is surprising.
>
> For example, I know why transactions are useful, but I also know that
> for some situations atomic operations will do the job just as well, but
> this doesn't scale to situations where complexity requires executing
> multiple statements. Knowing general principles only goes so far in this
> situation, as it depends on the specific implementation details as well
> as the nature of the problem being solved.

Yes and no.  There are certain design principles that one adheres too.
Mainly to make life easier, but also to avoid those traps that you have to
think about.

A the developers of a good database have already thought long and hard
about the problems you are going to try and solve.

Maybe an atomic operation will work, maybe not. What about transaction
isolation?

> Most information sources echo opinions, and it's easy to find them on
> both sides. What's needed is an expert analysis of the actual
> implementation, and an opinion given in the context of a specific type
> of problem.

A database is a general purpose solution. As such, specific examples of
problems tend to just echo opinion. The MySQL gang have been having a
field day creating bogus benchmarks.

Understanding how it works is more important. Understanding how a database
system works is the only why to evaluate its applicability to your
application.

>
> Also, many of the comparative differences come down to performance,
> rather than functionality. Take your discussion of how MySQL handles
> locking. It has long been criticized for for using table locking, but
> only real-world application benchmarks prove whether that poses a
> noticeable performance hit.

Table locking is ALWAYS bad. It can be proved that it is (a) bad and (b)
completely avoidable.

>
>
>> I have had MySQL developers look in wonder as I reduce their queries to
>> sub-selects and functions, that improve the performance by at least an
>> order of magnitude. Saying "I didn't know you can do that." My response
>> is
>> "You can on most real SQL databases." (but can't on MySQL)
>
> This is indicative of an obsolete criticism, as MySQL currently supports
> both.

Not well.

>I understand why this comes about, as no one would want to spend
> time keeping current on a tool they didn't use, but it greatly detracts
> from your points when they're aimed at obsolete versions.

No, I periodically HAVE to keep up with MySQL. Just last year, I think I
soured a contract customer because of it. I spec'ed Oracle or PostgreSQL
for a project. Large tables with lots of concurrency\. They had an Oracle
support contract, but wanted to use FreeBSD. They didn't have a PostgreSQL
support contract, so I had to use MySQL.

MySQL just tanked on the project. Even on my little projects, I try to use
MySQL to offer "completeness,": and it just doesn't work.


-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.







BLU is a member of BostonUserGroups
BLU is a member of BostonUserGroups
We also thank MIT for the use of their facilities.

Valid HTML 4.01! Valid CSS!



Boston Linux & Unix / webmaster@blu.org