Re: Transactions: good or bad?

> Pointers? This is not clear yet.
>
> Anyway I think you are confusing transactions with data models. Don't.

>
> And the state-of-the-art is not transactions, but database assignment.
> So don't loose your time beating a dead horse.
>
> Your are messing relational with SQL. SQL is not relational, and has
> never been. Relational were QUEL, BS12, and now are Opus, Duro, Dataphor
> and perhaps LEAP.

It's relational enough for the marketplace. You know, the people that actually pay the bills.

> You are messing testing with proving. Test cases aren't formal proofs.
> I hope I don't have to use software coded by you for reliability.

And what is a formal proof but test cases based on internal consistency? Oh, if I have these conditions, then, it follows xyz, take them all together, and therefor, it is proven. Mathematics is a language. C# is another. You can write a mathematical system in C# just as easily as you could write C# in math. There is no hiearchy of languages. Turing PROVED they are all the same.

> Most customers don't understand what relational is all about. Most
> customers can't define what's relational any more than they can define
> what Mathematics is.

Well then, what good is it?

> So why the effort of misbranding your wares?

I'm not. I'm describing features in a way most customers will understand.

> You could be clearer, but since you are confusing relational with SQL it
> probably doesn't matter anyway.

Feature: better performance bounds for the given environment

Feature: a language easier to use for commodities

Look, if whatever there is to relational databases that SQL doesn't have was so incredibly useful, then, don't you think IBM, Oracle, or Microsoft might have been able to implement or sell them?

What is one feature a purely relational database has, that a SQL Server or an Oracle does not?

> Spammer.

Intellectually dishonest. Received on Mon Jun 09 2003 - 05:35:55 CEST