Relational-to-OOP Tax
in [OOP]
|
Prev: "OOP is Dead" article
Next: The reality of Topmind (Was: Topic-Organized Object-Oriented Programming)
From: frebe on 22 Feb 2007 13:41 > >> > More lines of code takes longer time to write. More lines of code > >> > makes the code harder to read. > > >> This is not always, or even often, the case. Highly coupled > >> big balls of mud that mix different concerns are more difficult to > >> understand than well-factored, clean code. > > > But nobody have proved why separating all SQL statements would > > create cleaner or more well-factored code. > > Actually, several people have pointed out the value of separating > concerns. The retrieval, transformation, and use of data are > conceptually different; combining them in a single lexical unit > reduces the understandability of that unit. Do you have pointers to where "several people have pointed out..."? In relational algebra retrieval, transformation and use of data is not conceptually different. A single select statement can do it all. The messy code is caused by the fact that you insist to transform relational data into object graphs. If you skip doing this you don't have any conceptually different concepts. > > In what what way is > > > createEmployee(x,y,z) > > > function createEmployee(x,y,z) { > > insert into employee values (x,y,z) > > } > > > cleaner than > > > insert into employee values (x,y,z) > > Even in this simple example, the name of the function is more > descriptive than the SQL statement. Really? It is just different syntax. > It can also be re-used without > exposing the database schema throughout the application. And the benefits with that are....? > >> Horizontal and vertical scalability benefits from having clearly > >> defined, decoupled components. > > > The decoupling you are talkning about is only about creating extra > > layer inside an existing process. How can scalability benefit from > > this? > > Not at all. I'm discussing decoupling in the general sense, I am not. Decoupling in a general sense have many benefits, but you can't decouple everything from everything. Decoupling has also a cost and that cost has to be compared to the benefits. > of which encapsulating SQL is only one, albeit important, aspect. This is what we are talking about in this thread. > Both > horizontal and vertical scalability benefit from the existence of > decoupled, well-encapsulated components. What is a well-encapsulated component in this case? Are you talking about EJB beans or something here? > >> Security is easier to implement and prove when components have > >> single responsibilities. > > > Do you have some examples of this? > > One of the primary difficulties with implementing security > correctly is the difficult to understand interactions between complex > components. Having a single responsibility for each component > simplifies analysis and testing considerably. Is this an example? /Fredrik
From: Kreeg on 22 Feb 2007 13:44 topmind wrote: > Patrick May wrote: >> "topmind" <topmind(a)technologist.com> writes: >>> Thomas Gagne wrote: >>>> It is cleaner when createEmployee(x,y,z) is more realistically >>>> imagined: >>>> >>>> insert into employee... >>>> insert into address ... >>>> insert into employeeAddress ... >>>> insert into employeeEmployee ... >>>> insert into calendarResource ... >>>> insert into payroll ... >>>> insert into planParticipant ... >>>> insert into benefitParticipant ... >>>> insert into dependents ... >>>> >>>> and when another table is created that must know about new >>>> employees the procedure can be updated without modifying >>>> application code. Or if employees can be added from multiple >>>> applications it is better to have isolated the code for adding them >>>> than to duplicate it. >>> In that case I would agree, but because it is an *entire* task in >>> itself, not just part of a task. But that is not the typical use of >>> SQL. >>> >>> Plus, it is a bit of a suspicious design. In most cases there are CRUD >>> screens to enter each of those *one* at a time. >> No, there most certainly are not. This is the case only in >> simple CRUD applications. Your limited experience is showing again. > > Why don't you show me wrong by presenting a real-world examples, > instead of self-puffery? > > I'd bet money that most companies don't enter employees and medical > benefits and 401k investment portfolios all in a single *monolithic > transaction*. A minor problem could prevent the *entire* thing from > being accepted, causing wasted data entry time and effort, making the > company less profitable. Perhaps you are the ahole that designs those > web pages that make you enter a bunch of stuff, only to have it all > rejected and lost because of some nitty problem such that one has to > retype it all. Now, that's just a dumb argument. An app can have the entire transaction fail, and still display all of the data back to the user so they can correct what's wrong. That has nothing to do with whether the data is written to the database in a single transaction. > > >> Sincerely, >> >> Patrick >> >> ------------------------------------------------------------------------ > > -T- >
From: topmind on 22 Feb 2007 14:00 On Feb 22, 10:44 am, Kreeg <k...(a)sentdotcom.nospam.com> wrote: > topmind wrote: > > Patrick May wrote: > >> "topmind" <topm...(a)technologist.com> writes: > >>> Thomas Gagne wrote: > >>>> It is cleaner when createEmployee(x,y,z) is more realistically > >>>> imagined: > > >>>> insert into employee... > >>>> insert into address ... > >>>> insert into employeeAddress ... > >>>> insert into employeeEmployee ... > >>>> insert into calendarResource ... > >>>> insert into payroll ... > >>>> insert into planParticipant ... > >>>> insert into benefitParticipant ... > >>>> insert into dependents ... > > >>>> and when another table is created that must know about new > >>>> employees the procedure can be updated without modifying > >>>> application code. Or if employees can be added from multiple > >>>> applications it is better to have isolated the code for adding them > >>>> than to duplicate it. > >>> In that case I would agree, but because it is an *entire* task in > >>> itself, not just part of a task. But that is not the typical use of > >>> SQL. > > >>> Plus, it is a bit of a suspicious design. In most cases there are CRUD > >>> screens to enter each of those *one* at a time. > >> No, there most certainly are not. This is the case only in > >> simple CRUD applications. Your limited experience is showing again. > > > Why don't you show me wrong by presenting a real-world examples, > > instead of self-puffery? > > > I'd bet money that most companies don't enter employees and medical > > benefits and 401k investment portfolios all in a single *monolithic > > transaction*. A minor problem could prevent the *entire* thing from > > being accepted, causing wasted data entry time and effort, making the > > company less profitable. Perhaps you are the ahole that designs those > > web pages that make you enter a bunch of stuff, only to have it all > > rejected and lost because of some nitty problem such that one has to > > retype it all. > > Now, that's just a dumb argument. An app can have the entire > transaction fail, and still display all of the data back to the user so > they can correct what's wrong. That has nothing to do with whether the > data is written to the database in a single transaction. "Can" and "should" are two different things. I am saying that "large lump" transactions tend to be problematic for the reasons described, even IF it is saved in a holding area. That is my experience with user interface design. Things tend to be smoother with the user and business process if broken down into transactions of roughly 10 to 20 items each. > > > >> Sincerely, > > >> Patrick > > >> ------------------------------------------------------------------------ > -T-
From: Thomas Gagne on 22 Feb 2007 14:07 topmind wrote: > <snip> > > I'd bet money that most companies don't enter employees and medical > benefits and 401k investment portfolios all in a single *monolithic > transaction*. Groan. Use your imagination! How elaborate a transaction do you think a $10 deposit to a banking account is? Do you really think it's as simple as "update account set balanceAmount = balanceAmount + 10 where accountKey = x"? How about a withdrawal or LOC advance or payment? Imagine those rules having to be maintained across the teller, ATM, POS, batch, and web interfaces. Imagine what information must be maintained so that statements can be produced in a timely manner for all their customers. Imagine the planning required so when the next disruptive technology grabs hold of customers' imaginations the bank won't be left in the dust. Do you really think those rules exist as embedded SQL? Who is responsible for the database and what safety measures do you think they might erect so the database' integrity will be protected and that application's won't be broken when the database needs modifications for a new product? Now considering how people who think their database is important guard their database's integrity we should ask ourselves how important do we believe our database's integrity to be? What measures are appropriate so that our database's integrity can be maintained, and yet allow enough flexibility so that our businesses can be responsive to market demands? Our company's first line of defense after declarative constraints is stored procedures. All applications, batch or online, multi-tiered or monolithic, have a single path to perform financial transactions and data changes--and that's stored procedures. -- Visit <http://blogs.instreamfinancial.com/anything.php> to read my rants on technology and the finance industry.
From: topmind on 22 Feb 2007 14:32
Thomas Gagne wrote: > topmind wrote: > > <snip> > > > > I'd bet money that most companies don't enter employees and medical > > benefits and 401k investment portfolios all in a single *monolithic > > transaction*. > Groan. Use your imagination! > > How elaborate a transaction do you think a $10 deposit to a banking > account is? Do you really think it's as simple as "update account set > balanceAmount = balanceAmount + 10 where accountKey = x"? If the tables are well-normalized, it should be just about that simple, perhaps with a "transaction ID" of some sort and maybe a time stamp. Are you talking about the money transaction itself, or the verification of the user? But, you are switching examples here. Let's stick to the employee/HR example for now. If that example was bad, then the author should admit it. > -- > Visit <http://blogs.instreamfinancial.com/anything.php> > to read my rants on technology and the finance industry. -T- |