Re: Unknown SQL

>> >> So, you claim it is easier to force the user to know about Arrays,
 Sets,
>> >> Bags, Collections, Iterators, Children, Parents etc. than it is to
 force
 the
>> >> user to know about Relations, Tuples and Domains?
>> >
>> >All of the above constructs are part of the Java programming language.
>>
>> So, your concept of a DBMS limits the user community to a very select
 group
>> of highly trained programmers?
>
>An interesting rhetorical attempt. :-)

What is the rhetoric? Your product limits its use to people who know Java. In order to use your product, one must learn Java. If one must learn a language to use a product, one will learn a simpler language faster. As you correctly point out, the more redundant "concepts" one has to learn, the greater the effort.

>Should I post a website link, that uses our database as a backend?

Who cares? We already know that Java programmers can build websites.

>> >We
>> >neither force the user to know about them, nor to use them.
>>
>> So, as long as your force all of your users to first learn Java, you are
 off
>> the hook?
>
>Your argumentation is like:
>"You need to understand C to work with your newsreader, since it is
>programmed in C."

Nope. My argument is you need to understand C to write C programs. You need to understand Java to write Java programs. You need to know the DBMS data model to query the data. Teaching a user about a single concept, call it relation or table or whatever, is easier than teaching users the differences between Array, Set, Bag and Collection.

>If you develop something with relational databases, what will users get to
>see?

The users of the relational DBMS will get to see the RDBMS. My application is one of those users, as I am too.

>The database vendors SQL-console or your program?

Both. Users of the DBMS will see the DBMS, whatever its interface. SQL or otherwise. Users of my program will see my program. Some individuals will use one product or the other exclusively. Other individuals will use both.

>> >If a programmer uses any of these JDK classes, we store them directly,
>> >without any detours through relational mappers to tables, which would be
>> >unsuitable.
>>
>> Of course such a wrapper would be unsuitable. Classes map to Domains and
 not
>> to Tables. Duh!
>
>What do Domains map to?

Data types.

>Relational databases map classes to tables

No, they don't. The statement is simply untrue. Relational databases map classes to domains. As I mentioned before, if you took any time to educate yourself, you would already know this.

>no matter how many unnecessary
>in-between layers you invent.

Since the supporting premise is untrue, the rest is meaningless.

>> >Can you program a parser with it, a text editor or a web-browser?
>>
>> Why on earth would anyone want to program a text editor with a DBMS? It
 is
>> an inappropriate use of the tool. Can you program a text editor solely
 with
>> your product? Or does one need to use a programming language, such as
 Java,
>> as well?
>
>I am only pointing out that one paradigm is given:
>The programming language.

There goes the bullshit antennae again.

The programming language is never a given. The DBMS must support all applications regardless of the programming language. That's its role.

>Lets take Java as a starting point.

Let's not.

>The programming language Java uses objects to represent data.

When you say objects, do you mean object classes or object instances? I always thought object orientation was about encapsulating and abstracting data. All along I thought object orientation was about hiding representation, and now you tell me it is about exposing representation. I find that difficult to believe.

>Now I wan't to store some of them.

You want to store some of what? The representations? If an object instance has multiple possible representations, which one do you want to store?

>Ideally I do not want to worry about what happens to my inheritance
>hierarchies, arrays and hashtables.

Well, as a programmer, I would certainly want to know what happens to my inheritance hierarchies. I certainly would not want them to change without my knowing!

I certainly would not want my array to turn into a hashtable just because some other application prefers to deal with the same data that way!

>The more work the database engine does
>for me here, the more productive I can be.

Huh? Inheritance hierarchies, arrays and hash tables are physical limitations imposed by the programming language. The more physical limitations the DBMS imposes on the data, the less productive you can be!

Regards,
Bob Received on Sun Jul 22 2001 - 01:28:46 CEST