Re: Queries and OO

From: Dmitry A. Kazakov (mailbox_at_dmitry-kazakov.de)
Date: 01/17/05 

Date: Mon, 17 Jan 2005 10:38:52 +0100

On 16 Jan 2005 09:30:18 -0800, frebe wrote:

>> I'd say that querying is rather about some specific implementation than
>> modeling.
>
> Lets say we have an application for order administration. Wouldn't it
> be necessary to be able to find orders by customer, by delivery date,
> by status, by product and combinations of these criterias? Not having a
> query mechanism would force you to have a lot of maps and sorted sets
> containing the customer objects. And when combined searches are done,
> decisions about in what order to use the containers have to be made.

I do not argue that there might be no applications requiring this.

> Queries is a way to decouple how objects are mapped into a container,
> from how the objects are retrieved from the container. When you are
> making software, new feature request forces you to retrieve objects in
> new and different ways all the time. A hard-wired solution with
> pre-defined search paths is mostly not possible.

I do not see it so. In my view queries is an interface of a container. No
more than that.

>> I might need no queries even if I do use a database.
>
> True, long time ago there were database types without query
> capabilites. It was possible to make working applications in that era
> too. But maybe the query capabilities was one of the reasons behind the
> success story of relational databases.

I'd cynically say that the success should be rather attributed to the poor
performance of RDBS. You know, people prefer poorly performing things.
Consider Windows and UNIX as examples. When you have some technical
problem, you are not responsible for, then you can always explain where you
had pulverized money and resources...

>> What could be so intriguing in a set of tables?
>
> Many application vendors find relational databases and tables an
> extremly important component in their solution.

Right, bigger servers, more staff, more resources. It is very attractive
for any manager...

> If we want the application to collaborate with a database, we should model this too.

What is the problem the application solves? Is the problem collaboration
with a DB, or it is DB used to solve a problem? 

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Relevant Pages

  • Re: Queries and OO
    ... Queries is a way to decouple how objects are mapped into a container, ... long time ago there were database types without query ... But maybe the query capabilities was one of the reasons behind the ... success story of relational databases. ...
    (comp.object)
  • Re: Trouble with sendkeys - Alternative?
    ... One customer can be involved in many sales (but not ... You can then create a query based on your three tables. ... If you want to include the sum of the "Value" columns in a crosstab query, ... Graham Mandeno ...
    (microsoft.public.access.formscoding)
  • Re: Crosstab query by quarter nightmare
    ... The Cartesian query gives every combination of customer and savings in the ... I am getting the same count for each savings. ... So you are recording when a customer came on board. ... So the whole crosstab relies ...
    (microsoft.public.access.queries)
  • Re: [PHP] OOP slow -- am I an idiot?
    ... OOP has overhead. ... That saves you putting wasteful SQL queries in your ... If you need to do a complex query with a couple of joins and such, ... I want to create a "customer" class which fetches its attributes from a ...
    (php.general)
  • Re: Many-to-Many relationship Query
    ... the key value is a text string and not a number. ... FROM Employee INNER JOIN (Customer INNER JOIN ... The following function reads this Query and produces a list of employee names similar to what you asked for. ... EmpByCustAS Employees ...
    (microsoft.public.access.queries)