Re: The wisdom of the object mentors (Was: Searching OO Associations with RDBMS Persistence Models)
Date: Thu, 1 Jun 2006 15:28:14 -0500
On 2006-05-31 11:31:29 -0500, Bob Badour <bbadour_at_pei.sympatico.ca> said:
>> On 2006-05-30 06:31:53 -0500, "Erwin" <e.smout_at_myonline.be> said: >> >>> Little point in preaching to the chuiar of course (how do you spell >>> that damn word ?). >>> >>> Go tell this on an Otherwise Oriented forum, you'll get dawnbashed. >>> >>> That said, application code is still highly important because it's >>> needed to fill all the holes that current dbms's still leave wide open >>> in the area of constraint enforcement. >> >> This statement is fascinating. It takes the view that the majority of >> the system is DB and that application code simply fills the cracks. >> The DB represents the bricks and the application code is the mortar. >> >> I disagree with this analogy.
> Which is highly indicative of your profound ignorance, which was noted
Ah! If I disagree, I am ignorant. I see. Now, can we get past the ad=hominem arguments about my personal character and get back to the argument at hand? WHY is it ignorant to disagree that the DB is the brick, and the app is the mortar?
>> accessing, reporting, data. That mechanism can be implemented many >> different ways and need not even be an RDB.
> If one is stupid, ignorant or has no choice, I suppose one might use
> something different. The RDBMS is also a mechanism for manipulating
> data, for security, for integrity, for derivation, for all-round
> management -- as the name implies.
Sigh. Then I suppose all OS designers are stupid and ignorant, because they certainly COULD have build the directory file structure on top of an RDB had they wanted to. But none have done this. So, they must all be stupid and ignorant.
> The application code
>> defines what the program does with the data.
> Other than enter, manipulate, report and derive, what does one do with data?
One makes decisions based upon it. One transforms it from one state to another. One merges data streams together and divides data streams apart.
An RDBMS can sometimes be a wonderful tool to use in pursuit of these activities. Other times it is not.
> [irrelevant and incorrect metaphors snipped]
Ah, so you are going with the "relevant" and "correct" metaphor of the bricks and mortar? Please note that bricks and mortar produce static structures. Indeed it is the nature of bricks and mortar to be static. On the other hand, it is the nature of software to be dynamic. So I think the metaphor might have a very slight flaw. But then, I'm stupid and ignorant, so you could just ignore my incoherent rantings. Please.
>> >> The story may be true, but I'm not sure I get the point. Frankly, it >> IS the responsibility of the application to enforce integrity. Oh, the >> DB can enforce it while the data is in the warehouse, but the data >> comes out of the warehouse, gets transported all over the place, gets >> transformed in many different ways into many different products, gets >> presented to many different customers and put into many different >> systems, and for all these activities it is the APPLICATION that must >> enforce the integrity of the data.
> Once again, you expose your ignorance.
ONCE AGAIN! Oh will the ignorance never cease? Can't these idiot application programmers see the beauty and power of the DB? Don't they understand? They just don't get it. They just don't get it. They are ignorant and stupid.
> If you remove the data from the data management system, obviously, you
> force yourself to re-invent other tools to manage the data--however
> poorly. It strikes me as rather stupid to choose the wrong tool for the
> job, though.
Hmmm. So your solution is that the data should never be removed from
the DBMS? I should never send a credit request transaction to a credit
check company because the data would have to leave the DBMS? I should
never print a purchase order because the data would have to leave the
DMBS? I should never present a customer record on a web page because
the data would have to leave the DBMS?
> The DB loses control once the data
>> is out of the warehouse.
> Here, you expose sloppy thinking.
Ignorant, Stupid, AND SLOPPY! Heavens! What is this industry coming to. Ye GODS, why do we have to deal with these moronic people who post OPINIONS on this newsgroup.
> A database is simply a set of facts, which renders your sentence nonsense.
Sorry. Let me put the MS back on the end of the DB so that your fragile sensibilities aren't harmed.
The DBMS loses control once the data is out of the warehouse
OK, now we can continue.
> If one were charitable, one might substitute 'data management system'
> where you put DB, but then the statement would become unremarkable and
I think the point is that once the data has left the MS it is the application program that is responsible for maintaining it's integrity until such time as it can be put back into that MS, or another MS.
>> Clearly keeping the integrity of the data in the warehouse is >> important. But that's not the whole story. It's not even most of the >> story.
> Yes, that's true. If the protagonist chooses at the outset to do stupid
> things (ie. to manage the data without a management system, to travel
> to an island full of dinosaurs, to catch the maneating 30 foot great
> white shark etc.), then Act II generally follows the protagonist as he
> struggles against the harmful consequences of his stupid choices, and
> Act III culminates the story with the protagonist either overcoming his
> stupidity or succumbing.
> That makes for entertaining drama, but I wasn't aware that the goal of
> computing science or information technology was to create drama or to
> entertain ourselves, per se.
Sorry, I didn't follow that last metaphor. I thought we were sticking with bricks and mortar. Or I at least thought that one of your points was that it's a bad idea to take the data out from the control of the MS.
Or perhaps you are still reeling from my assertion that application programs should be designed to be so decoupled from the MS that the MS could be replaced without affecting the application. Perhaps you could tell me why this notion is stupid, ignorant, and sloppy, if that is what you believe.
>> Finally, and this is critical to the understaning of my point, the code >> in which data integrity is specified IS application code. It may be >> written in a special purpose DB language, or it may not. But it is >> code that supports the application.
> Code? Do you consider a well-formed formula code?
> Are logic predicates code?
> I am just curious what you define as code.
Code is something a computer can read, interpret, and execute. Something that is so unambiguous and formal that an automaton can follow it.
> If you define code to include everything, then your statement is true
> if unremarkable and uninteresting.
Remember that my original statement is that application programs should be designed such that they are decoupled from the MS. Clearly if you use the MS langauge to write the bulk of the application you are violating that principle. So, the "critical" point that was lost was that if you code the aplication in the DBMS langauge, you have not decoupled from the DBMS.
-- Robert C. Martin (Uncle Bob) | email: unclebob_at_objectmentor.com Object Mentor Inc. | blog: www.butunclebob.com The Agile Transition Experts | web: www.objectmentor.com 800-338-6716 |Received on Thu Jun 01 2006 - 22:28:14 CEST