Re: Unknown SQL

From: Carl Rosenberger <carl_at_db4o.com>
Date: Sat, 21 Jul 2001 18:01:33 GMT
Message-ID: <9cud3i$m8o$03$1_at_news.t-online.com>


Todd Gillespie wrote:
> : Typically we do program with objects, though. Every additional "fashion"
 or
> : flavour of thinking complicates our business.
>
> I generally asked cow-orkers:
>
> "Are you programmers, constrained to a language, or engineers, who are
> capable of using many tools to solve a computing problem?"

What are you more effective with?
- a language that you have been working with for 5 years, knowing all the bugs and special tricks?
- a language that you use for the first time? There always is a first time.

> Look at your business card - does it say "Java Programmer" or "Hacker"?

I would take "Java Programmer" as an insult and "Hacker" as a compliment.

> I would also call foul on your assertion that additional methods
> complicates your business.

They sure do, if they are not necessary.

> I believe the other poster said "don't use a
> hammer on screws"; and with only 1 approach you must be using hammers on
> just about everything, ne?

I am very sure that I did not post a statement like "SQL is unnecessary".

The problem is:
Since human ressources are very scarce, we get people writing programs that aren't even "Java Programmers".

I have seen the development of complex SQL frameworks by people with no idea about all the flavours of multi-user-problems that can arise.

The locking- and isolation-level-behaviour of some very well reputed "industry standard" databases lets me question, if even the development of those base-technology products is done by "C programmers" or "Hackers": - Microsoft Access (some people say, you can't call it a database) has some very nice concurrency bugs.
- Using Oracle in "serializable" isolation level, you are bound to get bombed out with exceptions.
- SAP likes to use pessimistic locking for documents. If someone gos for a lunch break after starting to edit, the rest of the company can wait for his return, to regain modification access for locked records.

I have come across quite a few locking problems in the past, where a "record-by-record" modification of data was more effective than a single UPDATE statement, because the statement failed in 99% of the time due to locked records.

"Using a hammer on screws" for sure is the wrong way. The IT industry is exactly doing that by using SQL for objects. Looking at the posting traffic in comp.lang.java.databases, I get the idea that very few people know at all, that there are alternatives.

Kind regards,
Carl

---
Carl Rosenberger
db4o - database for objects - http://www.db4o.com
Received on Sat Jul 21 2001 - 20:01:33 CEST

Original text of this message