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 5 Jan 2008 23:45 > 1. For most of requests an RA description is close to optimal; RA is proven to be very useful for common data management tasks. > 2. SQL is the best way to spell RA requests. No, it isn't. But it is the only availible way in current production systems. > 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] True. Current mainstream SQL databases targets "business applications". But there also exists embedded databases which target applications in other areas. But obviously there are areas which is not covered by current database implementations. > 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. I think you should have made this disclaimer from the beginning. I agree with your that point 4 is a valid argument for not using SQL databases, in some scenarios. But you have been extensivly arguing that relational databases has basic flaws and that other libraries could be successfully used instead of SQL databases, without limit the claims to "my area of interest". "Relational view does deliver" is pretty much true, since the none of the mainstream SQL databases could be considered as relational (http:// myitforum.com/cs2/blogs/dhite/archive/2006/09/10/Codd_2700_s-12-Rules- For-The-Relational-Model.aspx). > As for other things, I am dying to see a UI written in SQL... SQL is a perfect language for reading and writing the GUI data. Lets say you have a combo box. Just write a select statement returning the data in the combo. Also the GUI layout could easily be described using relations, although many of current products used an obsolete hierarchic data model (HTML). //frebe
From: Dmitry A. Kazakov on 6 Jan 2008 04:03 On Sat, 5 Jan 2008 20:45:59 -0800 (PST), frebe wrote: > SQL is a perfect language for reading and writing the GUI data. Lets > say you have a combo box. Just write a select statement returning the > data in the combo. Sure, MVC works nicely for combo boxes and a relational model (but not SQL of course) in place of "M" is perfect there. It becomes a lot clumsier with tree view widgets, as expected. But you forgot about "V" and "C", that widgets are natively hierarchical, as well as signal handling there. > Also the GUI layout could easily be described using relations, I would really enjoy a serious attempt to build a relational widget library. The most difficult problems will be composition of signal handlers and renderers in a flat relational way. The former are hierarchical, the later are spatial. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: Dmitry A. Kazakov on 6 Jan 2008 04:24 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. >> 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 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. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: frebe on 6 Jan 2008 05:58 > >> 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. Who said that it need to be O(n) because you use RA? RA has nothing to do with the physical layer. Which indexes, etc, that is used, is a completely different story. > 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. Bullshit. You can use whatever algorithms you want, in the physical layer. It is up to the database engine implementation. Your statement would be a little bit true, if you very talking about SQL databases, since most of them doesn't support very many index types, and that most SQL database engines doesn't allow you to extend the query optimizer. But it is not true when talking about RA. //frebe
From: Dmitry A. Kazakov on 6 Jan 2008 06:23
On Sun, 6 Jan 2008 02:58:59 -0800 (PST), frebe wrote: >>>> 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. > > Who said that it need to be O(n) because you use RA? I do. > RA has nothing to do with the physical layer. The view limits possible implementations. View is a model, when the model is wrong, there is no implementation possible. When the model is inherently inefficient so will be the implementation. If you believe that RA is the best model for everything, then try to use it for integer arithmetic. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de |