Re: object databases

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.

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.

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.

*sigh*. Show me your code in Java or C#. that's the point.

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

.

Relevant Pages

  • Re: object databases
    ... No I never heard of SQLJ as I don't program in Java. ... SQLJ checks your SQL statements against the db. ... The compile time check is not mandatory. ... So you use an object oriented language, ...
    (comp.object)
  • Re: Full-Text Catalog does not build...
    ... You're welcome, Oleg, ... I've not confirmed if the Arabic language will be a FTS supported ... language in SQL Server 2005, you may want to review the ...
    (microsoft.public.sqlserver.fulltext)
  • Re: SQL
    ... Language can and do this. ... SQL is typed, ... How about something from the domain of custom biz apps. ... yet nobody would even try to use RDBMS for that. ...
    (comp.object)
  • Re: Databases as objects
    ... Isn't SQL able to assimilate to business vocabulary? ... using the same domain-ignorant language? ... Isn't the database schema already a domain-specific interface? ... have lesser lines of code than a corresponding assembler source code. ...
    (comp.object)
  • Re: SQL
    ... to have an ability to place things into cells ... It is a language issue then. ... An RDBMS engine that may ... Put a program code in a relational table and write compiler in SQL ...
    (comp.object)