Re: Business objects, subset of collection
- From: frebe <frebe73@xxxxxxxxx>
- Date: Tue, 29 Jan 2008 01:09:47 -0800 (PST)
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?
Optimised as in fast performance.
So what is the conclustion? SQL only works when the statements are
fast? But the statements can execute fast O(log N), so we don't have a
problem. Your solution, on the contrary, perform in O(N).
It does not work on non-orded,
disjoint data.
Tuples in a relation is non-orderd, so I have a problem understanding
your statement.
ordered data, as in it has relation (name address phone),
But the attributes doesn't have to be ordered in that way
insert into employee (phone, name, address) values (...)
disjoint for example (a car and a fish).
Do you claim that the relational model can't model cars and fishes?
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.
Not really, polling would indicate to me the use of the semaphore
pattern, but is not necessarily the only way. The observer pattern
for example using callbacks is another.
So, all items (invoices) are subscribing for events (query requests).
When you want to find all items matching a given criteria (unpaid
invoices), you send a notification to all invoices, and invoices that
matches the criteria executes the callback. Since you need to notify
all items and all items has to execute the criteria evaluation, you
will have O(N). OO philosophy doesn't work on large amount of data.
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.
I have seen many examples of poor application architecture as well.
Its surprising how many developers that will try an emulate the
functionality of an OO database system in an object relational system
without any real knowledge of the features of the OO Db and how to
even implement those techniques if they did know what they were.
The features of a OO database is basically the same as of a network
database. It is surprising that OO people try to reinvent a database
type that have been obsolte for more than 20 years. The lack of sucess
of OO database speaks for itself. It is also surprising to find so
many software developers such ignorant about data management basics.
//frebe
.
- References:
- Re: Business objects, subset of collection
- From: H. S. Lahman
- Re: Business objects, subset of collection
- From: frebe
- Re: Business objects, subset of collection
- From: H. S. Lahman
- Re: Business objects, subset of collection
- From: frebe
- Re: Business objects, subset of collection
- From: frebe
- Re: Business objects, subset of collection
- From: AndyW
- Re: Business objects, subset of collection
- From: frebe
- Re: Business objects, subset of collection
- From: AndyW
- Re: Business objects, subset of collection
- Prev by Date: Re: Business objects, subset of collection
- Next by Date: Re: Why is Object Oriented so successfull
- Previous by thread: Re: Business objects, subset of collection
- Next by thread: Re: Business objects, subset of collection
- Index(es):
Relevant Pages
|
|