> -----Original Message-----
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED]]On Behalf Of Peter
> Routtier-Wone
> Sent: 28 March 2001 11:59
> To: JBoss
> Subject: Re: [JBoss-user] BMP entity beans and MS SQL Server 7 ??
>
>
> > Interbase is cheaper and it's open source. That's all.
>
> No, it isn't all. It's far from all.
>
> To avoid tying oneself to a proprietary platform such as Oracle
> or Microsoft
> SQL Server or any other database server one must contain oneself to core
> ANSI SQL such as can be relied on to function consistently across all
> platforms. In an environment like EJB, particularly an implementation of
> same as capable as JBoss, this is no real catastrophe.
By your criteria - i.e. a need to function consistently across all [or at
least multiple database] platforms - Interbase is just another proprietary
DB platform. "Open Source" does not equal "not proprietary" when we are
talking about SQL dialects.
> However, what it means is that one ends up using the DB server as little
> more than a glorified ISAM engine that performs caching and
> returns packaged
> result sets. In this context there are profound and self-evident
> advantages
> to using a free, open source DB server.
I agree. If all you want is a glorified ISAM library, no point in paying top
$$ for it. And the source would be great too.
> If one throws caution to the wind and uses the specific
> capabilities of the
> DB server then I think that Interbase is still a better answer
> than MS SQL.
> For starters, it supports functions, which MS SQL does not. It is a
> versioning database, which makes it completely invulnerable to
> the problems
> of locking (no locks, no locking problems). And most important from a Java
> programmer's point of view, there is a *superb* JDBC2 implementation for
> Interbase available at no charge.
Concurrency control by versioning .vs. locking is trade-off. We make many of
those developers when we build systems. Locking offers higher performance,
using less resources but is constrained by the number of concurrent access
[may not be the same as number of users] whilst versioning removes the limit
on the number of concurrent accesses but at the cost of needing much more
resources [mainly memory/disk] and poorer performance than locking-based
schemes [below their concurrent access limit].
For a great many [well-designed] applications, the concurrent access limit
of locking engines may be _effectively_ ignored. For those applications
where it is an issue, usually high transaction OLTP environments, versioning
has failed to deliver significant benefits hence the predominance of
locking-based engines.
I don't question your preference for Interbase, it is a solid RDBMS. That it
is free and open source is a great asset too. And yes the free JBDC driver
is a definitive advantage compared to MS SQL Server. Nevertheless, if the
cost wasn't an issue (and even if it was since I use SQL Server), I'd choose
MS SQL Server. It is much slicker, well supported and I found it to be
faster - perhaps my tests favoured a locking engine given the generally low
level of concurrent access to any single entity in the database - than
Interbase.
Still, I don't have access to the source code for MS SQL Server and I doubt
I ever will :-(
>
> Versioning and locking are two technologies that address the same problem:
> ensuring the serialisablity of transactions.
They both address the problem of maintaining consistency & data integrity
when the data is being accessed concurrently (by multiple processes).
Transactions are always serializable. The challenge is to allow concurrent
transaction as this results in better performance.
> Locking is fast and efficient
> for limited numbers of users. It is popular with DB vendors chasing very
> high TPc scores because it is very well suited to OLTP, but it is
> completely
> unsuitable if you want to run OLTP and OLAP operations on the
> same database.
If you *needed* to do OLTP and OLAP on the same DB, then perhaps a
versioning engine offers some benefits [I don't know as I haven't *needed*
to do so]. OLAP operations by and large are long running, complex, queries
that tend not to need access to the absolutely latest data. In this case
database replicas or even datawarehouses offer much better models as they
utilize separate OLTP and OLAP databases.
> Versioning has none of these problems. For small numbers of users it
> produces poorer performance due to higher overheads, but as it suffers not
> at all from lock contention its performance degrades linearly with the
> number of users (therefore limited by memory), rather than degrading
> exponentially with lock contention.
>
> This is not to suggest that Interbase is perfect. It has many
> flaws, most of
> which are compensated by an amusing pragmatism: we can't keep the server
> from crashing, so let's design it to quickly auto-recover. Very
> biological.
> And while I'm being honest about the faults of Interbase, I have to admit
> that under Unix its memory management was appalling in version 4, bad in
> version 5 and as yet untested in version 6.
Don't get me started on the list of SQL Server flaws Peter....I might be
here for a while then ;-)
> I may not have bothered to substantiate them the first time around, but my
> opinions of Interbase and MS SQL are founded on ten years of professional
> experience doing back-end work for large corporations using these two
> engines. I think by now I may have learnt just a few things.
Bottom line is that both databases have something to offer [as do many
others]. It is prudent to be open-minded about all the options. That's what
my reply was about. If you need Open Source, strike off MS SQL Server, If
you need free, once again MS SQL Server is not your friend. If you need a
good db engine regardless then put it on your list and try it out along with
the other competing db engines.
Cheers!,
Micheal
_______________________________________________
JBoss-user mailing list
[EMAIL PROTECTED]
http://lists.sourceforge.net/lists/listinfo/jboss-user
