Relational database & OO
in [OOP]
|
From: Thomas Gagne on 10 Nov 2006 10:36 H. S. Lahman wrote: > <snip> > 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. Can you be more precise about what you mean when you say, "Each shift required major surgery ... because the persistence mechanisms were not encapsulated." If we were to look back at those transitions with an eye towards designing the original applications again so the surgery was more cosmetic, how would you have implemented the application's database interface differently and are you doing that today? -- Visit <http://blogs.instreamfinancial.com/anything.php> to read my rants on technology and the finance industry.
From: H. S. Lahman on 10 Nov 2006 12:03 Responding to Gagne... >> 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. > > Can you be more precise about what you mean when you say, "Each shift > required major surgery ... because the persistence mechanisms were not > encapsulated." At each shift there were huge amounts of legacy code around that used the old paradigm for persistence and needed to be upgraded. Typically the persistence mechanisms were not encapsulated in a single application subsystem. Thus the direct reads and writes were sprinkled ubiquitously throughout the code. Worse, the application processing was often structured around the preferred organization for the paradigm. So it was not simply a matter of 1:1 statement replacement. Often one had to modify the basic flow of control of the application. For example, the way one collects related data from multiple ISAM files is quite different than the way one employs SQL table joins. > > If we were to look back at those transitions with an eye towards > designing the original applications again so the surgery was more > cosmetic, how would you have implemented the application's database > interface differently and are you doing that today? Encapsulate the persistence mechanism behind a single subsystem interface (an API in the Procedural Days). Design the subsystem interface in terms of what the problem solution's needs for data are, which will be independent of how the data is stored. Then let the subsystem provide the mapping of that interface into the persistence paradigm de jour. Thus the application solution always requests, "Save this pile of data I call X" and "Give me the pile of data I saved before as X." The persistence access subsystem maps the X identity and the pile of data into records in ISAM files, RDB tables, clay tablets, or whatever. Now one can substitute the persistence paradigms by replacing one subsystem implementation without touching either the interface or the problem solution. ************* 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
From: frebe73 on 10 Nov 2006 12:33 > Worse, the application processing was often structured around the > preferred organization for the paradigm. How could we do it different know, if we don't know anything about the future paradigm? > Encapsulate the persistence mechanism behind a single subsystem > interface (an API in the Procedural Days). Design the subsystem > interface in terms of what the problem solution's needs for data are, > which will be independent of how the data is stored. What is your definition of "store"? Store to a persistent medium, store into a variable, store into another process, or? > Then let the > subsystem provide the mapping of that interface into the persistence > paradigm de jour. If we use a RDBMS, the persistence part is already separated. The application has no idea about if, when or how data is persisted. > Thus the application solution always requests, "Save this pile of data I > call X" and "Give me the pile of data I saved before as X." The > persistence access subsystem maps the X identity and the pile of data > into records in ISAM files, RDB tables, clay tablets, or whatever. Is X always an identifier? Should you be allowed to use any predicate logic in this interface ("give me the pile of data I saved before having X=5 or Y=6")? Fredrik Bertilsson
From: H. S. Lahman on 10 Nov 2006 12:37 Responding to Gagne... >> 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. > > That's one way of doing it. My experience shows that 70-80% of a system > is queries. Whether inquiry transactions or reports, all the business > systems I've participated coding or designing spent little production > time changing data. In the online systems I'm familiar with, update and > change transactions were preceded and followed with queries. Long after > transactions are done posting, management looks at reports to see how > their business is doing. Given statistics like these it makes little > sense to design your application or OO model before designing your > database. Note that I was careful to qualify with "non-CRUD/USER". That sort of proportion is a symptom that the application is USER/CRUD processing. The application is basically a pipeline between the database and the UI and its main purpose in life is to convert between the two views. For that sort of situation the RAD layered model infrastructures already provide lots of automation so an OO approach would probably be overkill by reinventing that wheel. > Additionally, relational data models can be more easily proven > correct--or correct enough--before an investment is made in coding. I'm not sure I buy that. More easily than what? The RDM normalization can be applied beyond the RDB's table/tuple paradigm. ISAM files, CODASYL files, and other data representations can be normalized using the same basic rules. And OO Class Models are routinely normalized as part of the basic paradigm methodology. However, I don't see that as being very relevant. My point is that the application's problem solution doesn't care how the data is stored. If it doesn't care how it is stored, it certainly doesn't care how the storage mechanism is validated. > Lastly, your database is language-neutral. It shouldn't matter what > language the application sitting in front of the database is written in, > or even what paradigm it's born from. Flexibility starts with a good > database design and extends through the application--not the other way > around. That's true enough but I would make it even stronger. RDBs are designed to be problem-independent, not just language independent, which is pretty much my point. The data structures one needs to optimize the solution to a /particular/ problem in an application are often quite different than the structures best suited to optimizing generic, ad hoc access of the same data. So if one is solving a non-CRUD/USER problem where special optimization is usually required, one wants to separate the views of the solution from those of the RDB. In addition, the OO construction paradigm for solving individual problems is quite different. For example, in an OO solution there is no construct remotely similar to an RDB join. That's because OO relationships are instantiated at the object level rather than the table level, relationships are navigated differently, and the paradigm employs peer-to-peer communications. ************* 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
From: frebe73 on 10 Nov 2006 14:12
> > Additionally, relational data models can be more easily proven > > correct--or correct enough--before an investment is made in coding. > > I'm not sure I buy that. More easily than what? The RDM normalization > can be applied beyond the RDB's table/tuple paradigm. What is the "RDB's table/tuple paradigm"? > And OO Class Models are routinely normalized as > part of the basic paradigm methodology. Many class diagrams would break 1NF. I also see a problem with applying to 2 & 3 NF because the id of the object is not a value itself, but a pointer. Because object may be easily cloned, I suppose that would break 2NF. > However, I don't see that as being very relevant. My point is that the > application's problem solution doesn't care how the data is stored. Neither do the relational model or SQL. > If it doesn't care how it is stored, it certainly doesn't care how the > storage mechanism is validated. I guess Thomas is talking about how the business rules are validated. > > Lastly, your database is language-neutral. It shouldn't matter what > > language the application sitting in front of the database is written in, > > or even what paradigm it's born from. Flexibility starts with a good > > database design and extends through the application--not the other way > > around. > > That's true enough but I would make it even stronger. RDBs are designed > to be problem-independent, not just language independent, which is > pretty much my point. The relational model is used for modelling data, problem-independent or not. Just because some data could be considered "problem-dependent", it may very well me modelled using the RM. > The data structures one needs to optimize the solution to a /particular/ > problem in an application are often quite different than the structures > best suited to optimizing generic, ad hoc access of the same data. In some special scenarios, B-trees might not be the best solution and arrays or hashtables might be better choices. But I think that is low-level optimization without significant impact on average enterprise applications. > So > if one is solving a non-CRUD/USER problem where special optimization is > usually required, one wants to separate the views of the solution from > those of the RDB. Using low-level collection classes is not a good idea for modern enterprise applications. There are a lot of issues like concurrency or transactions, that you have to solve by yourself in that case. Fredrik Bertilsson > > > ************* > 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 |