Re: Relational-to-OOP Tax

Decoupling SQL statements may or may not increase the total
number of lines of code, depending on the size of the SQL statements
and the number of times they are reused.

Forcing all SQL statements into functions instead of only putting them
into functions when suitable, will always increase LOC.

As discussed elsewhere in the thread, even the hard of learning
Mr. Jacobs admits that lines of code is not a sufficient measure.

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.

You keep asking for proof without specifying the burden of proof. What
burden of proof would require for structured programming to prove it is
better to call functions than not to (as used to be the case)

Regardless if your code contains SQL statements or not: Functions
should be used to avoid having repeated fragments of code that are
more complex than the function call itself. If the function is only
called once or is as simple as the call to it, a function has no
purpose. Function may also be used to enable recursion.

or that it
is better to let a filesystem handle file-io than an application to
manipulate disk structures directly (as also used to be the case)?

A relational database already offer separation between logical and
physical data structures. SQL already offer independence between
database vendors.

Maintainability and extensibility are two NFRs that come
immediately to mind. Clean code is easier to maintain and extend.

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)

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 ...

How would the argument list to createEmployee look like?
createEmployee(x1, x2, ....., x200)

If you show the complete implementation of createEmployee, I can
promise you that it is everything but clean.

and when another table is created that must know about new employees the
procedure can be updated without modifying application code.

Sorry, I don't follow you here.

Or if
employees can be added from multiple applications it is better to have
isolated the code for adding them than to duplicate it.

If the same fragment of code should be called from multiple points, a
function is suitable.

Are you arguing that clean, well-designed code does not have
quality benefits?

No, but creating new functions with only one statement or functions
that are only called only once, doesn't create cleaner or more well-
designed code.

Practically speaking that is rarely the case.

My experience is exactly the opposite. Using view would also make the
scenario more common.

And even if it occurred
more often than rarely, it is a better design that allows one
module/function/method to change independently of others that rely on it.

If a SQL statement is simple, there are not many possibities to change
it, without changing the semantics.

/Fredrik



.

Relevant Pages

  • Re: Relational-to-OOP Tax
    ... depending on the size of the SQL statements ... cleaner or more well-factored code. ... insert into employee values ...
    (comp.object)
  • Re: Passing values from a multi-select list to a MySQL query using PHP
    ... to pass those selections to a MySQL query for a report. ... include those in my MySQL statement? ... depending on the HTTP method used to submit the form. ... As to inclusion into SQL statements, ...
    (comp.lang.php)
  • Re: Relational-to-OOP Tax
    ... Forcing all SQL statements into functions instead of only putting them ... cleaner or more well-factored code. ... Clean code is easier to maintain and extend. ... The decoupling you are talkning about is only about creating extra ...
    (comp.object)
  • Re: Better Coding 2 SQL Commands
    ... It works but cleaner would be better! ... DoCmd.RunSQL (MySQL) ... It's not unreasonable to have to use two SQL statements to do that, so I don't see any obvious way to combine them. ... Please feel free to quote anything I say here. ...
    (microsoft.public.access.gettingstarted)