Relational database & OO
in [OOP]
|
From: topmind on 6 Nov 2006 12:43 Matt McGill wrote: > topmind wrote: > > > The answer depends a great deal on the application itself. There is > > > nothing intrinsically wrong with dealing directly with table data; > > > indeed, that is often the simplest solution. On the other hand, > > > complex applications often need to have complex behavior associated > > > with the data, and so objects become important. The objects are > > > sometimes related to the relational tables, but often they are not. > > > > This is an OOP myth. Often much or most of the behavior CAN be > > converted into a declarative form (data). > > > > For an extreme example, a brain could be more or less modeled with a > > schema such as: > > > > table: Links > > ================= > > sourceNode_ID > > destinationNode_ID > > weight // weighting factor, can be negative in some models > > > > table: Node > > =============== > > node_ID > > activationFuncIndicator // see note > > activationWeight // the "volume" given to activation function > > > > There are about 5 activation functions in common use: unit_step, > > sigmoid, piecewise_linear, gaussian, and identity. (I haven't reviewed > > my schema model closely, so buyer beware. This model allows "Y splits", > > which real neurons don't directly allow IIRC, but can be modeled with > > explicit neurons such that they are still interchangable.) > > All you've done is represent the relationships between the neurons and > a couple weights. Assuming you had inserted the data for every neuron > in your brian, and each interconnection, into your tables. Would the > RDBMS suddenly start establishing network connections and posting > inflamatory comments to usenet? Or would it just sit there, waiting to > be queried? You are correct that the RDBMS (or DBMS) would not "run" actual progression of activity. A seperate "propogation engine" would be needed. But that is generally treated as an implimentation detail seperate from the data modeling and/or data filling (configuration) step. This allows for a nice *seperation of concerns*. A more practical example may be a GUI and GUI event engine. The app developer does not have to concern themselves with the implementation details of GUI event engine; they just set the appropriate attributes (asuming the IDE does not do it). One can do this with OO also, but it is not encouraged and gets confusing because the separation of data and behavior is often fuzzy, and often turns OOP into a roll-your-own database-like thing anyhow (a navigational one) where one has to invent query languages etc. to inspect stuff. I liken attribute-driven programming to a player-piano roll: punching the holes in the roll for a particular song and implementing the roll reader and player system are seperate concerns. It allows one to mentally split the problem into fairly clean partitions. The one filling in the brain info above for a particular personality does not have to concern themselves with implementing neurons. And, I would hate to have to track all that stuff without a DBMS of some sort (relational or otherwise). There are standardized, well-understood tools to manage attributes and collections, but the same is NOT true of behavior. This is probably the biggest flaw of OOP in my opinion. In order to mix behavior and attributes (or hide the difference), OO has to take itself down to the lowest-common-denominator between behavior and data handling. Attribute-centric programming, on the othe hand, converts much more of the app into attributes so that off-the-shelf attribute management systems (DBMS) can be used for a larger part, saving a lot of wheel-reinventing. This also provides consistency over roll-your-own found in OO classes. Collection-handling and attribute handling are largely built-in to a DBMS such that one does not have to impliment getX, deleteX, findX, sortX, sumX, saveX, findXwhereYisPinkOnEvenSundays, etc. for each and every entity. This comes out-of-the-box. OO does not factor commonly-needed collection and attribute handling issues properly: every shop reinvents the wheel, and differently. OO results in messy shanty-town designs with cables, wires, and corridors going every which way, depending on the mood of the shanty'd family. Centralized governed city planning may be boring, but it works! (I agree that existing DBMS could use improvements. I wish there were more experiments in that area. But even with their flaws, they usually beat OO.) > > The data about connections and weights doesn't represent behavior, it > assumes its existence elsewhere. If you don't write some code to > activate some neurons, run queries to find connected neurons, apply the > activation functions (which would themselves need to be implemented in > code), and repeat, then nothing happens. You've not made any behavior > declarative. In fact, you've effectively provided an example for > Martin's argument - the logic which would be necessary to drive a brain > simulation off of the data in these tables could be encapsulated in > Neuron and NeuronLink objects, which get their data (weights and > function indicator) from the tables and then do the right things with > them. Those objects could then be used as part of a larger simulation > involving sensory organs, nerves, muscle tissue, etc. You don't /have/ > to use objects naturally. You could use structured programming just as > well. > > -Matt McGill -T-
From: Matt McGill on 6 Nov 2006 16:58 topmind wrote: > You are correct that the RDBMS (or DBMS) would not "run" actual > progression of activity. A seperate "propogation engine" would be > needed. But that is generally treated as an implimentation detail > seperate from the data modeling and/or data filling (configuration) > step. This allows for a nice *seperation of concerns*. You, sir, are a genious. OO is obviously ridiculous because it entails messy details like 'behavior,' which can be really hard to express clearly. If those silly OO guys would just stick to relational models, things would be so much simpler! Thank you for making this clear. The future of software development is handing some intern an enormous ERD and saying: "Take care of those implementation details for me. And make me some coffee." -Matt McGill
From: Robert Martin on 6 Nov 2006 18:49 On 2006-11-06 15:58:01 -0600, "Matt McGill" <matt.mcgill(a)gmail.com> said: > The future of software development is handing some intern an enormous > ERD and saying: "Take care of those implementation details for me. And > make me some coffee." Cream and sugar? Or just black? -- Robert C. Martin (Uncle Bob)??| email: unclebob(a)objectmentor.com Object Mentor Inc.? ? ? ? ? ??| blog:??www.butunclebob.com The Agile Transition Experts??| web:???www.objectmentor.com 800-338-6716? ? ? ? ? ? ? ? ??|
From: Patrick May on 6 Nov 2006 21:30 Robert Martin <unclebob(a)objectmentor.com> writes: > On 2006-11-06 15:58:01 -0600, "Matt McGill" <matt.mcgill(a)gmail.com> said: > > The future of software development is handing some intern an > > enormous ERD and saying: "Take care of those implementation > > details for me. And make me some coffee." > > Cream and sugar? Or just black? I like my interns the way I like my coffee. Ground up and in the freezer. Regards, Patrick ------------------------------------------------------------------------ S P Engineering, Inc. | Large scale, mission-critical, distributed OO | systems design and implementation. pjm(a)spe.com | (C++, Java, Common Lisp, Jini, middleware, SOA)
From: frebe73 on 7 Nov 2006 00:14
> > Queries (or predicate logic) is the first obvious one. When OO people > > separates SQL statements into a dedicated layer, they also try to limit > > the number of distinct SQL statements because the burden or modifying > > interfaces for every new statement. The consequence is that rather > > simple select statements are used and additional filtering is done in > > the application. This will hit performance and reduce maintainability > > of the application. > > So the problem here would be that SQL statements are being seperated > out into a layer or particular module, and that the task of maintaining > the interface for that layer or module causes OO programmers to > artificially limit themselves to simple queries. Being thus limitted, > they start performing join and selections in-memory on the query > results, when more complicated queries could have done those things > much more efficiently. Correct? Yes. > I can see how maintaining such a data access layer by hand might > predispose OO developers to use SQL in a naive way, or implement > functionality in-memory that a query could have given for free (doing > selections or joins this way could end up being particularly > disasterous). But when making use of an ORM framework, you don't need a > hand-created data access layer at all. Moreover, you get (at least with > Hibernate) an object-aware query language which, while limitting in > some ways (you can only join on mapped relationships, for example), is > actually more flexible than straight SQL in other ways (polymorphic > queries). What is the difference in using HQL strings instead of SQL strings? While I am not an expert in HQL I think most people agree that HQL is more limited than SQL. All modifications in the HQL language seem to make it more like SQL. Besides SQL has a rather high degree of standardization. The level of standardization for HQL is zero. You are entirely limited to one product. > I'm not trying to claim HQL (Hibernate's query language) is the > greatest thing since sliced bread - it has to be used with care. But > when it /is/ used correctly I think there are some benefits over SQL. SQL is not the best possible relational language. I am hoping that some day database vendors will agree upon a more modern language. The strange thing is that HQL copies all the bad syntax from SQL. Why don't the Hibernate guys make something new and modern instead? But my main objection against HQL is that it is not a relational language. Instead it is a strage mix between a network database language and a relational language. > > Caching is the second issue. Because OO people want to play with an > > object graph instead of predicate logic, they need the graph or parts > > of it to be virtually in memory all the time. This will very quickly > > lead to huge RAM consumtion, unless you use caching in your > > application. The DBMS already do caching for you, which synchronizes > > the cach with transactions and handles all concurrency issues. But if > > you try to do application caching, the realibility of the cached data > > will be rather low. > > I'm not sure I follow. My experience has been with multi-user web > applications, so the goal is typically to pull only those parts of the > object graph into memory that are actually necessary, and to keep them > there only during the processing of a request. That is a good design rule. But I have seen examples of the opposite too, motivated by that it is "more OO". > If you let the instances > (which are /not/ shared between threads, as you indicate below) hang > around in memory for long periods of time, the data goes stale. That is the problem, but that doesn't stop OO people from doing it. > My understanding is that for many (most?) database-backed applications, > the database resides on a different server than the client of the > database (whether that client is a web/application server, or > individual client machines). The database's caching helps to mitigate > disk access times, but there's still the network overhead of > transferring the data to the client of the database. If the database and application/web server resides on different boxes, it is very important with a fast network connection between. Application caching has so many disadvantages that this has to be avoided. I can't see any real reasons why the application and database server should be connected by a slow network, normally the boxes are standing next to each other. My recommendation is to have the DBMS and application server in the same box or even in the same process. > Hibernate, on the other hand, has some sophisticated caching mechanisms > built in. The actual cache functionality is supplied by third-party > cache libraries, and you can take your pick (there are a bunch). I > agree that rolling your own would be a dumb idea, but there's no reason > to. The RDBMS already have sophisticated caching mechanisms built in. Hibernate can not beat it. > Even better, transaction demarcation can be done declaratively rather > than programmatically, with a little AOP. If I want some class's > saveChanges() method (which will modify 'persistent' objects) to be > transactional, I don't even have to begin/commit the transaction in the > code, and remember to catch exceptions and roll back. Frameworks like > Spring provide helpful proxy classes which can be configured to > intercept method calls and do such things for you. You actually get > much more than this - you can state that certain methods may only be > called /within existing transactions/ for example, or vica versa. I also use implicit transactions. My SQL-based approach does not stop you from using spring beans at all. (Another solution is to put transaction start and ending in a web filter.) > I disagree that OO applications like to share state between threads. > Hibernate is designed specifically /not/ to do this (a Hibernate > Session is not a thread-safe object - each thread creates its own > Session, those Sessions are independent, and they would return > different instances when queried for the same sets of objects). Do you > have a specific example that led you to conclude this? As soon as you use caching, you share state between threads. > A view every time a SQL statement is repeated more than once, though? I > understand the bit about encapsulati |