too much OOP ?
in [OOP]
|
Prev: Should class code access private members or public wrappers for those private members?
Next: Should class code access private members or public wrappers forthose private members?
From: Daniel Parker on 6 Jan 2008 14:38 On Jan 6, 4:24 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > On Sat, 5 Jan 2008 17:30:10 -0800 (PST), Daniel Parker wrote: > > On Jan 5, 3:22 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > > 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. Notice that in every one of your replies, you're moving away from the problem space that I defined. In my problem space, applications already exist, some with SQL interfaces, others without. These business users are better off with the applications with SQL interfaces, because they can get to the data without going through IT. > > >> 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. Hey, I look around, and I see six business users who are quite able to write their own queries, these are people who have mastered Excel, for God's sakes, SQL is easy... Training? What training? People pick up what they need to know themselves. Anyone who can get a PhD in mathematics or finance can easily pick up SQL. What's hard for them is setting up the connectivity to the databases, those JDBC connection strings, but there's someone around who knows how to do that. > > >> 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. > > > low-level is having to put in a request to IT, and waiting ... high > > 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. > Think about it, Dimitry. I can download a free tool off the internet (e.g. DataVisualizer) that knows nothing about a production application, and use it to navigate through the all the data of that application, I can get a list of all the swap trades belonging to the LONDON book that have indexes with floating rate multipliers not equal to one, extract them and load them into Excel for further analysis. I can do this because the production application stores data following standards, the free tool knows about the standards, knows how to get at the metadata describing the data, and submit queries based on mathematical logic against the data. This is not really about SQL. It is about an approach to software, based on logic, metadata and standards, and SQL is just one of the _BIG_ early success stories. This is the direction that software is going, not class A implements I etc., etc., etc. -- Daniel
From: Dmitry A. Kazakov on 6 Jan 2008 15:09 On Sun, 6 Jan 2008 09:49:26 -0800 (PST), frebe wrote: >> The point stands, even for ordered sets, relational may turn bad. > > And as said before, relational calculus can use any operator on any > domain (type). I am not sure what you are trying to claim here. That > an expression like a*b can't be used in relational calculus? Right. You can use the result of, but you cannot use the expression itself. It cannot be reasonably implemented in RA. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 6 Jan 2008 15:09 On Sun, 6 Jan 2008 10:00:37 -0800 (PST), frebe wrote: > But > your point seem to be that since you can't tell the complexity from > the source code, the model is flawed? Exactly. I don't board an aircraft without wings. Who knows, maybe it has an anti-gravity relational engine inside, but I better take no chances. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 6 Jan 2008 15:31 On Sun, 6 Jan 2008 11:38:30 -0800 (PST), Daniel Parker wrote: > People pick up > what they need to know themselves. Anyone who can get a PhD in > mathematics or finance can easily pick up SQL. Where is that place where customers with PhD in mathematics grow? (:-)) -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: topmind on 6 Jan 2008 18:39
On Jan 6, 12:31 pm, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > On Sun, 6 Jan 2008 11:38:30 -0800 (PST), Daniel Parker wrote: > > People pick up > > what they need to know themselves. Anyone who can get a PhD in > > mathematics or finance can easily pick up SQL. > > Where is that place where customers with PhD in mathematics grow? (:-)) > There's techniques, such as Query By Example along with a few other tricks (sets and/or logic groups) that allow people to design fairly complex queries without knowledge of SQL. Such is not as powerful as SQL, but can come fairly close if you know the tools well. > -- > Regards, > Dmitry A. Kazakovhttp://www.dmitry-kazakov.de -T- |