Re: Is Interbase still thriving?

Eric Grange wrote:
If your developers had only Oracle experience, I am sure it is to be expected. I saw it myself too often to forget. 


Actually we started on InterBase, when faced with MSSQL and wether to adapt
to it or not, the choice was a little like when deciding if we should
dumb down our Delphi code to have it run on TP3... Obvious decision was to
wait and let MS updated its DB to more modern techology.
Actually, your team would be learning good pratices about query writing. Which are independent of the RDBMS adopted.
In Oracle/IB/Progress you have much less contention problems derived from bad writen queries, and that is a GOOD thing. But those bad written queries does damage the performance of your app, in terms of Physical IOs.
I maintain what I said earlier, in my experience, the vast majority of contentions problems I faced was due to EXTREMELY bad written code.

That they're still using such an outdated transaction approach speaks more
about them being stuck into old technologies... and having a lot of money
to waste on developping workarounds for old tech ^_^
Maybe it speaks about they having a lot of money to teach their developers and to hire good ones? <g>
Those companies are starting new projects every month, is a bit funny that with all that money in their hands they still starts new projects in those "1-user" databases.

Standard OLTP and DSS, sometimes mixed. Of course all the model was pretty normalized, nothing diferent from what you would expect in an Oracle DB. 
In an Oracle (or Interbase) DB, much of these transfers and clean up work
is unnecessary since you can directly write the data where it belongs,
without preventing reads, and you can maintain 100% coherent data at all
times (at the DB level, not just the row or table level).
Where did I mention ANY "transfer" or "clean up work"? I insist, I never needed to "write on one place and the read from the other". The systems I was involved always where modelled as you would model in Oracle. It is simple as that.

With those RDBMS, the problem isn´t in your Model, is with your transactions. It´s very important that you design your transactions to be small, short-lived. Do this and you won´t have contention problems.
What you're saying here is not very different from saying "you have to write
ASM routines wherever it matters" to a regular Delphi user.
Nope. Maybe a comparison with thread programming would apply better, like when you have to change a global variable, I suppose I should lock it for as little as possible? Excuse me, but I did very little thread programming, so maybe I am incorrect here.

This kind of thing is irrelevant pretty much all the time on a modern DB.
Not at all. You still have lock contention, like 2 process trying to write at the same time. You still have to manage the redo logs, you still have more time that the readers will read "old snapshots" from data, etc. Long-running transactions are symptoms of bad written code, period.
Maybe that´s why you need a 64-bit Delphi? You really need to speed up those transactions <g>

But in most of the real-world, is pretty rare when you HAVE TO do a very long transaction, except on batch jobs (when you don´t have big concurrency problems).
Doesn't take a very long transaction, if you transaction lasts, what 20 ms,
then 50 users writing data would be enough to prevent reads for a second
on your lock-based DB engines.
50 users writing to the same ROW of data!! That´s a pretty rare number to me.

Should some hiccup out of your control occur
(network connexion lost, computer crash, whatever), then the lock could
last a very long time.
This NEVER happened on the systems I was involved. All the RDBMS I worked with identified the situation and quickly released all resources.

Also, long-running transactions can impact Oracle too, google for "Snapshot too old" and you will see what I mean. 
This is taking it to the other extreme.
Transactions issues with MSSQL are become visible in the seconds timeframe,
be those seconds come from a single transaction, or many shorter ones.
On your systems perhaps, none of the systems that I saw being well administered and monitored.


I expect that Sybase and MS-SQL performs better here. Cache and locking comes to play here more than transactions. And the Oracle model is more complex than the model implemented from those vendors.
Yet in practice, that won't be the case. The model is more complex, but so
much more efficient in practice it may not even be funny. AFAIK the DB you cite proceed on the lock-update-unlock paradigm, resulting in an awful lot of
locking-unlocking.
Those 2 paradigms are valid, that´s my point. You have benchmarks, you have previous real-world experience, showing that ORACLE isn´t faster than MS-SQL or Sybase ON THE SAME MACHINE (contention included).

And MS kinda agrees with that since they're taking MSSQL in that direction AFAIK.
It´s good to have the option, but IMO, this move is more focused in making easier the migrations from Oracle->MS-SQL (making an app done with focus in Oracle behave well in an MS environment) than for performance benefits.

Well, I really enjoyed this discussion, but I don´t have the desire to make you change your mind. I just wanted to clarify some misinformation on the SQL-Server (and Sybase and DB2) scalability (the "1 user database"). Obviously you will find HUNDREDS of systems who use SQL-Server with many users and very good performance (e.g. Starteam).
I like Oracle, it is a awesome DB and deserve the reputation it got, but they do have some SERIOUS and COMPETENT concorrents. And I am not talking about Postgress here. <g>

  Leonardo Pasta
.

Relevant Pages

  • Re: AutoCommit - Oracle.
    ... > and invoked the stored procedures, the user would not have to worry about ... Oracle never autocommits. ... are only internal should not be used to control transactions. ...
    (microsoft.public.dotnet.framework.adonet)
  • HP tops 1 million tpmC on Superdome with Itanium2 CPUs
    ... HP and Oracle Set World Record Performance Mark -- First to Top 1 ... Million Transactions per Minute ... Superdome server and IntelŪ ItaniumŪ 2 processors. ...
    (comp.os.vms)
  • Re: Oracle
    ... Microsoft Oracle .NET Managed provider or Oracle Data ... Does anyone know if I can use promotable transactions ... technology provided by the database vendor. ...
    (microsoft.public.dotnet.framework.adonet)
  • EMN0 process memory leak.
    ... We have an SR open with oracle ... ... before placing a message on persistent queue from where it ... is sent across a dblink into a destination queue on the Datamart. ... what will be the impact on any transactions? ...
    (comp.databases.oracle.server)