Re: Queries and OO
From: Daniel Parker (danielaparker_at_spam?nothanks.windupbird.com)
Date: 01/13/05
- Next message: Ron Jeffries: "Re: how many bugs do you find and correct during TDD?"
- Previous message: Sylvia Gardner: "Re: up front designs always useless"
- In reply to: Doc O'Leary: "Re: Queries and OO"
- Next in thread: Doc O'Leary: "Re: Queries and OO"
- Reply: Doc O'Leary: "Re: Queries and OO"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Date: Wed, 12 Jan 2005 16:01:05 -0800
"Doc O'Leary" <droleary.usenet@2005.subsume.com> wrote in message
news:droleary.usenet-1C2B91.07362112012005@corp.supernews.com...
> In article <BaZEd.30267$TN6.922746@news20.bellglobal.com>,
> "Daniel Parker" <danielaparker@spam?nothanks.windupbird.com> wrote:
>
>> There is no
>> counterpart to querying a collection of objects and applying logical
>> operations to obtain projections on the original set, at least not in a
>> statically typed language. Reflection has nothing to do with it.
>
> You sure have a way of obfuscating your point! All (I guess) you're
> saying is that an object query cannot create new *classes* in the same
> way an SQL query result is a "table" of rows/columns. You're right, but
> given the "static" qualification I could just as easily argue that SQL
> doesn't do what you say because the results of a query aren't *really* a
> table,
A query against a relation, whether it's a restriction (subset of rows), a
projection (subset of columns) or a join, all result in another relation.
You should immediately see the benefits of clear well defined terms :-)
Relational theory is not about database tables.
> and a creating a view in the database breaks a corresponding
> "static" qualification. The database result corresponds more to an
> associative array (aka, hash/map/dictionary) collection, and in that
> manner there would be a corresponding OO way to query those objects to
> get a subset. The question, then, is whether or not you want a query
> mechanism that returns objects themselves, or returns just the
> information that is queried? My assumption is that people don't *want*
> to create classes/objects by doing a query; they want existing objects.
> The query results may not directly correspond to what other mechanisms
> provide, but that doesn't change the fact that you *can*, in theory,
> provide an object query mechanism that doesn't require you to call
> methods on objects to execute the query.
The point is that the relational calculus gives you a very rich way of
querying for data, subsets of data, supersets of data, according to the
rules of logic. There is nothing comparable to that in the idea of queryng
sets of objects. What you do with the data, once you have it, is up to you.
Database API's that support SQL give you some of the power of the relational
calculus, and all the data comes back with a full set of metadata, the same
metadata as it would come back with if it did come from a "table." You can
bind that data to the properites of objects, you can do so through
introspection and reflection, and you can automate the conversion of types
from database types to class data member types. I know about that :-)
Regards,
Daniel Parker
- Next message: Ron Jeffries: "Re: how many bugs do you find and correct during TDD?"
- Previous message: Sylvia Gardner: "Re: up front designs always useless"
- In reply to: Doc O'Leary: "Re: Queries and OO"
- Next in thread: Doc O'Leary: "Re: Queries and OO"
- Reply: Doc O'Leary: "Re: Queries and OO"
- Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]
Relevant Pages
|
