Re: Business objects, subset of collection

In OO, I would suggest that we also dont have collections of related
data, we have schemas of objects (a set of rules that define the
collection). Schema can also be composite.  In the SQL statement above
as I interpreted it one has a collection of invoices each with
possibly a collection of payments.   The most ideal way of searching
is to go for the one that is easier to find - so if one knows the
payment find that, then transverse to its invoice (like using a
foreign key).   In other words, sometime its better to reverse the
search order given the information known.

A SQL database is very good at doing thing kind of decisions.
Depending on the query and current statistics, it will choose the best
set of indexes to use.

I disagree,  SQL only works if the data has been normalised (ordered)
and the statements are optimised.  

Data should obviously be normalised. SQL works on not normalised data
too, but you risk getting inconsistent data. What do you mean with
optimised statements? Are you refering to statements that can't
utilize indexes, when executed?

It does not work on non-orded,
disjoint data.

Tuples in a relation is non-orderd, so I have a problem understanding
your statement.

In other words its good at lists, but not disjoint patterns.

Isn't this a disjoint pattern?

create table vehicle (
vechicleid integer,
primary key (vechicleid)
)

create table car (
vehicleid integer,
primary key (vehicleid),
foreign key (vehicleid) references vehicle (vehicleid)
)

create table boat (
vehicleid integer,
primary key (vehicleid),
foreign key (vehicleid) references vehicle (vehicleid)
)

Think of it like Bob going into a crowded hall and
shouting out, can Wilma of 43 someplace street please go to the
information kiosk fill in the appropriate form.  Then a short time
later, a faint voice shouts back, ok I am done what next. (this is the
observer pattern)

I order to "shout out" to every object, you need to traverse every
object. The complexity of the algorithm will be O(N). In a SQL
database, with appropriate indexes, most searches will be O(log N).

This is an incorrect assumption.  You simply need to set a flag that
the appropriate items are looking out for.  This is a common way of
implementing an event model.

But the items (objects) have to do some polling? Doesn't every object
need to do the polling? Doesn't that imply O(N). If not, please show
some source code proving the opposite.

So to me in reference to the select statment above, the request is
simply - can everyone who has a sum of money that is now due for
payment, please now execute their request payment routines (remember,
objects contain methods based on their classification as well).  If
one were being smart one could actually provide them a method
invocation to execute - which is called dynamic method invocation.

That means that every object need to calculate the sums and decide if
calling the callback or not. The complexity will be O(N). Using SQL,
you could create a materialized view with the sum columns, create
indexes for them, and you will have O(log N).

Yes, this is correct. Remember that objects contain the code needed to
perform the actions on their own data.  This code is encapsulated in
'methods'.

That is why encapsulating is a bad thing in this case. Since the code
(and data) necessary to tell whether the condition is met or not, are
encapsulated, the only thing to do is to actually ask every object.
And the complexity will be O(N). I have seen many OO geeks building
applications this way, and believe me, it is a disaster.

So I think the techniques in OO are that objects can find themselves,
objects can manipulate themselves and it can all work in parallel.

That is why so many OO applications have such bad performance.

They dont, in general they are usually hacked by a poorly designed
relational database.  Any application both OO and non-OO will suffer

And who did the poor schema design, probably a OO geek? And if we have
a poorly designed schema, the OO geek will say: No problem, I will
separate the schema from the business logic in different layers, and
everything will be OK. The database guy would say: The schema is the
foundation for your application, if you don't fix the schema, the
application will sucks for ever.

//frebe
.

Relevant Pages

  • SQL Adapter Disassembling Result Sets & Dynamic Parameters
    ... properties of the schema returned in my orchestration. ... Also after processing all the records returned by SQL adapter in my ... from the toolbox drag an xml disassembler ...
    (microsoft.public.biztalk.general)
  • SQL Adapter Disassembling Result Sets & Dynamic Parameters
    ... properties of the schema returned in my orchestration. ... Also after processing all the records returned by SQL adapter in my ... from the toolbox drag an xml disassembler ...
    (microsoft.public.biztalk.server)
  • Re: Select Statement with 4 tables help required please
    ... > legal SQL syntax to use the same name for both a table and a scalar. ... > data element name would be used in the entire schema. ... I have a livingroom television and a bedroom television. ...
    (microsoft.public.sqlserver.programming)
  • Split messages
    ... This is based off the northwind database. ... Create document schema: ... Select the SQL entry, make sure that we are pointing to the SQL ... For the item select a receive pipeline and name it EmpSplitPipe.btp. ...
    (microsoft.public.biztalk.general)
  • RE: SQL Adapter
    ... Did you add the SQL schema with the 'Add Generated Items - Add Adapter' wizard. ... Target namespace and Request and Response root element name. ... > have to be inserted in an SQL Database. ...
    (microsoft.public.biztalk.general)