Relational database & OO
in [OOP]
|
From: Matt McGill on 3 Nov 2006 11:26 frebe73(a)gmail.com wrote: > If the OO programmer only needs persistence, and RDBMS is a huge > overkill. A much simpler tool would do. What would you suggest as a simpler tool? In Java the serialization mechanism is the first thing that comes to my mind, but I don't see how that would be anywhere near sufficient. It's sort of all-or-nothing. Sure, you can serialize your entire object graph to a file when your application shuts down, and then pull it all back in, if you want. But that might not be such a hot idea if you've got 4 million customer objects, and only 200 customers are ever using your application at a time. Having the ability to be very selective about which objects you actually have in memory at any given time is sort of nice, and the querying capabilities built into an RDBMS give you the ability to be selective. > > > The problem then becomes one of > > instantiating relationships - if an object is persistent, it needs to > > be loaded from the storage mechanism at some point. Who does that? Who > > loads other persistent objects associated with the first? Where are the > > transaction boundaries? > > A RDBMS is not a storage mechanism. A storage mechnism is much simpler. > Transactions and persistence are two orthogonal features. I grant you that transactions and persistence are seperate concerns, and that an RDBMS does a lot more than just store data. But it /does/ store data. What do you mean "not a storage mechanism"? Maybe the better question is, "What did you think I meant by 'storage mechanism'?" because we clearly aren't on the same page. > > If these persistence-related concerns are > > sprinkled about your business logic, your code will be much harder to > > adapt to changing requirements. > > If you use SQL in your application, your application will contain no > persistence related logic at all. How can you consider 'INSERT INTO table_name VALUES (1, 2, 3)' to be anything /other/ than persistence logic? It's an imperitive statement that persists data in just about as explicit a way as I can think of. When you write an application using straight SQL all over the place, there is /no/ seperation of application flow or business logic from persistence logic at all - it's just a big mishmash. As transactionality and persistence are orthogonal, so is business logic and the means by which the data that logic operates on is stored. Maybe it's in a database. Maybe it's in flat files. Maybe there /is/ no database, and verything is 'persistence' because it's all in memory all the time. It shouldn't matter to your business logic. -Matt McGill
From: PS on 3 Nov 2006 12:20 "aloha.kakuikanu" <aloha.kakuikanu(a)yahoo.com> wrote in message news:1162502265.486041.153780(a)b28g2000cwb.googlegroups.com... > > Doug Pardee wrote: >> ajspowart(a)gmail.com wrote: >> > 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? >> >> Martin Fowler's book "Patterns of Enterprise Application Architecture" >> covers this territory. It would be a good starting point. > > Or yeah. A tiny time management application certainly needs to be > hammered with "Enterprise strength" approach. My newsreader must show different posts than yours does. I didn't see the "tiny application" mention. > > 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. Again I didn't see where the Java application was mentioned. I need to read more carefully from now on. Must go. Got to get over to the database newsgroups to so some trolling. PS
From: frebe73 on 3 Nov 2006 12:47 > > If the OO programmer only needs persistence, and RDBMS is a huge > > overkill. A much simpler tool would do. > > What would you suggest as a simpler tool? Berkeley DB for example. > Sure, you can serialize your entire object graph to a file when your > application shuts down, and then pull it all back in, if you want. But > that might not be such a hot idea if you've got 4 million customer > objects, and only 200 customers are ever using your application at a > time. You just proved that persistence is not the only feature we use in a database. Concurrency is another important feature. Otherwise you have to implement that in your application. > Having the ability to be very selective about which objects you > actually have in memory at any given time is sort of nice, and the > querying capabilities built into an RDBMS give you the ability to be > selective. Very useful, but completely orthogonal to persistence. > > A RDBMS is not a storage mechanism. A storage mechnism is much simpler. > > Transactions and persistence are two orthogonal features. > > I grant you that transactions and persistence are seperate concerns, > and that an RDBMS does a lot more than just store data. But it /does/ > store data. Not necessarly. You might use a all-in-RAM RDBMS. > > > If these persistence-related concerns are > > > sprinkled about your business logic, your code will be much harder to > > > adapt to changing requirements. > > > > If you use SQL in your application, your application will contain no > > persistence related logic at all. > > How can you consider 'INSERT INTO table_name VALUES (1, 2, 3)' to be > anything /other/ than persistence logic? An insert statement may not write anything to disk at all. It might only put the data into the cache. A all-in-RAM database would not write anything to disk. > When you write an application using straight SQL all over the place, > there is /no/ seperation of application flow or business logic from > persistence logic at all - it's just a big mishmash. SQL is not about persistence, so your conclustion is false. SQL is about data management. > As transactionality and persistence are orthogonal, so is business > logic and the means by which the data that logic operates on is stored. How data is stored is hidden deep inside the DBMS. When you use Oracle, you have no idea how the data is stored. > Maybe it's in a database. Maybe it's in flat files. Maybe there /is/ no > database, and verything is 'persistence' because it's all in memory all > the time. It shouldn't matter to your business logic. If your application only needs flat files, a database is overkill. If your application needs a RDBMS, flat files are never an option. If your application operates all in memory, you would probably still need a RDBMS. Fredrik Bertilsson
From: Matt McGill on 3 Nov 2006 13:42 frebe73(a)gmail.com wrote: > > I grant you that transactions and persistence are seperate concerns, > > and that an RDBMS does a lot more than just store data. But it /does/ > > store data. > > Not necessarly. You might use a all-in-RAM RDBMS. Oy. I know this is bad form, but I can't help it. From dictionary.com: storeâ?? /stÉ?r, stoÊ?r/ [stawr, stohr] â??verb (used with object) 8. to supply or stock with something, as for future use. 9. to accumulate or put away, for future use (usually fol. by up or away). 10. to deposit in a storehouse, warehouse, or other place for keeping. 11. Computers. to put or retain (data) in a memory unit. Last time I checked, RAM was considered to be a memory unit. And I'm pretty sure I've read plenty of talk about 'storing' data in a stack, list, or some other ADT. If the word 'store' is no longer allowed to refer to anything other than disk writes, I never got the memo. We're both nitpicking each other to death here and apparently mapping entirely different meanings to the same set of words. 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. Berkley DB would indeed be a good choice of persistence back-end for certain types of applications - thank you for mentioning it.
From: H. S. Lahman on 3 Nov 2006 16:16
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. <aside> People tend to discount swapping paradigms as an advantage because RDBs have dominated for 2+ decades. However, I've personally watched the paradigm for persistence changing from paper tape/punched cards to flat sequential disk to ISAM to CODASYL to RDBs to OODBs (in at least some niches). Each shift required major surgery for huge amounts of legacy code because the persistence mechanisms were not encapsulated. And each paradigm shift was regarded as the last possible -- until some new technology appeared. So I wouldn't bet against another paradigm shift in the future just because RDBs have been around awhile. 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> ************* There is nothing wrong with me that could not be cured by a capful of Drano. H. S. Lahman hsl(a)pathfindermda.com Pathfinder Solutions http://www.pathfindermda.com blog: http://pathfinderpeople.blogs.com/hslahman "Model-Based Translation: The Next Step in Agile Development". Email info(a)pathfindermda.com for your copy. Pathfinder is hiring: http://www.pathfindermda.com/about_us/careers_pos3.php. (888)OOA-PATH |