Comments for The Real Cost of Data Roundtrip

[phinjensen]

Comments for https://www.endpointdev.com/blog/2012/10/the-real-cost-of-data-roundtrip/ By Szymon Lipiński

To enter a comment:

1. Log in to GitHub
2. Leave a comment on this issue.

[phinjensen]

original author: vdp
date: 2012-10-03T08:41:04-04:00

Nice clear numbers and I've often lobbied for this myself.

One counter-argument I've often heard and that is hard to counter (it may sometimes be valid, and it is hard to measure) is that you end up using the db server's CPU when it would be more efficient to let the app server do that work. Especially since app servers tend to scale horizontally but db server vertically.

Not a definitive counter-argument, just a YMMV warning.

[phinjensen]

original author: Szymon Guz
date: 2012-10-03T09:39:14-04:00

This is a very good argument. The best way is always to check the real cost of performing such database operations and calculate what's cheaper or more business friendly.

It is always good to know that there is another, possibly better, way of changing database data, than the pure ORM solution.

[phinjensen]

original author: Jeff Boes
date: 2012-10-03T09:40:51-04:00

There's another argument against "SELECT *" in embedded Perl code. (Admittedly, this one gets solved if you use an interface like Rose, but if you are scripting down at the DBI level, this can be a pitfall.)

Using "SELECT *" means your code is vulnerable to column name-changes with very little warning. For instance,

SELECT * FROM emp

and code that references $row->{fname} will break (sometimes silently) when column "fname" becomes "first_name". (Yes, this is a somewhat contrived example, but it happens.)

Much better to find out about it if your embedded SQL code is:

SELECT fname, lname FROM emp

then at least you get a run-time error that provides far more help.

[phinjensen]

original author: Robert Young
date: 2012-10-03T12:55:15-04:00

As to why coders instinctively reach for java/etc.? Simple. Ever since programming became synonymous with "the web", coders have reveled in the reactionary paradigm of COBOL/VSAM of their granddaddies: dumb data, smart code. Few, if any, have taken a serious database course while in school. Lots of languages, of course, but little or nothing of databases. I don't count xml/NoSql as databases.

As to PG's support for many languages, not so much as one might think. Most (all?) that aren't C are themselves implemented in C, so the engine actually implements the underlying C. Not saying this is a bad thing, only that non-C languages aren't natively supported.

Should we ever get to the point that 5NF databases are the norm rather than the exception, then the argument that the DB is just a "file store" and data management belongs in the client (as it did/does in the COBOL/VSAM world) will fade.

[phinjensen]

original author: Szymon Guz
date: 2012-10-03T14:12:44-04:00

@Jeff you're absolutely right, I just wrote that as a simple example. However I think it is best to provide good examples, I will fix that in a moment.

[phinjensen]

original author: Joshua Tolley
date: 2012-10-04T17:08:29-04:00

@Robert Young, non-C languages are supported in much the same way SQL itself is -- it's all interpreted somewhere inside the server. For most of those languages there will be some extra overhead of converting the data from types PostgreSQL understands to types the embedded interpreter understands, and depending on the task at hand, that can be significant. But the same sort of conversion is necessary to get the data ready to send across a network, and then again in application code.