Relational database & OO
in [OOP]
|
From: topmind on 7 Nov 2006 01:34 Matt McGill wrote: > 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. Two-thirds right. The trick is to minimize behavior by using heavier declarative approaches so that we can use declarative engines, which are more evolved than "behavioral engines" at this stage in history. Maybe "behavior maths" will somebody be invented, but until then, relational has a leg up. Behavior and data are pretty much the same thing, just different views of the same thing. To a compiler/interpreter, machine language is data, for example. Building attribute-centric applications in many ways is like building a domain-specific interpreter. > 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." I'll take an "enormous ERD" over an enormous class diagram any day. Relational is far more consistent than OO connections. A relational mess is a 10-fold improvement over the equivalent navigational-slash-OO mess. Dr. Codd was an IT genious who slayed the navigational dragons of the 60's. But the OO Smeagols tried to bring navies back because building shanty town random-class apps made them feel empowered to create messes and gain job protection instead of sticking with sound relational modeling. And relational does not rule out putting functions inside of table cells. However, i've found that it does not add much to the mix except in specific circumstances. > > -Matt McGill -T-
From: topmind on 7 Nov 2006 01:35 Patrick May wrote: > 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. Bill Clinton merged with Jeffery Dalmer? > > 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: Thomas Gagne on 10 Nov 2006 09:53 H. S. Lahman wrote: > <snip> > 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. Additionally, relational data models can be more easily proven correct--or correct enough--before an investment is made in coding. 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. <http://bogs.in-streamco.com/anything.php>
From: Thomas Gagne on 10 Nov 2006 10:09 AndyW wrote: > <snip> > > The difference between what I think should be a true OO database and a > PSE is that to me the former has no separation of state between what > is executing and what is stored. There shouldnt be any concept of > storage or transience or separation of application and data - just > "IS-ness of the whole" as I call it. > "Just be the ball, be the ball, be the ball. You're not being the ball Danny." Pretending the database doesn't exist is a recipe for pain. Too many OO programmers, enamored with the benefits of OO design inside an application try imposing object graphs to the database thinking that if they could only become one, their wonder twin powers would activate. For OO beginners, the database is the elephant in the room. It's the 800 lb. gorilla they think can be negotiated with. What we forget is the database lives independently of our application. Long after our application has stopped running and users have logged off, the database is still there and has other potential customers--including managers, programmers, and everyone's favorite: auditors. If the only way to make sense of your database is to look at through the binoculars of an OO-designed application, then developers had better be prepared to multiple any of their times estimates by 5 because most of their time will be consumed writing reports. As I mentioned in an earlier post, 70-80% of a system's utility is in its reports. People are always looking for new ways to look at data, but rarely do they look for new ways of posting or changing data. -- Visit <http://blogs.instreamfinancial.com/anything.php> to read my rants on technology and the finance industry.
From: Thomas Gagne on 10 Nov 2006 10:23
frebe73(a)gmail.com wrote: > <snip> >> 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. > Will you explain what you mean by "Transactions and peristence are two orthogonal features?" -- Visit <http://blogs.instreamfinancial.com/anything.php> to read my rants on technology and the finance industry. |