Relational database & OO
in [OOP]
|
From: aloha.kakuikanu on 3 Nov 2006 17:14 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. 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. Therefore, all what database system does is maintaining an environment where customer can query such predicates. Now, it is up to database vendors how faithfully they do this job. If customer cares about quality of ther data, e.g. minimal chances of data lost, no phantom data, etc, then they would likely to choose traditional database vendor. If they have lesser requirements, they could choose a vendor who sacrifices data quality in favor of other features (cost, speed, etc).
From: topmind on 3 Nov 2006 17:32 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. 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. Therefore, all what database system does is > maintaining an environment where customer can query such predicates. > Now, it is up to database vendors how faithfully they do this job. If > customer cares about quality of ther data, e.g. minimal chances of data > lost, no phantom data, etc, then they would likely to choose > traditional database vendor. If they have lesser requirements, they > could choose a vendor who sacrifices data quality in favor of other > features (cost, speed, etc). That is more or less the "Big Iron" view of RDBMS. I used to use a lot of XBase (dBase derivative), and it made creating, managing, and using app-level tables quite easy. I didn't have to worry much about RAM/Disk dichotomies: it cached what it could automatically. Unfortunately, tools moved away from "nimble tables" because OO was supposed to replace all that. Well, OO stunk at it and I want my nimble tables back. Radio Killed the Video Show. It changed the way I think about programming. Tables are not something to hide/wrap away in a formal closet, but fantastic tools when used and implimented right. -T-
From: AndyW on 3 Nov 2006 19:06 On Fri, 03 Nov 2006 21:16:59 GMT, "H. S. Lahman" <h.lahman(a)verizon.net> wrote: >Responding to AndyW... > >>>Solving a time management problem is a quite different subject matter >>>than persisting the relevant data. Solve the time management problem in >>>you application first. Then, when you know what object attributes need >>>to be persisted, define a suitable Data Model for the database. The RDB >>>Data Model and the solution's Class Model will typically be different >>>for non-CRUD/USER applications because they need to be optimized >>>differently. >> >> >> 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 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. 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 not be aware that the $59.50c that the customer currently owes is produced by a real time billing sytem over in Hong Kong (ok, I know it will be slow - this is just an example). From the server side, its time to sweat the detail - this is where the plug-innable architecture works for the server side stuff. What brand of RDB/ODB cluster is used and how its used, or if another system is being interconnected to (and requires an interface in SOA terms). It doesnt even have to be an OO system at the back end. Procedural or RPC functions may be good enough. To answer the orginal question, to me, working with an OO database is like working as the client programmer in the example above. Using a relational database to me is like being the server side programmer in the above example.
From: Robert Martin on 3 Nov 2006 21:35 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. 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 Object Mentor Inc.? ? ? ? ? ??| blog:??www.butunclebob.com The Agile Transition Experts??| web:???www.objectmentor.com 800-338-6716? ? ? ? ? ? ? ? ??|
From: Robert Martin on 3 Nov 2006 21:39
On 2006-11-02 15:17:45 -0600, "aloha.kakuikanu" <aloha.kakuikanu(a)yahoo.com> said: > Keep it simple. Write a minimal amount of code that transfers the > information from the database to the GUI. Don't create classes unless > you really forced to. Ignore all the temptations to design for "future > extensibilty" -- just admit you don't have crystall ball to know the > future. Embed all the SQL in java code, because it is the most simple, > readable and easily maintainable way to program database application. This is very good advice. I would add the DRY principle. "Don't Repeat Yourself" (See "The Pragmatic Programmer" by Dave Thomas and Andy Hunt). For example, if you find yourself building the same SQL query in more than one place, or a similar query, then consolidate that code into a single module, which will probably be a class. -- 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? ? ? ? ? ? ? ? ??| |