Symfony: SQL-Phobia

In the symfony book
there's an alarming bit of explanation:

Using objects instead of records, and classes instead of tables, has another benefit: you can add new accessors to your tables. For instance, if you have a table called Client with two fields, FirstName and LastName, you might like to be able to require just a Name. In an object-oriented world, this is as easy as adding a new accessor method to the Client class, like this:

public function getName()
{
  return $this->getFirstName().' '.$this->getLastName();
}

All the repeated data-access functions and the business logic of the data can be maintained within such objects. For instance, consider a class ShoppingCart in which you keep items (which are objects). To retrieve the full amount of the shopping cart for the checkout, you can add a getTotal() method, like this:

public function getTotal()
{
  $total = 0;
  foreach ($this->getItems() as $item)
  {
    $total += $item->getPrice() * $item->getQuantity();
  }
  return $total;
}

And that's it. Imagine how long it would have required to write a SQL query doing the same thing!

Hmm.... That's a lot of "get" going on there. The worst case scenario is a single SQL query for each "get", and the best case scenario is that each "get"'s data is cached in an objects, so it's just one query. (Of course, the best case scenario is bad for memory usage.)

How about this alternative for the first example:

function getName($id)
{
    return sql_query_get_one_value("SELECT CONCAT(First, ' ', Last) FROM table WHERE id=$id");
}

Assume that sql_... function does what you expect: runs a query, returns the first column of the first row, disposes of the result.

And that second example's SQL, which wouldn't take that long to write, is:

SELECT SUM( price * quantity ) FROM table

That's 1 line of SQL to 9 lines of PHP. This single SQL statement takes care of all the "looping" for you. If you need it function-ized, you can do the getName() trick above.

Not only is it shorter, it's probably faster than the PHP code.

That's the whole point of SQL - to reduce the number of loops you have to write. Taking tables of data, and turning them into objects, is really not the way to go. Objects are basically like the old-school C data structures connected to each other via pointers. It's great stuff, but, it's very low-level. Typically, to make the code more "high level", C programmers sometimes ended up writing small virtual machines for their apps. Maybe they'd make a FORTH-like stack-based machine, or a Lisp-like list-based machine, or something that handled streams of data well, or something that solves matrices. Then, C++ was invented. Then Java was invented.

The point is, low-level programming, where you manipulate arrays of bytes, is a pain in the ass. The solution is to improve the abstractions, so you can handle larger and larger amounts of data.

After a point, you stop wanting to manage objects. You want to stop writing a loop for the thousandth time. That's what SQL does for programmers -- it lets you get beyond writing loops for a specific situation.

jQuery

jQuery helps you stop writing loops, too. It's based on the idea of "map()" - of applying a function to every member of an array, and then returning that new array as the result.

The array in question is initially built up with a query. The query is conceptually identical to CSS's selectors -- that is, the CSS selector language is used as jQuery's selector language. For SQL heads, it's something like this:

SELECT element FROM document WHERE id='foobar'

Except that the syntax is a lot shorter: $('#foobar')

Then, the mapping can be performed:

$('#foobar').each( function(){...} );

Once again, the pain of traversing pointers to get to your data has been avoided by a higher-level of abstraction.

XSLT, applied to XHTML, was supposed to be that higher-level language, but, XSLT sucks. It's too verbose. The main drawback of excessive verbosity is typist fatigue, leading to increased syntax errors, leading to programmer frustration.

It's too bad, because, XSLT, being a very high-level language compared to Javascript, can be very fast. You can potentially compile the transforms, and apply them to the DOM. That's potentially very fast, at least compared to Javascript and jQuery.

Maybe one day, jQuery, or something like it, will be implemented natively in the Javascript language.

Meanwhile, if you need JS speed, you have to avoid using the anonymous functions, objects, multi-dimensional arrays, and write loops yourself. Bleah.