Relational database & OO
in [OOP]
|
From: Dmitry A. Kazakov on 4 Nov 2006 09:42 On 3 Nov 2006 14:14:29 -0800, aloha.kakuikanu wrote: > Matt McGill wrote: >> Evidently >> 'persistence' evokes very different concepts in my mind and in yours, >> perhaps as a result of different development backgrounds? Anyway, I'm >> going to stop cluttering this thread. > > Persistence is a significant idea from a programmer perspective who is > unfamiliar with database management fundamentals. "You can save a > subgraph of your program's object spaghetty into a file and it can > outlive the program!" Wow, what a big deal. > > In relational world you deal with logical concepts, and lifetime > doesn't apply to logical entities. This is of course wrong. Persistence addresses not time, but scope. If the scope is bound to time, that makes the thing "real-time," which alone is unrelated to persistence. > The predicate "John was married to > Kathy in 2005" may be a valid statement or not, but anyhow its validity > is independent of the puny artifact whether your application is > currently running or not. That depends on the scope again. In a different scope the predicate might turn worthless, wrong or illegal. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de
From: H. S. Lahman on 4 Nov 2006 11:10 Responding to AndyW... >>>I agree with the solution, but I really think one is talking about a >>>Persistant Storage Engine (PSE) rather than perhaps an OO database. A >>>PSE can often be implemented using an object schema or RDB model. >> >>That's fine. In fact, it is one of the advantages of the approach I >>proposed. It really doesn't matter to the time management problem >>solution whether the data is persisted in an RDB, an OODB, flat files, >>or clay tablets. The persistence mechanisms are fully encapsulated in >>the DB Access subsystem. So one could regard the DB Access subsystem I >>proposed as being a PSE from the perspective of the problem solution. >> >>Among other things, that allows one to change one's mind about how the >>data is stored without having to touch the problem solution in any way. >> All one needs to do is replace the DB Access subsystem underneath the >>same subsystem interface. >> >>Another advantage is reuse. Once one starts to abstract a DB Access >>subsystem for, say, the RDB paradigm, one quickly realizes that the >>abstractions are things like Schema, Table, Tuple, Query, etc. that are >>quite generic. So one can reuse the DB Access subsystem across >>applications with relatively little extra effort. (All one needs is an >>identity mapping between the problem solution and the RDB artifacts, >>which is easily described in configuration data for a particular >>application.) In fact, RAD IDEs are based upon exactly that sort of >>problem-independent reuse. > > > I would agree but again to me its still really at the end of the day > talking about relational issues ant not OO ones. Persistance to me > immediately evokes the need to be storing data - once that separation > is made, then one I think is in the relational world, no matter what > else they choose to believe (although this is not a bad thing). I argue that the DB Access subsystem needs to deal with the particular persistence mechanisms that are at hand. The abstractions one needs to do that will be different for flat files (file/Line), RDBs (Table/Tuple), OODBs (Object/Relationship), or whatever. The situation is analogous to a UI where one uses Window/Control abstractions for a GUI and Page/Section abstractions for a browser. In addition, one needs to optimize differently for each paradigm and appropriate abstractions facilitate that. However, within the context of a particular persistence paradigm, one should be able to provide subsystem reuse across all applications that happen to use that particular persistence paradigm. OTOH,... >>I would also argue that modern RDB or OODB engines are not as portable >>as the vendors would have us believe. Each vendor has their own SQL >>extensions or whatever. And they each have their own unique quirks that >>need to be addressed in the way the data is accessed for optimal >>performance. So even when one just changes vendors within the RDB >>paradigm or the OODB paradigm, one may have to do some tweaking and that >>should be isolated from the problem solution code. >></aside> > > > I agree with the portability thing to be honest, unless the database > is kept very simple and genereric, its often better to just have the > simple API that sits on top of a plug-in architecture. > > I sometimes use CORBA IDL to describe a problem because I can look at > it from the client side and see the OO and business mechanism being > expressed or I can look at it from the implementation side (server > side if you will) and see the often non-OO details. > > Here is a basic example that you may find in a customer care & > billing system. > > > Module CustomerAccount { > typedef float Account_balance; > typedef float Amount_value; > > interface Account { > exception NoFunds {...} > exception TransactionError {...] > > void Withdraw( in Amount_value someAmount ) > raises NoFunds; > > void Deposit( in Amount_value someAmount ) > raises TransationError; > } > > interface ServiceAccount : Account {...} > interface ConsumerAccount : Account {...] > > struct AccountDetail { > Customer customer; > AccountType typeOfAccount > Account account; > etc. > } > typedef sequence<AccountDetail> customerAcounts; > } > > I've left out the customer definiton, but in all general purposes its > a list of client accounts, each one contains a customer (billing and > contact details) and an account (which can be of any type depending on > your business structure. > > Now, from the implementation side - there is no persistance, thats > where the OO side of things really shines thru. The developer in > america or the one in japan who may be implementing this have no > knowledge of the technical detail behind the interface they are > looking at. All they see is business functions (in their programming > language of choice). > > This is the level that I prefer to work at - in other words - I sweat > the detail later and to me is a benefit of OO. That's fine too. Note that the DB Access subsystem is free to use such generic mechanisms. That would make the DB Access subsystem even more reusable -- so long as one doesn't run into a situation where CORBA isn't available. B-) The advantage still remains that the subsystem interface is defined in terms of the particular application solution's needs and doesn't even have this level of dependence on the persistence access mechanisms. > However, the developer who is working on the implementation side > (unfortunately and confusingly called a server in corba terms) which > may be located in the UK, gets to see the detail behind the scenes. > Now they may be using a persistance storage engine, it may be a > relational database, or, if a telco solution, it actually may be an > interface to a real time billing system and may not have a database at > all (thats in this context). > > Now from the client side point of view, they may be just trying to get > a list of customers who belong to a business entity, display the list > on the screen, then allow the CSR to see that customers real time > billing detail. The programmer may figure that the customer data has > come from a local database, but might no
From: sjdevnull@yahoo.com on 4 Nov 2006 12:56 frebe73(a)gmail.com wrote: > > > Embed all the SQL in java code, because it is the most simple, > > > readable and easily maintainable way to program database application. > > > > This doesn't make sense to me. If you're going to take the time to > > force all your database calls through one language, you're better off > > just doing an full mandatory database layer from the start without > > embedded SQL calls. > > This doesn't make sense to me. What different languages are you > talkning about. Who is talking time to forcing anything. I'm talking about whatever language(s) your application is written in. I think there was some confusion here. If you substitute "application code" for "java code" in your statement above then I'm in agreement with you. I have, however, worked places that mandated all database access go through Java code (even access from non-Java programs); while there are sometimes reasons for such a stipulation, I certainly wouldn't say it's the easiest, most readable, most maintainable way of doing things in general.
From: Matt McGill on 4 Nov 2006 13:59 frebe73(a)gmail.com wrote: > In that case, calling object.setSomething(data) is also about > "storing". Actually a program is all about storing, because you store > data in different variables all the time. In other words, "store" is > not a very useful word in this context. I didn't introduce the word > "store" in this thread. That's kind of what I had in mind - I meant 'storage mechanism' to mean something which can be used to selectively obtain references to objects when they need to be used, and to which objects can be tucked away until they're needed again. An ORM framework sitting on top of an RDBMS often does that job. But you're right on both counts - you didn't use the term initially, and it probably wasn't a good choice on my part. I haven't, in general, done such a hot job of communicating clearly in this thread, have I? Communicating well is a skill, and I'm still learning it. Thanks for your patience. Just so I have things straight in the future: when you're talking about persistence, you're talking about the means by which data is moved to a persistent storage medium, like a hard disk? I was talking about a way of treating object instances as if they exist independent of any particular running process. So they would be 'persistent' in the sense that they stick around (conceptually, at least) until they are explicitly destroyed (and terminating the process which created them does not count as explicit destruction). > Everybody with a solid background using RDBMS knows that a RDBMS is > about much more than persistence, and would still use a RDBMS even if > persistence is not needed. Many people from OO-land implements a lot of > data management features by them self in every application, instead of > using the features already provided by the RDBMS, and uses the RDBMS > only for persistence. If you want to, I can give you real-world > examples with the various downsides with this approach. I would certainly agree that re-implementing RDBMS features in application-level code would be A Bad Thing. But it seems to me that if those of us in OO-land can avoid making that mistake and instead rely on those features (here I'm thinking particularly of ACID transactions and query capabilities), we can achieve useful results. In the interest of identifying things which OO people should /not/ do, can you post what you would consider to be a particularly pathological example of inappropriately re-implementing the data management features an RDBMS provides for free? -Matt McGill
From: topmind on 4 Nov 2006 23:51
Robert Martin wrote: > On 2006-11-01 19:52:37 -0600, ajspowart(a)gmail.com said: > > > My question relates to good design when it comes to creating an OO > > application that uses a relational database to store most of its data, > > how do people go about designing and storing the data once it has been > > retrieved from the database? Do you keep it as records, or when you get > > the data, do you create collections of objects which represent the data > > which you have obtained from your database? > > > > I am wanting to create an application that is for time management and I > > want most of the data to be on my webservers database, but in creating > > my OO 'client' I really want to create a good design. > > > > Anthony > > 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.) > > Keep this in mind. Relational tables contain data in a behavior > independent way. Objects express behavior in a data independent way. > This is not to say that there isn't behavior implied by the relational > tables, or data implied by the objects. Rather those implications are > kept abstract. The behavior implied by the relational tables could be > written in any language an in any form. The data implied by the > objects could be expressed in any of a menagerie of different forms. > > So, here's the trick. Start out simple and just use table data. > Create objects only when you need to. For example, you may need an > object to help you isolate your application to make it testable. Or > you may need an object to make your application more generic. > -- > Robert C. Martin (Uncle Bob) | email: unclebob(a)objectmentor.com -T- |