Re: too much OOP ?
- From: Daniel Parker <danielaparker@xxxxxxxxx>
- Date: Sat, 5 Jan 2008 17:30:10 -0800 (PST)
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.
2. SQL is the best way to spell RA requests.
Don't know about the best way, but the worst way is to make a request
to IT for data. From the business side, if you can bypass IT and get
at the data yourself, you're better off.
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.
4. The non-functional requirements allow deployment of an SQL database as
the platform, or even as a component (and where is the rest?) [Such as
memory constraints, real-time constraints, mobile distributed components,
lag and blackout periods, security, safety etc]
In the assumed problem space, the SQL database already exists.
low-level is having to put in a request to IT, and waiting ... high
Any or all of these four assumptions can be wrong. As I said, I know
nothing about inventory management, but in my area of interest relational
view does not deliver. This can be stated and proved mathematically. After
all the algorithms behind SQL implementations are well known. It is also
know when they are optimal and when not... SQL as a language speaks for
itself... As for other things, I am dying to see a UI written in SQL...
(:-))
Nevertheless, in case you missed the beginning of this chat, it was not my
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.
-- Daniel Parker
--
Regards,
Dmitry A. Kazakovhttp://www.dmitry-kazakov.de
.
- Follow-Ups:
- Re: too much OOP ?
- From: Dmitry A. Kazakov
- 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 ?
- Prev by Date: Pattern for multiple States
- Next by Date: Re: Pattern for multiple States
- Previous by thread: Re: too much OOP ?
- Next by thread: Re: too much OOP ?
- Index(es):
Relevant Pages
|