Re: too much OOP ?
- From: "Dmitry A. Kazakov" <mailbox@xxxxxxxxxxxxxxxxx>
- Date: Sun, 6 Jan 2008 10:24:45 +0100
On Sat, 5 Jan 2008 17:30:10 -0800 (PST), Daniel Parker wrote:
On Jan 5, 3:22 pm, "Dmitry A. Kazakov" <mail...@xxxxxxxxxxxxxxxxx>
wrote:
On Sat, 5 Jan 2008 10:48:57 -0800 (PST), Daniel Parker wrote:
Here's one. As a business analyst, I want to look at all of the data
in a production trading system. I want to look at the data one way,
then another, as a preliminary step in writing requirements. Getting
a SQL database account is a pretty good way of achieving that
objective.
You cannot say that without specifying what kind of requests are planned.
You made three assumptions:
1. For most of requests an RA description is close to optimal;
It doesn't need to be optimal, it just needs to be a practical way of
getting at the data now.
A difference between O(log n) and O(n) might quickly become impractical.
The point is that these things should be analysed before rushing to RA (and
any other algorithmic solution). The problem of specifically RA is that it
is closed, so the class of algorithms you will be able to use is firmly
determined by the choice of RA. That means that the decision has to be made
early and you will have no second try.
3. All other components of the system are negligibly (in terms of
implementation and maintenance costs), and even more generally, that most
of the system functionality is exhaustively described as performing
requests.
If you (from the business side) can avoid having to go through IT,
whether to write code, extract a file, produce a report, etc, you're
better off.
That assumes that you can with SQL, and that there is no other components.
But normally, this is otherwise. You will also need personell training,
which in long term perspective is way more expensive, than designing a
reasonable system interface.
Nevertheless, in case you missed the beginning of this chat, it was not mylow-level is having to put in a request to IT, and waiting ... high
point, that SQL database should never be used. My point was that designing
the system in terms of records updates is low-level.
level is submitting a request to the order desk for a SQL database
account, downloading some free generic tool for applying logical
operations against the data, data that the tool knows nothing about,
except that it conforms to standards.
That depends on the meaning of "request." When request is spelt so that the
user understands it in terms of his domain, then it is high level
relatively to the implementation strata (and low level for the user), that
is how it ideally should be.
--
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de
.
- Follow-Ups:
- Re: too much OOP ?
- From: Daniel Parker
- Re: too much OOP ?
- From: frebe
- Re: too much OOP ?
- References:
- Re: too much OOP ?
- From: frebe
- Re: too much OOP ?
- From: Dmitry A. Kazakov
- Re: too much OOP ?
- From: frebe
- Re: too much OOP ?
- From: Dmitry A. Kazakov
- Re: too much OOP ?
- From: frebe
- Re: too much OOP ?
- From: Dmitry A. Kazakov
- Re: too much OOP ?
- From: frebe
- Re: too much OOP ?
- From: Dmitry A. Kazakov
- Re: too much OOP ?
- From: frebe
- Re: too much OOP ?
- From: Dmitry A. Kazakov
- Re: too much OOP ?
- From: frebe
- Re: too much OOP ?
- From: Dmitry A. Kazakov
- Re: too much OOP ?
- From: Daniel Parker
- Re: too much OOP ?
- From: Dmitry A. Kazakov
- Re: too much OOP ?
- From: Daniel Parker
- Re: too much OOP ?
- Prev by Date: Re: too much OOP ?
- Next by Date: Re: There is some way to stop the "M15" spam?
- Previous by thread: Re: too much OOP ?
- Next by thread: Re: too much OOP ?
- Index(es):
Relevant Pages
|