object databases
Sasa
might provide some suggestions, sorry if this is an OT:
So after years of using strictly relational databases, I've begun to
consider an alternative. Object databases seem compelling, especially
since the data in the project I'm mostly involved in is highly
hierarchical. So the questions:
1) When would you recommend ODBMS, and when RDBMS?
2) Which ODBMS would you recommend?
3) The application I work on is single user desktop application. The
data resides on the user's computer. Is there any ODBMS suitable for
this (something like equivalent to MSDE, Access, etc.). Is there any
"lightweight" object database suitable for this, or would you recommend
something else instead?
Thanks,
Sasa
Frans Bouma
> I posted this to comp.databases, but then it came to me that you guys
> might provide some suggestions, sorry if this is an OT:
>
> So after years of using strictly relational databases, I've begun to
> consider an alternative. Object databases seem compelling, especially
> since the data in the project I'm mostly involved in is highly
> hierarchical. So the questions:
> 1) When would you recommend ODBMS, and when RDBMS?
Object databases are good in serving/handling objects, or better:
instances of entities which are pre-defined. Examples are Customer,
Order, Product etc.
Relational databases are good in serving sets and set operations on
sets of attributes, grouped together in entities.
The core difference can be seen with a simple example. Say you want a
list of orders and also the CompanyName of the customer which has
ordered the order.
In a relational database, you'll have an easy job, as the resultset is
a simple selectlist (a new entity!) defined on the joined set of
attributes from the entity order and the entity customer, in layman
terms: a select statement with a join.
In an object database, this is harder to do. The thing is: the
resultset should be an object. However, the object isn't defined, as
the objects known are Customer and Order, but not OrderWithCompanyName.
So if you work a lot with these sets, you'll likely be better of with
a relational database. If you're working a lot with sets of entity
instances which are pre-defined, you're better of with an OODB.
> 2) Which ODBMS would you recommend?
I've heard good things about db4o, however the market for oodb's is
small, so there are a few players. I wouldn't go for versant's, it's
very expensive.
An alternative could be to use a relational database and an O/R
mapper.
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#)
------------------------------------------------------------------------
Nick Malik [Microsoft]
store your data relationally, but manipulate it as objects. In fact, some
of the OODBs got their start as O/R mapping tools sitting on top of a SQL
database.
--
--- Nick Malik [Microsoft]
MCSD, CFPS, Certified Scrummaster
http://blogs.msdn.com/nickmalik
Disclaimer: Opinions expressed in this forum are my own, and not
representative of my employer.
I do not answer questions on behalf of my employer. I'm just a
programmer helping programmers.
--
"Sasa" <sas...@gmail.com> wrote in message
news:ei9jui$4kr$1...@sunce.iskon.hr...
topmind
Have you thought about using the File System? File systems are more or
less hierarchical databases in their own right.
-T-
aloha.kakuikanu
Are you aware that object databases failed miserably to gain any
acceptance? Hmm, what the conclusion of this trivial fact might be? Use
relational database _always_?
There are numerous ignoramuses around (some with pretty loud names) who
would fight this obvious truth, but the fact of the matter is that you
as a computer developer professional just can't skip fundamentals of
data management class. And if you learn data fundamentals, then you
know why the concept of object database is a misnomer.
H. S. Lahman
> I posted this to comp.databases, but then it came to me that you guys
> might provide some suggestions, sorry if this is an OT:
>
> So after years of using strictly relational databases, I've begun to
> consider an alternative. Object databases seem compelling, especially
> since the data in the project I'm mostly involved in is highly
> hierarchical. So the questions:
Actually, an ODBMS is not inherently well suited to hierarical
relations. The OO paradigm is actually designed to eliminate them.
OTOH, one can map something like a tree in either one through
relationships. IOW, the Data Model looks the same for both:
0..* parent of
[Node] ---------------+
| 0..1 |
| child of | R1
| |
+------------------+
> 1) When would you recommend ODBMS, and when RDBMS?
If the relationships among tuples of data are complex and more naturally
expressed directly between tuples, then and ODBMS is a better choice.
For example, most road map applications use a ODBMS because every item
usually has a host of fixed relationships to other items of different
types AND the number of items involved in a specific relationship is
usually a tiny subset of all the items. Perhaps more important, one
always navigates the relationships in exactly the same way (i.e., the
relationships are defined tailored to the problem in hand). An ODBMS
will also usually be more efficient if you have a lot of navigation from
the 1-side of 1:* relationships (which is also common in road map
applications).
An RDBMS is better suited to situations where relationships between
tuples are fairly simple and the individual tuples are related in an
arbitrary manner. An RDBMS shines in processing ad hoc queries where
one cannot predict exactly what subsets of data will be accessed. For
an online airline reservation system one has a relatively few
relationships whose navigation can be optimized by a few indices in
order to access arbitrary tuples in simple joins.
Bottom line: an ODBMS works well when the data needs to be modeled for a
very specific purpose or one routinely needs very complex join.
Meanwhile an RDBMS works well when the data is accessed in an ad hoc
manner and joins are relatively simple.
> 2) Which ODBMS would you recommend?
Sorry, I've only used one (ObjectStore) and that was many moons ago so I
don't have comparative data.
> 3) The application I work on is single user desktop application. The
> data resides on the user's computer. Is there any ODBMS suitable for
> this (something like equivalent to MSDE, Access, etc.). Is there any
> "lightweight" object database suitable for this, or would you recommend
> something else instead?
If it is for a single application, that suggests that the data model can
be tailored to a particular problem solution, which /might/ make an
ODBMS a better choice. But it would still depend on how complex the
relationships were and the nature of the joins.
You can get ODBMSes for desktops, particularly the memory-mapped ones
like ObjectStore that directly support persistence in OO applications
fairly transparently. But they tend to be pricey. (An ODB engine,
particularly a memory-mapped one, is inherently more complex than an RDB
engine.)
Note that a memory-mapped ODBMS has a downside for its convenience in
managing persistence in an OO application. The application is littered
everywhere with infrastructure statements that are specific to the ODBMS
and that tends to marry one to a particular vendor. That is in contrast
to an RDBMS where one can encapsulate the access mechanisms like SQL in
a single client subsystem.
*************
There is nothing wrong with me that could
not be cured by a capful of Drano.
H. S. Lahman
h...@pathfindermda.com
Pathfinder Solutions
http://www.pathfindermda.com
blog: http://pathfinderpeople.blogs.com/hslahman
"Model-Based Translation: The Next Step in Agile Development". Email
in...@pathfindermda.com for your copy.
Pathfinder is hiring:
http://www.pathfindermda.com/about_us/careers_pos3.php.
(888)OOA-PATH
Frans Bouma
> Sasa wrote:
> > I posted this to comp.databases, but then it came to me that you
> > guys might provide some suggestions, sorry if this is an OT:
> >
> > So after years of using strictly relational databases, I've begun to
> > consider an alternative. Object databases seem compelling,
> > especially since the data in the project I'm mostly involved in is
> > highly hierarchical. So the questions:
> > 1) When would you recommend ODBMS, and when RDBMS?
> > 2) Which ODBMS would you recommend?
> > 3) The application I work on is single user desktop application. The
> > data resides on the user's computer. Is there any ODBMS suitable for
> > this (something like equivalent to MSDE, Access, etc.). Is there any
> > "lightweight" object database suitable for this, or would you
> > recommend something else instead?
>
> Are you aware that object databases failed miserably to gain any
> acceptance? Hmm, what the conclusion of this trivial fact might be?
> Use relational database always?
>
> There are numerous ignoramuses around (some with pretty loud names)
> who would fight this obvious truth, but the fact of the matter is
> that you as a computer developer professional just can't skip
> fundamentals of data management class. And if you learn data
> fundamentals, then you know why the concept of object database is a
> misnomer.
I don't see why the fact of not being widely accepted means that the
technique is THUS bad. It's a niche, and within the niche they function
very well.
Fact is, relational databases have drawbacks too, which aren't present
in OODB's. For example, working with objects in the code consuming the
database's data is more efficient if you use an OODB as you then don't
have to convert OO to relational and back. Of course, using an OODB has
drawbacks as I described in my post in this thread, but if you don't
run into them, which is often in a program which is targeting a niche
or has specialistic features, an OODB doesn't have to be a bad choice.
Frans Bouma
> Responding to Sasa...
>
> > I posted this to comp.databases, but then it came to me that you
> > guys might provide some suggestions, sorry if this is an OT:
> >
> > So after years of using strictly relational databases, I've begun
> > to consider an alternative. Object databases seem compelling,
> > especially since the data in the project I'm mostly involved in is
> > highly hierarchical. So the questions:
>
> Actually, an ODBMS is not inherently well suited to hierarical
> relations. The OO paradigm is actually designed to eliminate them.
> OTOH, one can map something like a tree in either one through
> relationships. IOW, the Data Model looks the same for both:
>
> 0..* parent of
> [Node] ---------------+
> | 0..1 |
> | child of | R1
> | |
> +------------------+
In relational databases, storing hierarchies is one of the things
which isn't very efficient, when you use the model you described. The
thing is that you can't use a single select statement to get a subset
of the hierarchy as SELECT isn't recursive and can't fetch adjacency
lists in one go, it's set based, and this is a nested set oriented
problem, so it can't be solved with a single select unless the
datamodel is adjusted to get the nested sets out in one set oriented
operation. So the model can't be the same.
So in relational databases, other solutions are preferred. One is what
I'd call the CELKO method:
http://groups.google.com/group/comp.databases.theory/msg/25acd5da2a3110e
7?dmode=source
Another one is to introduce a helper table with hierarchy information
which can be joined into the set to get a single hierarchy out of the
db.
OODB's aren't used with SQL, they're used with an OO language so they
don't run (necessarily) into this problem per se.
H. S. Lahman
>>Actually, an ODBMS is not inherently well suited to hierarical
>>relations. The OO paradigm is actually designed to eliminate them.
>>OTOH, one can map something like a tree in either one through
>>relationships. IOW, the Data Model looks the same for both:
>>
>> 0..* parent of
>>[Node] ---------------+
>> | 0..1 |
>> | child of | R1
>> | |
>> +------------------+
>
>
> In relational databases, storing hierarchies is one of the things
> which isn't very efficient, when you use the model you described. The
> thing is that you can't use a single select statement to get a subset
> of the hierarchy as SELECT isn't recursive and can't fetch adjacency
> lists in one go, it's set based, and this is a nested set oriented
> problem, so it can't be solved with a single select unless the
> datamodel is adjusted to get the nested sets out in one set oriented
> operation. So the model can't be the same.
My point was that the ODBMS has no particular benefit for hierarchical
structure over an RDB. Neither has any convenient mechanism for
"walking" the tree or extracting it in bulk and the developer needs to
tailor that explicitly.
AndyW
<aloha.k...@yahoo.com> wrote:
I would suggest that before making what see as 'glorified hail mary'
statements like that, you may like to try implementing a parts catalog
(with diagrams) in an OO database and an RDB first.
I will find it interesting to see how you handle the concept of parts
diagrams within parts diagrams (schema within schema) to the n-th
level.
I would also find it interesting to see how efficient a distributed
real time billing system would be for a large telco network that you
would implemented using an RDB - something that is considerably
difficult, even for a small telco only generating say 500 million call
data records per day.
Alvin Ryder
All the projects I've seen that used OODBMS suffered badly. They solved
their problems by switching to Oracle.
Not sure if that's worth anything to you but I wouldn't rush into it
and I certainly wouldn't believe what the "glossy brochures" say.
Cheers.
aloha.kakuikanu
> Fact is, relational databases have drawbacks too, which aren't present
> in OODB's. For example, working with objects in the code consuming the
> database's data is more efficient if you use an OODB as you then don't
> have to convert OO to relational and back.
Well, I never understood the so called "impedance mismatch" problem.
Calling SQL from say java code is one of the easiest tasks in mordern
programming. Getting results back is straightforward as well. What I
also never has been able to grasp is why would you discard this simple
idea lightly in favor of learning obscure 20 something mapping rules
(TopLink).
> Of course, using an OODB has
> drawbacks as I described in my post in this thread, but if you don't
> run into them, which is often in a program which is targeting a niche
> or has specialistic features, an OODB doesn't have to be a bad choice.
You have to tell what niche it is. Somebody mentioned bill of
materials, but are they really familiar with hierarchical query
facilities in SQL?
Frans Bouma
> Frans Bouma wrote:
> > Fact is, relational databases have drawbacks too, which aren't
> > present in OODB's. For example, working with objects in the code
> > consuming the database's data is more efficient if you use an OODB
> > as you then don't have to convert OO to relational and back.
>
> Well, I never understood the so called "impedance mismatch" problem.
> Calling SQL from say java code is one of the easiest tasks in mordern
> programming. Getting results back is straightforward as well. What I
> also never has been able to grasp is why would you discard this simple
> idea lightly in favor of learning obscure 20 something mapping rules
> (TopLink).
that's simple.
take the following small code snippet.
using(DataAccessAdapter adapter = new DataAccessAdapter())
{
adapter.SaveEntity(myCustomer);
}
this line of code saves:
- the Customer entity instance myCustomer
- its related Order entities
- its related order detail entities
- and other related entities to these.
all in the right order, it syncs pks with fk's, it pulls back the new
PK's from the db if the pk's are identity/sequenced, performs pre-/post
save validation etc. etc. etc.
effectively 2 lines of code.
Now, tell me, you can do all that with 2 lines of code with SQL
strings etc. ? No, you can't.
Another thing: it's type save.
CustomerEntity c = new CustomerEntity();
c.CompanyName = "MyCompany Inc.";
c.ContactPerson = "Joe Smith";
//.. save the entity, using the mechanism of the o/r mapper, e.g.:
c.Save();
// or:
using(DataAccessAdapter adapter = new DataAccessAdapter())
{
adapter.SaveEntity(c);
}
// or if your o/r mapper uses a central session/context:
session.Attach(c);
session.PersistChanges();
If something changes in the db, e.g. ContactPerson becomes Contact, it
still works, OR your code breaks at COMPILE TIME, while your sql string
misery breaks at runtime and turns into an unmaintainable nightmare.
Take the example above even further:
OrderEntity o = new OrderEntity();
o.OrderDate = DateTime.Now;
OrderDetailEntity od = new OrderDetailEntity();
od.Price = 10.0f;
od.Quantity = 1;
od.ProductId = 10;
o.OrderDetails.Add(od);
CustomerEntity c = new CustomerEntity();
c.CompanyName = "MyCompany Inc.";
c.ContactPerson = "Joe Smith";
o.Customer = c;
Let's save the order, as that's what we're interested in:
o.Save();
// or:
using(DataAccessAdapter adapter = new DataAccessAdapter())
{
adapter.SaveEntity(o);
}
// or whatever mechanism the o/r mapper uses.
All entities have sequenced PK's. As we're saving the order,
recursively, the customer has to be saved first, as order depends on
customer. The graph thus has to be sorted, so a DAG sorting algo has to
be used, taking into account which entities are affected by fk updates
etc.
The pk's have to be synced with the fk's relying on them, so when
customer is saved, the pk it got of the sequence has to be synced with
the fk in order, which then has to be saved and after that the order
details, which receives the pk of order.
All I did was write some typed, compile time checked code which is
simple to follow, easy to update and maintain (!) and everything is
taken care of.
Can you do that easily with the same # of code I wrote? I doubt it, as
sorting graphs and have pk-fk syncing isn't easy. So you've to build
that into the code you write. But that will then be very fragile code
as one change will perhaps break everything up and you've to reschedule
all the saves and pk-syncs.
I.o.w.: you're doing a lot of plumbing code which comes for free with
an o/r mapper. That's the advantage of using a persistence layer which
solves the impedance mismatch as it abstracts away the relational
aspects of the persistant storage.
> > Of course, using an OODB has
> > drawbacks as I described in my post in this thread, but if you don't
> > run into them, which is often in a program which is targeting a
> > niche or has specialistic features, an OODB doesn't have to be a
> > bad choice.
>
> You have to tell what niche it is. Somebody mentioned bill of
> materials, but are they really familiar with hierarchical query
> facilities in SQL?
an application without a lot of lists build from attributes of
various entities is suitable for an OODB.
fre...@gmail.com
> > Calling SQL from say java code is one of the easiest tasks in mordern
> > programming. Getting results back is straightforward as well. What I
> > also never has been able to grasp is why would you discard this simple
> > idea lightly in favor of learning obscure 20 something mapping rules
> > (TopLink).
>
> that's simple.
> take the following small code snippet.
> using(DataAccessAdapter adapter = new DataAccessAdapter())
> {
> adapter.SaveEntity(myCustomer);
> }
>
> this line of code saves:
> - the Customer entity instance myCustomer
> - its related Order entities
> - its related order detail entities
> - and other related entities to these.
>
> all in the right order, it syncs pks with fk's, it pulls back the new
> PK's from the db if the pk's are identity/sequenced, performs pre-/post
> save validation etc. etc. etc.
>
> effectively 2 lines of code.
>
> Now, tell me, you can do all that with 2 lines of code with SQL
> strings etc. ? No, you can't.
But what about DataAccessAdapter? If it is a generic framework class I
guess that you have to supply som O/R mapping descriptions that is
longer than 2 lines. And there are numerous known problem with O/R
mapping that limits the way you can use a RDBMS. If DataAccessAdapter
is a custom class I guess you have a lot of SQL code inside it. And you
didn't provide the Customer, Order and OrderDetail classes. Using a
SQL-based approach, these classes are not necessary.
> Another thing: it's type save.
If you embedded SQL like SQLJ you will also get type safety.
> CustomerEntity c = new CustomerEntity();
> c.CompanyName = "MyCompany Inc.";
> c.ContactPerson = "Joe Smith";
> //.. save the entity, using the mechanism of the o/r mapper, e.g.:
> c.Save();
insert into company (name, contactperson) values ('MyCompanyInc','Joe
Smith')
My SQL-based approach did it in only one line.
> If something changes in the db, e.g. ContactPerson becomes Contact, it
> still works, OR your code breaks at COMPILE TIME, while your sql string
> misery breaks at runtime and turns into an unmaintainable nightmare.
Use embedded SQL.
> Take the example above even further:
> OrderEntity o = new OrderEntity();
> o.OrderDate = DateTime.Now;
> OrderDetailEntity od = new OrderDetailEntity();
> od.Price = 10.0f;
> od.Quantity = 1;
> od.ProductId = 10;
> o.OrderDetails.Add(od);
> CustomerEntity c = new CustomerEntity();
> c.CompanyName = "MyCompany Inc.";
> c.ContactPerson = "Joe Smith";
> o.Customer = c;
>
> Let's save the order, as that's what we're interested in:
> o.Save();
>
> // or:
> using(DataAccessAdapter adapter = new DataAccessAdapter())
> {
> adapter.SaveEntity(o);
> }
insert into customer (companyname, contactperson) values ('MyCompany
Inc', 'Joe Smith')
customerid = insert_id();
insert into order (orderdate, customerid) values (now(), customerid);
orderid = insert_id();
insert into orderdetail (orderid, price, quantity, productid) values
(orderid, 10, 1, 10);
Your solution is still more verbose than a SQL-based approach.
> The pk's have to be synced with the fk's relying on them, so when
> customer is saved, the pk it got of the sequence has to be synced with
> the fk in order, which then has to be saved and after that the order
> details, which receives the pk of order.
This problem only exists when you use domain objects. A SQL-based
solution has no problems with this.
> All I did was write some typed, compile time checked code which is
> simple to follow, easy to update and maintain (!) and everything is
> taken care of.
My code compile time checked, simple to follow easy to update and
maintain.
> Can you do that easily with the same # of code I wrote? I doubt it,
Yes, but with less # of code.
> I.o.w.: you're doing a lot of plumbing code which comes for free with
> an o/r mapper. That's the advantage of using a persistence layer which
> solves the impedance mismatch as it abstracts away the relational
> aspects of the persistant storage.
If you try to map classes to tables, you have an impedance mismatch.
But if you map classes to datatypes (date, SSN, etc) the relational
model and OO lives happy together.
Fredrik Bertilsson
http://frebe.php0h.com
fre...@gmail.com
> Calling SQL from say java code is one of the easiest tasks in mordern
> programming. Getting results back is straightforward as well.
The major problem is that SQL statements are written as strings in
Java. And in Java you can't write a string that spans multiple lines.
You need use + operator or StringBuffer append. Even in languages with
proper string features, the strings are not compiled until runtime. But
embedded SQL is the solution to that problem. Unfortunately embedded
SQL for java, SQLJ, is very rarely used. In other languages like COBOL
or C it is much more common.
> What I
> also never has been able to grasp is why would you discard this simple
> idea lightly in favor of learning obscure 20 something mapping rules
> (TopLink).
It is based on the misconception that the network model (object graphs)
are better suited for data management, than the relational model (set
theory and predicate logic). If you prefer object graphs, you need
verbose O/R mapping.
Fredrik Bertilsson
http://frebe.php0h.com
Frans Bouma
It's an example of using an o/r mapper, so it's an element of an o/r
mapper. I also could have picked NHibernate's session object, it would
serve the same purpose.
> If DataAccessAdapter
> is a custom class I guess you have a lot of SQL code inside it. And
> you didn't provide the Customer, Order and OrderDetail classes. Using
> a SQL-based approach, these classes are not necessary.
An o/r mapper generates SQL on the fly so there's no sql in there at
all.
> > Another thing: it's type save.
>
> If you embedded SQL like SQLJ you will also get type safety.
hehe, no way.
string myQuery = "SELECT CompanyName, ContactPerson, CustomerID FROM
Customer";
How's that typesave and how does that break at compiletime? It will
break at runtime, something you want to avoid, because if the name
changes you've to manually search for ALL code to make the change. If
it breaks at compiletime, just compile the code, fix the errors and
you're done.
> > CustomerEntity c = new CustomerEntity();
> > c.CompanyName = "MyCompany Inc.";
> > c.ContactPerson = "Joe Smith";
> > //.. save the entity, using the mechanism of the o/r mapper, e.g.:
> > c.Save();
>
> insert into company (name, contactperson) values ('MyCompanyInc','Joe
> Smith')
>
> My SQL-based approach did it in only one line.
how did you run that sql code from say Java or C#? That's the whole
point. Also, how do you handle fk-pk syncs and new pk value retrieval ?
>
> > If something changes in the db, e.g. ContactPerson becomes
> > Contact, it still works, OR your code breaks at COMPILE TIME, while
> > your sql string misery breaks at runtime and turns into an
> > unmaintainable nightmare.
>
> Use embedded SQL.
I don't think you understand what I was talking about, see above.
*sigh*. Show me your code in Java or C#. that's the point. Your code
also contains the order in which it is saved. If I get the objects from
a gui tier and the graph contains say 20 objects and say 5 entitytypes,
your code will already become complex, and if something changes the
order might change as well, which will break your code, AT RUNTIME, or
better: will cause a bug which is hard to find.
> > The pk's have to be synced with the fk's relying on them, so when
> > customer is saved, the pk it got of the sequence has to be synced
> > with the fk in order, which then has to be saved and after that the
> > order details, which receives the pk of order.
>
> This problem only exists when you use domain objects. A SQL-based
> solution has no problems with this.
I'm not sure if you understand what I was talking about but I was
talking about a SQL based solution, namely an o/r mapper using solution
as an example to show that hard-coded sql queries in code isn't useful
nor necessary. I'm not talking about an OODB.
> > All I did was write some typed, compile time checked code which is
> > simple to follow, easy to update and maintain (!) and everything is
> > taken care of.
>
> My code compile time checked, simple to follow easy to update and
> maintain.
your code is compiletime checked? Your embedded sql strings are
compile time checked? How on earth does a java or c# compiler check
your embedded sql strings?
> > I.o.w.: you're doing a lot of plumbing code which comes for free
> > with an o/r mapper. That's the advantage of using a persistence
> > layer which solves the impedance mismatch as it abstracts away the
> > relational aspects of the persistant storage.
>
> If you try to map classes to tables, you have an impedance mismatch.
> But if you map classes to datatypes (date, SSN, etc) the relational
> model and OO lives happy together.
erm... mapping datatypes to classes isn't the problem, that's done by
any db driver for you, the point is having entities in your OWN CODE
and persist them into a relational database. The gap between YOUR OWN
CODE and the relational database is the gap you still have to fill up
with code to make it work.
Frans Bouma
> > What I
> > also never has been able to grasp is why would you discard this
> > simple idea lightly in favor of learning obscure 20 something
> > mapping rules (TopLink).
>
> It is based on the misconception that the network model (object
> graphs) are better suited for data management, than the relational
> model (set theory and predicate logic). If you prefer object graphs,
> you need verbose O/R mapping.
I hope you realize that what you're preaching is more verbose, as you
completely ignore the code you've to write to execute these
unmaintainable embedded sql strings.
fre...@gmail.com
>
> hehe, no way.
Are you aware of SQLJ (http://www.onjava.com/pub/ct/46)? I suggest that
you do a little homework first. For other languages there are other
embedded SQL products, like Pro*C.
> string myQuery = "SELECT CompanyName, ContactPerson, CustomerID FROM
> Customer";
> How's that typesave and how does that break at compiletime? It will
> break at runtime, something you want to avoid, because if the name
> changes you've to manually search for ALL code to make the change. If
> it breaks at compiletime, just compile the code, fix the errors and
> you're done.
This example is not typesave nor SQLJ. Do your homework first.
> > > CustomerEntity c = new CustomerEntity();
> > > c.CompanyName = "MyCompany Inc.";
> > > c.ContactPerson = "Joe Smith";
> > > //.. save the entity, using the mechanism of the o/r mapper, e.g.:
> > > c.Save();
> >
> > insert into company (name, contactperson) values ('MyCompanyInc','Joe
> > Smith')
> >
> > My SQL-based approach did it in only one line.
>
> how did you run that sql code from say Java or C#? That's the whole
> point. Also, how do you handle fk-pk syncs and new pk value retrieval ?
In Java using SQLJ it would look like:
#sql { insert into company (name, contactperson) values
('MyCompanyInc','Joe Smith') };
I already showd you how to handle you imaginary problem with fk-pk
syncs and new pk value retrieval. Most databases has a function (like
insert_id) that returns the last generated sequence no (for the current
session).
> > > If something changes in the db, e.g. ContactPerson becomes
> > > Contact, it still works, OR your code breaks at COMPILE TIME, while
> > > your sql string misery breaks at runtime and turns into an
> > > unmaintainable nightmare.
> >
> > Use embedded SQL.
>
> I don't think you understand what I was talking about, see above.
I don't think you understand what embedded SQL is. Read the link I
supplied above.
Wrap every line inside #sql { } and you have the Java code.
> Your code also contains the order in which it is saved.
What is the great benefit with being able to call statements in random
order?
> If I get the objects from
> a gui tier and the graph contains say 20 objects and say 5 entitytypes,
> your code will already become complex, and if something changes the
> order might change as well, which will break your code, AT RUNTIME, or
> better: will cause a bug which is hard to find.
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.
> > > The pk's have to be synced with the fk's relying on them, so when
> > > customer is saved, the pk it got of the sequence has to be synced
> > > with the fk in order, which then has to be saved and after that the
> > > order details, which receives the pk of order.
> >
> > This problem only exists when you use domain objects. A SQL-based
> > solution has no problems with this.
>
> I'm not sure if you understand what I was talking about but I was
> talking about a SQL based solution, namely an o/r mapper using solution
> as an example to show that hard-coded sql queries in code isn't useful
> nor necessary. I'm not talking about an OODB.
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.
> > > All I did was write some typed, compile time checked code which is
> > > simple to follow, easy to update and maintain (!) and everything is
> > > taken care of.
> >
> > My code compile time checked, simple to follow easy to update and
> > maintain.
>
> your code is compiletime checked?
Yes. Try to learn something about SQLJ or any other embedded SQL
products.
> 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.
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?
> How on earth does a java or c# compiler check
> your embedded sql strings?
Once again, do your homework and read a little bit about SQLJ. And we
are not only limited to java or c# compilers. We might also use
pre-compilers.
> > > I.o.w.: you're doing a lot of plumbing code which comes for free
> > > with an o/r mapper. That's the advantage of using a persistence
> > > layer which solves the impedance mismatch as it abstracts away the
> > > relational aspects of the persistant storage.
> >
> > If you try to map classes to tables, you have an impedance mismatch.
> > But if you map classes to datatypes (date, SSN, etc) the relational
> > model and OO lives happy together.
>
> erm... mapping datatypes to classes isn't the problem, that's done by
> any db driver for you, the point is having entities in your OWN CODE
> and persist them into a relational database. The gap between YOUR OWN
> CODE and the relational database is the gap you still have to fill up
> with code to make it work.
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.
Fredrik Bertilsson
http://frebe.php0h.com
fre...@gmail.com
> > > also never has been able to grasp is why would you discard this
> > > simple idea lightly in favor of learning obscure 20 something
> > > mapping rules (TopLink).
> >
> > It is based on the misconception that the network model (object
> > graphs) are better suited for data management, than the relational
> > model (set theory and predicate logic). If you prefer object graphs,
> > you need verbose O/R mapping.
>
> I hope you realize that what you're preaching is more verbose, as you
> completely ignore the code you've to write to execute these
> unmaintainable embedded sql strings.
Did you notice the letters SQLJ in my post? Do you know what it is? If
not, did you google for it? If yes, did you find anything? If yes, did
you read it? If yes, did you understand anything?
Fredrik Bertilsson
Frans Bouma
> > > If you embedded SQL like SQLJ you will also get type safety.
> >
> > hehe, no way.
>
> Are you aware of SQLJ (http://www.onjava.com/pub/ct/46)? I suggest
> that you do a little homework first. For other languages there are
> other embedded SQL products, like Pro*C.
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.
It's interesting, though still I doubt it checks at compile time of
your application that your queries are correctly matching the target db.
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?
> > string myQuery = "SELECT CompanyName, ContactPerson, CustomerID FROM
> > Customer";
> > How's that typesave and how does that break at compiletime? It will
> > break at runtime, something you want to avoid, because if the name
> > changes you've to manually search for ALL code to make the change.
> > If it breaks at compiletime, just compile the code, fix the errors
> > and you're done.
>
> This example is not typesave nor SQLJ. Do your homework first.
Lecture someone else, mister. I damn well know what it takes to write
a typesave data-access layer and I don't have to proof that anymore.
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.
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.
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.
You do know what typesafety means, I hope?
> > > > CustomerEntity c = new CustomerEntity();
> > > > c.CompanyName = "MyCompany Inc.";
> > > > c.ContactPerson = "Joe Smith";
> > > > //.. save the entity, using the mechanism of the o/r mapper,
> > > > e.g.: c.Save();
> > >
> > > insert into company (name, contactperson) values
> > > ('MyCompanyInc','Joe Smith')
> > >
> > > My SQL-based approach did it in only one line.
> >
> > how did you run that sql code from say Java or C#? That's the whole
> > point. Also, how do you handle fk-pk syncs and new pk value
> > retrieval ?
>
> In Java using SQLJ it would look like:
> #sql { insert into company (name, contactperson) values
> ('MyCompanyInc','Joe Smith') };
>
> I already showd you how to handle you imaginary problem with fk-pk
> syncs and new pk value retrieval. Most databases has a function (like
> insert_id) that returns the last generated sequence no (for the
> current session).
it's not an imaginary problem, as when you save a graph you've to
manually update FK's pointing to the same PK, that's not done for you
and to update your objects in-memory with these values is thus not an
imaginairy problem, it's a real problem and to do it in 100% of the
situations thinkable, it's not an easy problem to solve as well.
> > > > If something changes in the db, e.g. ContactPerson becomes
> > > > Contact, it still works, OR your code breaks at COMPILE TIME,
> > > > while your sql string misery breaks at runtime and turns into an
> > > > unmaintainable nightmare.
> > >
> > > Use embedded SQL.
> >
> > I don't think you understand what I was talking about, see above.
>
> I don't think you understand what embedded SQL is. Read the link I
> supplied above.
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.
and it's executed in the right order?
> > Your code also contains the order in which it is saved.
> What is the great benefit with being able to call statements in random
> order?
Who has to do his homework here?
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.
> > If I get the objects from
> > a gui tier and the graph contains say 20 objects and say 5
> > entitytypes, your code will already become complex, and if
> > something changes the order might change as well, which will break
> > your code, AT RUNTIME, or better: will cause a bug which is hard to
> > find.
>
> 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?
Because for what reason do you want to refuse them? Because they
otherwise will introduce 'imaginairy' problems?
> > > > The pk's have to be synced with the fk's relying on them, so
> > > > when customer is saved, the pk it got of the sequence has to be
> > > > synced with the fk in order, which then has to be saved and
> > > > after that the order details, which receives the pk of order.
> > >
> > > This problem only exists when you use domain objects. A SQL-based
> > > solution has no problems with this.
> >
> > I'm not sure if you understand what I was talking about but I was
> > talking about a SQL based solution, namely an o/r mapper using
> > solution as an example to show that hard-coded sql queries in code
> > isn't useful nor necessary. I'm not talking about an OODB.
>
> 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.
> > > > All I did was write some typed, compile time checked code
> > > > which is simple to follow, easy to update and maintain (!) and
> > > > everything is taken care of.
> > >
> > > My code compile time checked, simple to follow easy to update and
> > > maintain.
> >
> > 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...
> > 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?
> 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?
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.
Just because there's some hype around dynamically typed languages,
doesn't mean they're key for better software.
> > > > I.o.w.: you're doing a lot of plumbing code which comes for
> > > > free with an o/r mapper. That's the advantage of using a
> > > > persistence layer which solves the impedance mismatch as it
> > > > abstracts away the relational aspects of the persistant storage.
> > >
> > > If you try to map classes to tables, you have an impedance
> > > mismatch. But if you map classes to datatypes (date, SSN, etc)
> > > the relational model and OO lives happy together.
> >
> > erm... mapping datatypes to classes isn't the problem, that's
> > done by any db driver for you, the point is having entities in your
> > OWN CODE and persist them into a relational database. The gap
> > between YOUR OWN CODE and the relational database is the gap you
> > still have to fill up with code to make it work.
>
> 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.
fre...@gmail.com
> 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
carl.ros...@gmail.com
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
carl.ros...@gmail.com
> 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.
topmind
carl.ros...@gmail.com wrote:
> fre...@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
Frans Bouma
> > 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.
Frans Bouma
>
> 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
out of curiosity: weren't you going to build this into db4o, or
better: weren't you going to support more ad-hoc querying support in
db4o to counter this problem?
fre...@gmail.com
> 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.
I already showed to you that using embedded SQL gives you a less
verbose source code. The impedance mismatch is avoided by not mapping
classes to tables.
> > > > > *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.
What is DAG and how does that corresponds to your customer/order
example?
> Now something changes.
What changes? The database schema, the application code, or?
> Where to change your list of sql statements so
> the code works OK? I don't have to think about that.
Can you give an example using your customer/order scenario?
> 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.
I don't you any graph. When I update data, I call an update statement.
You need to first call a set-method and later call a save method,
giving you complex problems. You have two different states (objects and
tables) that need to be syncronized. That is the disadvantage with an
object domain model. The database schema is the domain model.
> Sure, if you want to spend time on that and doing all the sql
> yourself, why not?
I already showed you I have to write fewer lines of code than you.
> 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.
Can you please exemplify.
> You really must like these runtime errors.
Nope.
Fredrik Bertilsson
http://frebe.php0h.com
carl.ros...@gmail.com
Frans Bouma wrote:
> > 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
>
> out of curiosity: weren't you going to build this into db4o, or
> better: weren't you going to support more ad-hoc querying support in
> db4o to counter this problem?
Hi Frans,
our query processor ( for Query-By-Example, SODA, Native Queries )
can deal with indexes very well as long as objects reference eachother.
Aggregating data from objects that are not connected by references
does work but it is not yet directly supported by the query processor.
Best,
Carl
--
Carl Rosenberger
Chief Sofware Architect
db4objects Inc.
http://www.db4o.com
aloha.kakuikanu
Frans Bouma wrote:
> string myQuery = "SELECT CompanyName, ContactPerson, CustomerID FROM
> Customer";
>
> How's that typesave and how does that break at compiletime? It will
> break at runtime, something you want to avoid, because if the name
> changes you've to manually search for ALL code to make the change. If
> it breaks at compiletime, just compile the code, fix the errors and
> you're done.
You are completely out of sync with current database application
practices. The simple statement like your example *never breaks*.
People for sure would add columns into the Customer table, but your
statement still would run with no issues. People can completely
reorganize customer schema, provide backward compatible views and your
statement would still run just fine. It is much more likely, that
you'll spend most of your time chasing bugs in the spaghetty of object
pointers, then fix the SQL.
fre...@gmail.com
Frank is also ignoring the fact that even is such a stupid schema
change is done, the embedded SQL pre-compiler would catch it. Hibernate
or some other O/R-mapper would not detect such schema change until
runtime.
Fredrik Bertilsson
Frans Bouma
> > 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.
>
> I already showed to you that using embedded SQL gives you a less
> verbose source code. The impedance mismatch is avoided by not mapping
> classes to tables.
No, the impedance mismatch is still there, as the mismatch is about
thinking in objects -> thinking in set oriented data.
You do the conversion with your own sql statements. If I have an
entity which is mapped onto 2 tables because it's a subtype of another
entity, I'm working with a single object and save a single object. You
have to write 2 queries, first the supertype one, then the subtype one.
When deleting the same entity, you too have to write 2 queries, but now
in reverse order. That's solving the mismatch in code yourself, as it
otherwise is left to the o/r mapper.
> > > > > > *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.
>
> What is DAG and how does that corresponds to your customer/order
> example?
Directed Acyclic Graph.
Customer <- Order <- OrderDetails
|----> Employee
etc.
'<-' == depends on.
When working with objects in memory which are related to eachother,
you will be working with object graphs as that's more easier and fits
into the way OOD is done.
Your problem is that you by yourself have to figure out what the order
is of ALL the entities in the graph to save all the changes (and what
are the changes btw? You've to figure out which fields have changed and
if the object is new or not new etc.)
this problem shows its ugly head when you for example have a system
where a GUI part doesn't contain knowledge how to save the data managed
by the GUI part, i.e. an order entry form.
The form then will push down a changed object graph or collection of
objects and doesn't knwo what the order is or which objects are changed
as that's not important, as we're using OO, not flat-file C code.
You then have to figure out which entities are new, which aren't,
which have to be saved first, which after that, which syncs with which
etc. I don't have to do that. I call 1 method and it's done. That's
what makes the system more efficient and less error prone as it doesn't
matter if an FK is changed, my code will still work.
> > Now something changes.
>
> What changes? The database schema, the application code, or?
any change that will make the order in which elements have to be saved
different.
and make no mistake: the order in which entities can be saved MIGHT be
different based on data, i.e. in entities with a relation to self.
> > Where to change your list of sql statements so
> > the code works OK? I don't have to think about that.
>
> Can you give an example using your customer/order scenario?
Same code as I gave before. the sorting of the complete graph is done
by the o/r mapper layer, which also checks which entities to save and
which to ignore, which fields to update and if an entity has to be
updated or inserted etc.
> > 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.
>
> I don't you any graph. When I update data, I call an update statement.
> You need to first call a set-method and later call a save method,
> giving you complex problems. You have two different states (objects
> and tables) that need to be syncronized. That is the disadvantage
> with an object domain model. The database schema is the domain model.
The relational model is very important, I won't deny that, but I think
you overlook something: what you and I call semantically 'Customer' or
'Order' is effectively the same abstract entity. If you look at THAT,
and not at where it's physically represented, you'll undersatnd it
doesn't matter where you start from: the rest is plumbing code.
> > Sure, if you want to spend time on that and doing all the sql
> > yourself, why not?
>
> I already showed you I have to write fewer lines of code than you.
I don't think so.
// get all customers from germany and their orders. This will give
// two queries, not 1 + #of customers fetched. Everything is merged
// for me into a graph.
// private member variable of form:
private EntityCollection<CustomerEntity> _customers;
// init code
_customers = new EntityCollection<CustomerEntity>();
PrefetchPath2 path = new PrefetchPath2((int)EntityType.CustomerEntity);
path.Add(CustomerEntity.PrefetchPathOrders);
RelationPredicateBucket filter = new RelationPredicateBucket(
(CustomerFields.Country== "Germany"));
using(DataAccessAdapter adapter = new DataAccessAdapter())
{
// fetch graph
adapter.FetchEntityCollection(_customers, filter, path);
}
// bind to master-detail grid
myCustomerDataGrid.DataSource = _customers;
myOrderDataGrid.DataSource = _customers;
myOrderDataGrid.DataMember = "Orders";
//...
//... in the save button click event handler:
using(DataAccessAdapter adapter = new DataAccessAdapter())
{
adapter.SaveEntityCollection(_customers);
}
et viola. I load a graph, filter the root entities on some field,
typed, I then bind the graph to two grids, master detail. I can edit
whatever I want in the two grids, add new rows, whatever, I don't care.
Then I save the whole graph with effectively 1 line of code.
Also, the code is db agnostic: it works on any db supported by the
O/R mapper.
The syntaxis of the o/r mapper code above is mine, but other o/r
mappers offer similar features, or perhaps in a different way but the
idea is clear I hope.
There's no code written which fixes the order in which things are
saved. This is preferable, as this thus doesn't break when the db
schema changes slightly. A 2-level graph is perhaps not the best
example for this, but I hope you can imagine that when you have a more
complex graph with more dependencies (and e.g. a relation with self)
you will run into problems if the save order changes in that graph,
different FK's are synced etc. What's key is that things that belong to
the plumbing required for making the switch from OO thinking to
setoriented thinking are abstracted away for you: you don't have to
worry about that. With your code you DO have to worry about that.
I'm not implying what you wrote doesn't work, because I'm sure it will
work, however it will be MORE work to KEEP it right all the time,
because you've to perform the plumbing for the mismatch solving
yourself. I don't know which sql statements are generated by the
o/rmapper and frankly I don't care. You have to care about that.
Frans Bouma
>
> Frans Bouma wrote:
> > string myQuery = "SELECT CompanyName, ContactPerson, CustomerID FROM
> > Customer";
> >
> > How's that typesave and how does that break at compiletime? It will
> > break at runtime, something you want to avoid, because if the name
> > changes you've to manually search for ALL code to make the change.
> > If it breaks at compiletime, just compile the code, fix the errors
> > and you're done.
>
> You are completely out of sync with current database application
> practices. The simple statement like your example *never breaks*.
> People for sure would add columns into the Customer table, but your
> statement still would run with no issues.
I was talking about name mismatches not additional columns. I think I
know what it takes to create sql which runs OK on schemas which are a
moving target.
> People can completely
> reorganize customer schema, provide backward compatible views and your
> statement would still run just fine. It is much more likely, that
> you'll spend most of your time chasing bugs in the spaghetty of object
> pointers, then fix the SQL.
Which object pointers?
Frans Bouma
> > > string myQuery = "SELECT CompanyName, ContactPerson, CustomerID
> > > FROM Customer";
> > >
> > > How's that typesave and how does that break at compiletime? It
> > > will break at runtime, something you want to avoid, because if
> > > the name changes you've to manually search for ALL code to make
> > > the change. If it breaks at compiletime, just compile the code,
> > > fix the errors and you're done.
> >
> > You are completely out of sync with current database application
> > practices. The simple statement like your example *never breaks*.
> > People for sure would add columns into the Customer table, but your
> > statement still would run with no issues. People can completely
> > reorganize customer schema, provide backward compatible views and
> > your statement would still run just fine. It is much more likely,
> > that you'll spend most of your time chasing bugs in the spaghetty
> > of object pointers, then fix the SQL.
>
> Frank is also ignoring the fact that even is such a stupid schema
FranS
> change is done, the embedded SQL pre-compiler would catch it.
> Hibernate or some other O/R-mapper would not detect such schema
> change until runtime.
Not all. LLBLGen Pro can figure out any schema change, change your
mappings for you, and you hit 1 button to update your mappings in your
project and you're back in business.
Sasa
"Frans Bouma" <perseus.usenet.NOSPAM.@xs4all.nl> wrote in message
news:xn0eth1a...@news.xs4all.nl...
> fre...@gmail.com wrote:
> Also, the code is db agnostic: it works on any db supported by the
> O/R mapper.
Since you brought this up - are there mappers which support non relational
storages (XML, proprietary formats, etc.)?
Sasa
Christian Brunschen
I'd suggest that peple look at Apple's WebObejcts, which includes Apple's
'Enterprise Objects Foundation', 'EOF', which is, among other things an
O/R mapper.
However, where Hibernate directly maps database constructs to Java
contstructs (essentially, tables to classes, etc), EOF uses an
Entity-Relationship model, which is then mapped to tables & columns on one
side, and to classes and fields on the other - though EOF can in fact use
a 'generic object' class (essentially a dictionary / hashtable) to
represent any entities for which you don't need to implement any bespoke
logic. WebObjects (and EOF) underly the iTunes Music Store, for instance.
EOF allows you to write your own 'database adaptor' classes; there have
been those that use flat files. It is generally used with relational
databases, though.
More recently, Apple have (as part of their Cocoa frameworks) introduced
'Core Data', which is not a general Object-relational modeler, but instead
is billed as an 'object graph management system', and which can use either
a relational database (SQLite) or an XML file as its underlying datastore
for persistence. However, with Core Data, you just design your object
model, and don't have any specific control over the database schema.
>Sasa
Best wishes,
// Christian Brunschen
fre...@gmail.com
> > verbose source code. The impedance mismatch is avoided by not mapping
> > classes to tables.
>
> No, the impedance mismatch is still there, as the mismatch is about
> thinking in objects -> thinking in set oriented data.
If you look at www.thethirdmanifesto.com you can find some material
that explains why objects and sets are orthogonal issues.
> You do the conversion with your own sql statements. If I have an
> entity which is mapped onto 2 tables because it's a subtype of another
> entity, I'm working with a single object and save a single object. You
> have to write 2 queries, first the supertype one, then the subtype one.
> When deleting the same entity, you too have to write 2 queries, but now
> in reverse order. That's solving the mismatch in code yourself, as it
> otherwise is left to the o/r mapper.
This is easily solved by updatable views (which is supported by major
database vendors).
> > What is DAG and how does that corresponds to your customer/order
> > example?
>
> Directed Acyclic Graph.
> Customer <- Order <- OrderDetails
> |----> Employee
>
> etc.
>
> '<-' == depends on.
>
> When working with objects in memory which are related to eachother,
> you will be working with object graphs as that's more easier and fits
> into the way OOD is done.
For the last time, I don't work with object graphs. I work with
relations. Problems related to objects graphs are not relevant for me.
> Your problem is that you by yourself have to figure out what the order
> is of ALL the entities in the graph to save all the changes (and what
> are the changes btw? You've to figure out which fields have changed and
> if the object is new or not new etc.)
I don't buffer changes in memory objects. I call update immediatly when
I want to change some data. I don't have your order problem.
> this problem shows its ugly head when you for example have a system
> where a GUI part doesn't contain knowledge how to save the data managed
> by the GUI part, i.e. an order entry form.
The problem only exists if you forbid the GUI to use SQL.
> The form then will push down a changed object graph or collection of
> objects and doesn't knwo what the order is or which objects are changed
> as that's not important, as we're using OO, not flat-file C code.
Another argument for not using object graphs....
> You then have to figure out which entities are new, which aren't,
> which have to be saved first, which after that, which syncs with which
> etc. I don't have to do that. I call 1 method and it's done. That's
> what makes the system more efficient and less error prone as it doesn't
> matter if an FK is changed, my code will still work.
Because I don't buffer changes in objects, I don't have any sync
problem.
> > > Now something changes.
> >
> > What changes? The database schema, the application code, or?
>
> any change that will make the order in which elements have to be saved
> different.
>
> and make no mistake: the order in which entities can be saved MIGHT be
> different based on data, i.e. in entities with a relation to self.
Can you be more specific please?
> > > Where to change your list of sql statements so
> > > the code works OK? I don't have to think about that.
> >
> > Can you give an example using your customer/order scenario?
>
> Same code as I gave before. the sorting of the complete graph is done
> by the o/r mapper layer, which also checks which entities to save and
> which to ignore, which fields to update and if an entity has to be
> updated or inserted etc.
Sorting is done by the database. The GUI is responsible for
determinating which data that should be updated or inserted.
> The relational model is very important, I won't deny that, but I think
> you overlook something: what you and I call semantically 'Customer' or
> 'Order' is effectively the same abstract entity. If you look at THAT,
> and not at where it's physically represented, you'll undersatnd it
> doesn't matter where you start from: the rest is plumbing code.
I don't care about how 'Customer' is phisically represented. The
database hides that from me.
You don't show the source code for your data grid, so I suppose I am
allowed to use my own generic master/child grid. All you have to supply
to the grid is the SQL statements for retrieving and writing the data.
In PHP it would look something like this:
myGrid.masterSelect = <<<SQL
select customerid, companyname, contactperson
from customer
where country='Germany'
SQL;
myGrid.childSelect = <<<SQL
select orderid, orderdate, amount
from order where customerid=$customerid
SQL;
myGrid.masterUpdate = <<<SQL
update customer
set companyname=$companyname, contactperson=$contactperson
where customerid=$customerid
SQL;
myGrid.display()
or
myGrid.save()
I assume that layout info and additional business logic need to be
added to the grid as extra properties and function pointers, but you
don't supply them either.
> Then I save the whole graph with effectively 1 line of code.
Me too.
> Also, the code is db agnostic: it works on any db supported by the
> O/R mapper.
My SQL is not vendor specific.
> There's no code written which fixes the order in which things are
> saved.
There is no need for it.
> I'm not implying what you wrote doesn't work, because I'm sure it will
> work, however it will be MORE work to KEEP it right all the time,
> because you've to perform the plumbing for the mismatch solving
> yourself. I don't know which sql statements are generated by the
> o/rmapper and frankly I don't care. You have to care about that.
My solution does not takes more work.
Fredrik Bertilsson
http://frebe.php0h.com
Frans Bouma
in theory that's indeed possible, in practise I'm not sure I know any
o/r mapper out there which supports non-relational storages, like XML
or what have you.
AndyW
<perseus.usenet.NOSPAM.@xs4all.nl> wrote:
>fre...@gmail.com wrote:
>
>> > 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.
>>
>> I already showed to you that using embedded SQL gives you a less
>> verbose source code. The impedance mismatch is avoided by not mapping
>> classes to tables.
>
> No, the impedance mismatch is still there, as the mismatch is about
>thinking in objects -> thinking in set oriented data.
I would agree with that and I think its one of the issues between
people that work with relational data vs people that work with object
data.
Its like a math expert claiming that they really dont thing logically.
topmind
It seems one big difference between OO fans and relational fans is that
OO fans think that these should be seperate people or specialties,
while relational fans think they should be the same people because
relational is or can be a key app tool and not just a "storage" tool.
That battle continues, for good or bad...
>
> Its like a math expert claiming that they really dont thing logically.
-T-
Frans Bouma
I don't see why there should be a battle. There's no black-white here,
simply because solely using OO objects is problematic in some
situations and so is pure set-based data.
That's also why most mature O/R mappers offer a way to pull dynamic
sets out of the DB based on meta-data available in the mappings, i.e. a
list of some order attributes + the customer.companyname in a new set,
including features to project this set onto different datastructures /
classes if you want to.
As long as people think that solely using entity representing objects
covers 100% of the cases and also the other 'side' thinks everything
set-based/oriented is fully usable as an OO construct in an OO program,
these discussions won't end, but at the same time, they're as
meaningless as the stupid debates whether stored procedures are better
than dynamic SQL.
Phlip
> topmind wrote:
>
>> OO fans
> these discussions won't end
You figured out Topmind's system!
--
Phlip
http://www.greencheese.us/ZeekLand <-- NOT a blog!!!
hast...@hotmail.com
> fre...@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.
>
Ahem... And what is your point exactly, Carl ?
--- Raoul