shells and bells

[niall at kst.com (Niall Kavanagh)]

> 
> Let me go out on a limb here: this operating paradigm is borderline
> insane, like saying that cars would be faster without brakes.  In a sense
> this is true, but it is making a virtue out of a defect, which is greatly
> disingenuous.  The problem is that, since MySQL has no notion of a
> transactional queue, there is no way for EACH updater to do these pseudo
> transactions.  Each updater who wants to modify the database must assert a
> read lock against the whole table, and possibly against multiple tables,
> effectively shutting down the whole database.  What this paragraph above
> says is that ANY updater can stop ALL OTHER updaters from having their
> changes committed, but that leads to an undefined situation.
>

I once met a person who always spoke in absolutes, because he got more
attention that way.

It is nothing like a car without brakes. Mysql makes sure what you put in
is what you get out, it's up to the developer to track what should or
should not be there. You can do this quite easily. The tradeoff is a
little more coding for a lot more speed.

> 
> > YMMV. I for one am very pleased with mysql.
> 
> This is because it is a big index card server, not a real database, but it
> works pefectly well if what you need is an index card server.
>

That statement is so well backed up my only possible response is : "Is
not!". It's also quite ridiculous.
 
> Transaction support has nothing to do with data getting screwed up.  
> Rather, it has to do with who makes the decisions about the real-world
> significance and correspondence of the data.  The client is the side which
> imparts human meaning to the data, and it is where the locus of decision
> significance should reside.  If a telephone clerk is running an order
> entry system and the customer changes their mind, this should not require
> a database operation beyond a simple rollback to cancel the order.  At the
> same time, the order entry system should not allow two different clerks to
> decrement the same inventory item by selling it to two differnt customers,
> at least not without them knowing about it.  In fact, row-level locking
> and transaction support are part of any basic database system which
> involves concurrent updates by different arbitrarily sequenced parties.
>

There's no simple "rollback" in mysql, but there are analagous methods.
 
> 
> I suppose this may be the case, but there are probably a wide selection of
> sexual positions which one could reasonably infer would not be much fun
> without actually trying them out, such as hanging by a rope and dangling
> several hundred feet above asphalt pavement with a TV news crew below.
> 

More absolutes. Who would do that?  

My original point: Try them and select the one that suits you
Not every solution needs transaction support. Many can and would benefit
more from the added speed gained by not having it.
By the same token, if I had to design a storefront tomorrow, I would use a
database with transaction support   (like oracle).
Pick which one suits you. And for crying out loud stop telling people
mysql is a card file.

--
Niall Kavanagh, niall at kst.com
News, articles, and resources for web professionals and developers:
http://www.kst.com

-
Subcription/unsubscription/info requests: send e-mail with
"subscribe", "unsubscribe", or "info" on the first line of the
message body to discuss-request at blu.org (Subject line is ignored).