Re: Unknown SQL

Joe Cosby wrote:
> >A database without set logic (some present object databases) does not
> >require you to think in sets. You only think in terms of single objects.
> >
> >Agreed, a declarative query interface to create sets is a feature that is
> >needed in most database applications.
> >
>
> Well how exactly do you define a set of data if not as a set?
 

:-)

If you work with single objects only, you do not think in sets of data. You create business rules to modify members, if certain members are modified in a certain way. You never need to see all objects at once, since the database takes care of persisting changed values automatically. The system is called "transparent persistency". You don't need to think in sets. (Personally I do not think the times are ready for this approach. It would require tons of standardised callback methods to handle locking issues intelligently.)

> But for the most part, these don't come under the category of
> 'learning SQL', or have anything to do inherently with SQL as a query
> language. You're talking about behavior of the database system
> itself, and learning what the vendor supports and how.

Yes that is true, but wouldn't it be nice if there would be a standard that defines how to do these tasks? Shouldn't it be part of something? SQL or a standard API?

> >- how do outer joins work?
>
> Agreed, that is a complicated part of learning SQL, but if you want
> that functionality, you're going to have to learn something analogous.

The approach we follow is a little different. In contrast to SQL our S.O.D.A. query interface has a "viewport". "WHERE attribute.member = 'X' OR attribute = null" will always automatically be an "outer join".

Kind regards,
Carl

---
Carl Rosenberger
db4o - database for objects - http://www.db4o.com