object databases
in [OOP]
|
From: frebe73 on 6 Nov 2006 04:07 > 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 t
From: carl.rosenberger on 6 Nov 2006 07:53 Sasa wrote: > 1) When would you recommend ODBMS, and when RDBMS? Object databases work great when: - you work truely object-oriented, modelling the world with classes, when you really use object-oriented features of your programming language - class hierarchies become more complex - ressources are sparse on your system and you do not want to spend them for an O-R mapping layer or when you do not want to slow the system down with an O-R mapper - your class model is subject to change and you want the database to adopt as quickly as possible Relational databases are the better choice if: - you already have an enterprise database system that you have to stay compatible with - you are going to do a lot of ad-hoc reporting in ways that you do not want to encode into your class model > 2) Which ODBMS would you recommend? A shameless plug: Ours. -- Carl Rosenberger db4objects Inc. http://www.db4o.com
From: carl.rosenberger on 6 Nov 2006 07:57 frebe73(a)gmail.com wrote: > Objects has many benefits, but they should not be overused. When making statements like this one, you should consider where you are. This is comp.object. This is a thread about object databases. -- Carl Rosenberger db4objects Inc. http://www.db4o.com
From: topmind on 6 Nov 2006 11:58 carl.rosenberger(a)gmail.com wrote: > frebe73(a)gmail.com wrote: > > Objects has many benefits, but they should not be overused. > > When making statements like this one, you should consider where > you are. Since there is no comp.object.criticism, THIS is where the criticism goes too. As far as not "compiling" SQL, I generally believe in dynamic languages anyhow. There may be static query language techniques, but I don't really follow them due to lack of interest in strong/compiled typing. Smalltalk fans complain about Java's typing-focus also. OO and strong typing are generally orthogonal issues. > > This is comp.object. > This is a thread about object databases. > > -- > Carl Rosenberger > db4objects Inc. > http://www.db4o.com oop.ismad.com -T-
From: Frans Bouma on 7 Nov 2006 05:15
frebe73(a)gmail.com wrote: > > 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. that's not what I meant. I'm sure SQLJ can check the syntactical errors in a sql statement. What I meant was the validity of a syntactical correct sql statement, i.e.: names of tabels are wrong, a value is passed in of the wrong type etc. > > 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. OK > > 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? sql syntax checking is something else than checking names etc. I couldn't find info about that but if you say so, let it be so. The thing that's still there is that you are writing hardcoded sql strings and doing the impedance mismatch solving YOURSELF instead of a piece of code which is in general more suitable for these kind of things. > > > > *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. argg... You write it in the right order at time T. What's the right order? well, a topologically sorted DAG and then executed from start to finish. Now something changes. Where to change your list of sql statements so the code works OK? I don't have to think about that. You have to. And when the # of elements to save gets bigger and the graph gets more levels, the problem gets much more complex than you'd like. Sure, if you want to spend time on that and doing all the sql yourself, why not? Others find that a waste of time and write normal OO code and let software figure it out. The funny thing is: with that they don't make mistakes either, while you run the risk of violating an FK constraint at RUNTIME. You really must like these runtime errors. > > 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. erm... the whole purpose of OO is using object graphs, because DUE TO the objects you CAN. > > 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. pointer hell? Where? The relational model is based on set theory and has nothing to do with pointers or OO as the relational model is based on math, not on some imperative implementational syntaxis of a 3GL. FB -- ------------------------------------------------------------------------ Lead developer of LLBLGen Pro, the productive O/R mapper for .NET LLBLGen Pro website: http://www.llblgen.com My .NET blog: http://weblogs.asp.net/fbouma Microsoft MVP (C#) ------------------------------------------------------------------------ |