[sclug] Re: sclug Digest, Vol 20, Issue 16

[Graham Swallow]

> If I want a database I want a DATABASE.
> mysql is NOT a real database. All the old arguments still hold true.
> And the 'features' you speak of aren't 'bonus add ons' but a necessity 
> when working with anything when you value your data.
> 
> I invite you to read the bits regarding ACID in this link, which 
> although outdated is STILL relevant to mysql.
> 
> http://openacs.org/philosophy/why-not-mysql.html

	The full feature list may make a difference (stored procedures are available,
	as are clusters, repeaters, and replayable, editable, transaction logs,
	which are necessary when you value your data). A lot comes from PHP/C++,
	but this it boils down to the lines between atomic and consistent.

	Somewhere in the big MySql html page manual, it clearly says that you
	get fast atomic updates, but a single grain of sand, not multiple things
	put together in a transaction (consistency), and that you should design your
	app to do such grouping. Conversely, a DBMS that does provide transaction
	grouping, not-yet-visible updates, long-lived-locks, etc, might give a false sense
	of security. EG: (examples are always contrived)

		you app is adding a branch to a tree of things (?web pages?),
		but a second user must not see the branch, before the twigs exist,
		and the leaves are in place (broken links, consistency).

		(1) accept a small risk (low probability and low cost)

		(2) create all of branch THEN add it to parents list (list is sorted table view)

		(3) group all of branch into a transaction

	EG2:
		Now suppose that it was a branch with a key name.
		With transactions, you must cater for a second user
		attempting to create a different branch with the same name
		(this app is getting wierd). So you try to break that aspect out
		of the main transaction, so that the second user sees it.

		With a full DBMS you have to think of the 'mid-way' case
		(before-during-after). With MySQL, you can see a sequence
		of steps as your 'mid-way' situation.

		With both, (in a different system), you still have to build queues of
		actions that ripple outwards. EG one transaction update causes
		a letter to be printed and posted, so you defer that in a queue
		(which can be cancelled in a rollback, or merged with an adjusting
		transaction, one letter for all todays actions).

	Half of the ACID responsibility is in the application design + code.

--
   Graham
   gps @ Information-Cascade .co.uk
   www . Information-Cascade .co.uk
-- 
   regards
--
   Graham
   0118 975 6229
   gps @ Information-Cascade .co.uk
   www . Information-Cascade .co.uk