Re: object databases
- From: frebe73@xxxxxxxxx
- Date: 6 Nov 2006 01:07:30 -0800
You should be aware that 'embedded SQL' is an ambigious term so
mentioning it and then assuming everyone understands what you meant is
not going to work. No I never heard of SQLJ as I don't program in Java.
Most people with some experince from enterprise applications in the
pre-OO era has encountered different embedded SQL products.
It's interesting, though still I doubt it checks at compile time of
your application that your queries are correctly matching the target db.
SQLJ checks your SQL statements against the db. If you write an invalid
SQL statement, you get a compilation error.
The problem is that you then have to have access to the db schema
meta-data when you write the SQL code. I don't know about you, but you
do have that all the time when you compile your code?
The compile time check is not mandatory. You can turn it of, if you by
some reason don't have the database availible. But normally the
database is availible, because otherwise I would not be able test the
application anyway.
SQLJ's code is parsed and emitted again as Java bytecode which calls
into a runtime, that's fine. What's odd though is that you seem to
think that that suddenly brings typesafety to the table.
The SQL statements are checked at compile time.
your SQL strings embedded into preprocessor constructs don't
necessarily bring typesafety as it's not guaranteed the SQLJ
preprocessor will throw an error when a name mismatch is found with a
table/field name in the actual db schema meta-data.
It does.
Because, to do that, the SQLJ preprocessor has to check the specified
queries with the live db schema meta-data so missing names/wrong names
and other stuff, like oh.. value type checks? are found at compile time.
It does.
I do think and know what embedded sql means, I didn't know what SQLJ
was, now I know and I still don't see where the type safety comes from
nor a lot of other things you ignore completely.
Obviously you don't have any experience from other embedded SQL
products but SQLJ either. They have been sucessfully used for decades.
They brings compile-time checking and type safety. What do I ignore?
*sigh*. Show me your code in Java or C#. that's the point.
Wrap every line inside #sql { } and you have the Java code.
and it's executed in the right order?
Why do you want to write your code in the wrong order, and then need a
tools to put it in the right order? Write the code in the correct order
in the first place.
This is comp.object, we talk about objects, so we're working with
objects. Working with objects is different from working with relational
databases and FK constraints which have a direction.
Objects has many benefits, but they should not be overused. Classes can
be used for defining data types. It should not be used for creating
pointer-based network graphs.
I do not suggest using objects graphs. The GUI tier is allowed to call
SQL statements too. You just introduce imaginary problems that
wouldn't been there if you did it right in the first place.
No object graphs? So you use an object oriented language, yet you
refuse to use objects contained in collections inside other objects?
The relational model is better suited for defining data structures than
the network model you like to use. The battle was won already in the
early 80's. Objects are useful for representing atomic values according
to 1NF.
Because for what reason do you want to refuse them? Because they
otherwise will introduce 'imaginairy' problems?
Because the relational model was invented just because avoiding the
pointer hell in the network model. I can not give you the full
backgrund here, but I suggest some reading about the network model.
When I say SQL based solution, I refer to using the SQL language. I
have showed that by using the SQL language, you will get a less
verbose solution without adding the complexity of a O/R mapper. A O/R
mapper isn't userful nor necessary.
ah, it's not useful. Well, then I let you alone with the real problems
and utilize the full power of single object graphs and the real type
safety of non-checked strings in preprocessor constructs.
I don't use object graphs, embedded SQL is type safe and has compile
checking.
your code is compiletime checked?
Yes. Try to learn something about SQLJ or any other embedded SQL
products.
You do know what 'compile time checked' means, I hope? A name
error/typo, value type mismatch etc, are these caught by the SQLJ
preprocessor? If so, how? as the sqlj preprocessor generates java
bytecode with calls to a runtime...
A name error will be caught at compile-time.
Your embedded sql strings are compile time checked?
I do not suggest writing sql as strings. SQL is a language equal or
even more high level than Java. It is not a good idea for one language
to host another as strings. Different languages can be mixed in the
same source file and can be compiled.
storing a string as a preprocessor construct is still a string. What
the topic was was type safety. Type safety suggests that when a typo is
made or an error because types don't match is made, these are found at
compiletime. If you say, SQLJ is typesafe, it therefore means that if I
make a typo in a name or try to store a string into a NUMBER column it
is detected by the SQLJ preprocessor at compiletime. Well, is it?
Yes.
You also forget that the new generation languages like Ruby, Python,
etc are all script languages without any compile time check. You seem
to be very eager about compilation. I suppose you never use any
dymaically typed language?
why would I want to live with stupid issues which pop up at runtime
while I could have found out at compile time? Ever done asp pages?
Yes. A lot.
Compile time detectable errors are key for a maintainable system: the
security you have that because the compiler says 0 errors, assures you
you won't run into type mismatches at runtime, silly things you could
have figured out at compile time.
I guess the popularity of dynamic languages are based on the fact that
the advantages are larger than this disadvantage. After all, there are
a lot of opportunites to get runtime errors in Java too.
SQL is also my OWN CODE. When I need data I get the data using a
select statement. When I need to update data, I call an update
statement. Persistence is handled on a much lower level inside the
database. You creates this problem by creating domain objects that
needs to be synchronized with the database.
Yes, because after all, I'm using an OO language, so why do I have to
do the impedance mismatch solving myself by writing out the queries
hardcoded in sql, embedded or not? That's the whole point.
If you let your database schema be your domain model, you don't have
any impedance mismatch to handle.
Fredrik Bertilsson
http://frebe.php0h.com
.
- Follow-Ups:
- Re: object databases
- From: carl . rosenberger
- Re: object databases
- References:
- object databases
- From: Sasa
- Re: object databases
- From: aloha.kakuikanu
- Re: object databases
- From: aloha.kakuikanu
- Re: object databases
- From: frebe73
- Re: object databases
- From: frebe73
- object databases
- Prev by Date: Re: Relational database & OO
- Next by Date: Re: object databases
- Previous by thread: Re: object databases
- Next by thread: Re: object databases
- Index(es):
Relevant Pages
|
