Re: Business objects, subset of collection

invoiceSet = this -> R1 WHERE (date=20080113)
FOREACH invoice IN invoiceSet
    // process invoice objects
or
select invoiceid from invoice
where customerid=? and date=20080113
paymentSet = this -> R1 -> R2 WHERE (date=20080113)
FOREACH payment IN paymentSet
    // process payment objects
or
select paymentid from invoice i join payment p on
i.invoiceid=p.invoiceid
where customerid=? and p.date=20080113
Yes, they are quite similar. But apropos of your other message, that
just reflects that both are based on the relational model. However, the
models are quite different because the collection sets are object-based
in the AAL but they are table-based for the SQL. The set of invoices and
the set of payments examined in the AAL case will usually be much
smaller that the corresponding invoice and payment sets in the RDB.

That is a limitation you have to do, because your solution will
perform too bad otherwise. A relational database on the contrary isn't
limited to only operate on small amounts of data.

We do this because using the RDB query model with table-based indices
would be very inefficient for memory-based computing when solving
particular problems.

I solve particular problems using "the RDB query model" every day, and
I have not noticed it being "very inefficient".

That paradigm is fine for generic data storage and
access but searching large sets sucks for algorithmic processing.

SQL databases sucks for searching large data sets, come on...

But the 'n' in
O(log n) will usually be much smaller in the OO application because the
collections are object-based rather than class-based.

Lets say you want to find all unpaid invoices. Why would the n be much
smaller in a OO solution?

I said, "usually'. You are postulating a class-based search as a problem
requirement.

You might think that my example is too extreme, but isn't it good to
use a method/tools that doesn't limit you to work on small amounts of
data?

Again, did you miss the part where I said the OP might be able to save a
bunch of keystrokes by not doing OO? Where I said that RAD
infrastructures provide a lot of automation that would have to be done
from scratch in an OO approach?

No, I just love to see you repeating this disclaimer...

[Note that I also never said one shouldn't take advantage of the RAD
facilities. One should do that in a client-side data access subsystem
where the RDB schema is relevant. But when customizing the problem
solution data structures one needs to provide the access to those data
structures anyway and one needs to do it efficiently through custom
tailoring.]

Your main argument seem to be that the performance of a relational
databases should be insufficient, compared to your pointer based
solution. There are probably many scenarios there a pointer-based
solution would perform O(1) and a relational O(log n). But history
(and your previous posts in this thread) has showed numerous
disadvantages with data management using pointers (network databases),
and the benefits with the relational model are obvious. These days,
nobody are proposing pointer-based databases, only when it comes to
data in RAM, some people are still proposing this. What if RAM isn't
big enough for the data needed in the processing? Recently I worked
with an (OO) application loading data from database at startup. I
guess I don't have to tell you the problems the applications faced.
One was a startup-time of +6 hours. Another was dirty reads.

A SQL database allows him to construct CRUD/USER applications quickly
because the only problem being solved is data view conversion. That is
exactly what the Form/Query/Table RAD paradigm is designed to largely
automate and it does a good job of it.

But when you have a problem to solve that requires complex processing of
the data, you have to optimize to the problem and provide custom data
structures. IOW, you are going to have to provide unique access because
the mappings are not the same as in the RDB schema. That's what
application design is all about outside of CRUD/USER contexts.

Are producing invoices, "complex processing"? There are scenarios of
data processing that are not supported very well by existing index
types in current mainstream (SQL) databases. But the major part of all
processing done in common business applications, perform very well
using SQL databases, without having any custom data structures. What
about all COBOL applications out there with extremly simple data
structures, relying heavily on SQL statements to do the job. Doesn't
they perform well enough?

Your claim that a relational schema is designed for "data storage that
is independent of the applications", is debatable. When I design
schemas, I design them to fit the specific customer problem. Why
wouldn't I? If you look at the schemas for three different invocing
applications, you will find three different schemas. There doesn't
exists any application independent schema for invoices. It all depends
on the specific customer problem.

IMO, that is very bad practice for a DBA because it precludes reuse of
the data to solve other, different problems.

My databases solves problems for my applications. Between
applications, data are exported and imported.

When one creates a Data Model, it should be based on the overall problem
domain rather than specific problems within the domain. If you do that,
then the same schema should be reusable by all the core accounting
applications.

One could also say that it only need to be one core accounting
application. The question is: How do you define the "overall problem",
and the "specific problem". You base almost all your argumentation on
such fuzzy terms, which makes everything derived from it rather fuzzy
too.

//frebe
.

Relevant Pages

  • Re: Business objects, subset of collection
    ... FOREACH invoice IN invoiceSet ... FOREACH payment IN paymentSet ... Why do you think that designers of large, complex applications spend so much effort trying to minimize persistence access, regardless of whether they are doing OO or not? ... you have to optimize to the problem and provide custom data ...
    (comp.object)
  • Re: Business objects, subset of collection
    ... with amount due, payment total, etc. ... for the selected vendor ... I think one way to express my point is that the filter is the WHERE clause and one specifies the attributeto be checked in it. ...
    (comp.object)
  • Re: Business objects, subset of collection
    ... from invoice i join payment p on i.invoiceid=p.invoiceid ... locating an invoice. ... composite key based on the sum of all of the attributes and methods at ... A SQL database is very good at doing thing kind of decisions. ...
    (comp.object)
  • Re: Getting Data from 2 Queries into 1 Report
    ... the Payment in a one-to-many relationship. ... to something else that generates your actual invoice and that you may ... the Primary Key of the 'one' table. ... don't include any Lookup Fields! ...
    (microsoft.public.access.gettingstarted)
  • Re: credit card reciept response
    ... transaction is submitted for processing. ... to the consumer or a POST string to a site designated by the merchant. ... Here you accept the POST data, validate it, and mark the invoice ... DO NOT send any order details back to the payment ...
    (comp.lang.php)