Database Reference
In-Depth Information
Wrap up - why program in the server?
The main advantages of doing most data manipulation code server-side are the fol-
lowing.
Performance
Doing the computation near data is almost always a performance win, as the latencies
for getting the data are minimal. In a typical data-intensive computation, most of the
time tends to be spent in getting the data. Therefore, making data access inside the
computation faster is the best way to make the whole thing fast. On my laptop it takes
2.2 ms to query one random row from a 1,00,000 row database into the client, but it
takes only 0.12 ms to get the data inside the database. This is 20 times faster and this
is inside the same machine over Unix sockets. The difference can be bigger if there
is a network connection between client and server.
A small real-word story:
A friend of mine was called to help a large company (I'm sure you all know it, though I
can't tell you which one) to try to make its e-mail sending application faster. They had
implemented their e-mail generation system with all the latest Java EE technologies,
first getting the data from the database, passing the data around between services,
and serializing and de-serializing it several times before finally doing XSLT transform
on the data to produce the e-mail text. The end result being that it produced only a
few hundred e-mails per second and they were falling behind with their responses.
When he rewrote the process to use a PL/Perl function inside the database to format
the data and the query returned already fully-formatted e-mails, it suddenly started
spewing out tens of thousands of e-mails per second, and they had to add a second
copy of sent mail to actually be able to send them out.
Ease of maintenance
If all data manipulation code is in a database, either as database functions or views,
the actual upgrade process becomes very easy. All that is needed is running a DDL
script that redefines the functions and all the clients automatically use the new code
