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: frebe on 4 Jan 2008 13:41 > >>>>>> Others > >>>>>> quietly create their *libraries*. They might call them "engine", > >>>>>> "middleware", "framework", but show nothing alike that manic disorder the > >>>>>> former suffer... (:-)) > > >>>>> What libraries are you suggesting instead of a SQL database? Please > >>>>> show me some example. > > >>>> There exist lots of container libraries. > > >>> Please point out one library that could be used instead of a SQL > >>> database for an inventory management application? > > >> As I said, write the requirements. The problem of you and the OP is that > >> you don't care to write the requirements down. Instead of that you think in > >> terms of DB records, i.e. an implementation. The rest follows. In OO one > >> would first identify and describe the things and only then say, "hey, that > >> looks much like a relation!" > > > You claim that it does exists libraries that can be used instead of an > > SQL database, and do the job better. > > Which job? Describe it in the form of requirements. Your failure of showing one single example of such library speaks for itself... //frebe
From: Daniel Parker on 5 Jan 2008 13:48 On Jan 4, 10:44 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> wrote: > On Fri, 4 Jan 2008 07:14:02 -0800 (PST), frebe wrote: > >>>>>> Others > >>>>>> quietly create their *libraries*. They might call them "engine", > >>>>>> "middleware", "framework", but show nothing alike that manic disorder the > >>>>>> former suffer... (:-)) > > >>>>> What libraries are you suggesting instead of a SQL database? Please > >>>>> show me some example. > > >>>> There exist lots of container libraries. > > >>> Please point out one library that could be used instead of a SQL > >>> database for an inventory management application? > > >> As I said, write the requirements. The problem of you and the OP is that > >> you don't care to write the requirements down. Instead of that you think in > >> terms of DB records, i.e. an implementation. The rest follows. In OO one > >> would first identify and describe the things and only then say, "hey, that > >> looks much like a relation!" > > > You claim that it does exists libraries that can be used instead of an > > SQL database, and do the job better. > > Which job? Describe it in the form of requirements. > 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. -- Daniel
From: Dmitry A. Kazakov on 5 Jan 2008 15:22 On Sat, 5 Jan 2008 10:48:57 -0800 (PST), Daniel Parker wrote: > On Jan 4, 10:44 am, "Dmitry A. Kazakov" <mail...(a)dmitry-kazakov.de> > wrote: >> On Fri, 4 Jan 2008 07:14:02 -0800 (PST), frebe wrote: >>>>>>>> Others >>>>>>>> quietly create their *libraries*. They might call them "engine", >>>>>>>> "middleware", "framework", but show nothing alike that manic disorder the >>>>>>>> former suffer... (:-)) >> >>>>>>> What libraries are you suggesting instead of a SQL database? Please >>>>>>> show me some example. >> >>>>>> There exist lots of container libraries. >> >>>>> Please point out one library that could be used instead of a SQL >>>>> database for an inventory management application? >> >>>> As I said, write the requirements. The problem of you and the OP is that >>>> you don't care to write the requirements down. Instead of that you think in >>>> terms of DB records, i.e. an implementation. The rest follows. In OO one >>>> would first identify and describe the things and only then say, "hey, that >>>> looks much like a relation!" >> >>> You claim that it does exists libraries that can be used instead of an >>> SQL database, and do the job better. >> >> Which job? Describe it in the form of requirements. >> > 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; 2. SQL is the best way to spell RA requests. 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. 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] 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Daniel Parker on 5 Jan 2008 20:30 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. > > 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. > > 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. > 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. -- Daniel Parker > -- > Regards, > Dmitry A. Kazakovhttp://www.dmitry-kazakov.de
From: topmind on 5 Jan 2008 22:47
Dmitry A. Kazakov wrote: > 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. In past debates, you assumed a rather limiting/narrow implementation and/or query language. (SQL is not the pinnacle of relational.) I suppose you could state, "existing RDBMS", and I wouldn't necessarily take issue with that. But to say that "relational does not deliver" is misleading. You have NOT proved any inherent fault of relational. Why you continue to repeat these myths, I don't know. Some people are just stubborn. > 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... > (:-)) Most of GUI's are about setting and controlling attributes within some kind of structure that mirrors or models the visible UI. The best way to set them IMO is some kind of GUI editor (found in IDE's these days), or at least a markup language. Internally it could be all table- driven and even use SQL. You seem to be confusing the GUI designer's interface with the implementation (GUI engine). I agree that SQL would make a poor interface for typical GUI layout designing, but so would C, and even Java sucks at it. I see nothing wrong with a table-based GUI engine as far as implementation. (Although I think dynamic relational would be better than the current systems for such.) Most GUI systems are unfortunately tied to specific app programming languages, and this should change. > > -- > Regards, > Dmitry A. Kazakov > http://www.dmitry-kazakov.de -T- |