| Subject | Re: [Firebird-Architect] MVCC + a day in life the mysql instructor |
|---|---|
| Author | Jim Starkey |
| Post date | 2009-03-13T18:34:39Z |
marius adrian popa wrote:
concurrency control is actually record locking. Reading transactions,
however, dig through their transaction log to find the old versions.
This is not to say that it's a slouch, however. And, with Falcon
nipping at their heels, they've gotten about three times faster.
triggers and competitive instinct motivated inspiration. As it turned
out, my implementation cascaded and Sybase's didn't, but we beat them to
market anyway.
Views were there from the very beginning as were transactions.
There are number of common problems with other trigger implementations:
* SQL standard triggers suck intelligence from the universe.
* Not all triggers cascade, making them useless
* Some types of operations don't first triggers, reducing their utility
Interbase/Firebird doesn't have any of these (at least not the last time
I looked).
--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376
> Seems that Jim Starkey had an touch in Mysql now all the mysql storageInnoDB isn't actually MVCC except for marketing purposes. The
> engines will have MVCC and transactions :)
> And engines don't compete with each other : Maria vs Falcon vs Oracle
> (aka InnoDB) vs PBXT
> Ahh i din't included drizzle or Maria++
>
> http://code.openark.org/blog/mysql/tales-of-the-trade-1-a-day-in-the-life-of-a-mysql-instructor
>
concurrency control is actually record locking. Reading transactions,
however, dig through their transaction log to find the old versions.
This is not to say that it's a slouch, however. And, with Falcon
nipping at their heels, they've gotten about three times faster.
>Triggers showed up during 1.0 beta. I heard a rumor that Sybase was
> I'm just learning some c++ by writing an Firebird engine for mysql
> until now it opened some eyes on the mysql engine internals and how
> some consultants do some profits on it
> also i cursed the autotools , it always reminds me of sendmail maybe
> because of the m4 ...
> The other day some book recommends (weird sybase consultant) to avoid
> Triggers ,
> I don't know for me in interbase/firebird seems natural to use them
> and i didn't have any issues with them
> I fact i can't imagine life without triggers or views or transactions.
> Anyone knows when they were introduced in interbase?
> It's weird to not trust your RDBMS and to start implementing
> workarounds in php/c or python
>
>
>
triggers and competitive instinct motivated inspiration. As it turned
out, my implementation cascaded and Sybase's didn't, but we beat them to
market anyway.
Views were there from the very beginning as were transactions.
There are number of common problems with other trigger implementations:
* SQL standard triggers suck intelligence from the universe.
* Not all triggers cascade, making them useless
* Some types of operations don't first triggers, reducing their utility
Interbase/Firebird doesn't have any of these (at least not the last time
I looked).
--
Jim Starkey
President, NimbusDB, Inc.
978 526-1376