Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Simplify: move code into database functions

sivers.org

Post reply on HN
Print view View original

21–30 of 77 posts

Re: Simplify: move code into database functions

#21

Post by erichmond »

It's incredible to me that he watched Simple Made Easy (which is an incredible talk), and his mind went to "stick more stuff in the database". Not because that approach wouldn't work, but to me a clear sign of complection would be conflating the medium of data storage (a database) and the business rules that govern the data itself. But I guess that's the the sign of a good talk. It's open to interpretation.

It also complicates your scaling story, your caching story, your ability to change databases and a great number of other things.

If you're building an app that has no chance of ever possibly needing to scale, or use a different database for caching, searching, or analytic reasons, then this approach may be optimal, but if any of those levers need to move at some point, I think you'd be in for a world of hurt.

Re: Simplify: move code into database functions

#22

Post by jakejake »

Before the days of GUIs when regular office workers used the command line, the database was an all-in-one application. Stored procedures were created by the DB admin so that the non-techies could run reports with simple commands.

I've found it interesting that all of this functionality has remained in databases, but is almost never used in modern web applications.

Re: Simplify: move code into database functions

#23

Post by alkonaut »

> "In 1997, I started in Perl. In 1998, I switched to PHP. In 2004, a rewrite in Rails. In 2007, back to PHP. In 2009, minimalist Ruby. In 2012, client-side JavaScript. Each time I’d have to re-write all of the logic around the database: how to add a new person into the database, how to verify an invoice is correct, how to mark an order as paid, etc. But that whole time, my trusty PostgreSQL database stayed the same."

And what if during that time instead of switching programming languages, it was the storage system that had to be switched? You could easily invert the argument "Don't keep the logic in the DB! I had to switch from Postgres to MSSQL which meant I painstakingly had to convert all my db-logic, I wish it had been in the code instead!"

Re: Simplify: move code into database functions

#24

Post by hobs »

radicalbyte wrote: post #18
falcolas wrote: post #10

Earlier quoted context omitted.

Absolutely this. Not to mention the need to prematurely scale up DBs due to the added load. Expensive and hard.

The other side of the coin is that you probably won't need to scale. The performance differences can be staggering: I've replaced Java-based procedures which took more than an hour to execute with Stored Procedures which completed within milliseconds. That's an extreme example - the original code was simply incompetent - but I regularly see significant (100x) performance increase in core functions through the switch.…

I see databases in general get a lot of flack from developers for this reason, when on the other side of the fence I see a lot of really smart people misunderstanding the tool (as your example alludes to.)

I have often come to a stored procedure and not returned 100x, but more like 50,000x by simply changing a few lines of code.

tl;dr anyone can write slow code in any language.

Re: Simplify: move code into database functions

#25

Post by devdas »

alkonaut wrote: post #23

> "In 1997, I started in Perl. In 1998, I switched to PHP. In 2004, a rewrite in Rails. In 2007, back to PHP. In 2009, minimalist Ruby. In 2012, client-side JavaScript. Each time I’d have to re-write all of the logic around the database: how to add a new person into the database, how to verify an invoice is correct, how to mark an order as paid, etc. But that whole time, my trusty PostgreSQL database stayed the same.…

Switching programming languages is far more common than switching databases.

Re: Simplify: move code into database functions

#26

Post by straws »

erichmond wrote: post #21

It's incredible to me that he watched Simple Made Easy (which is an incredible talk), and his mind went to "stick more stuff in the database". Not because that approach wouldn't work, but to me a clear sign of complection would be conflating the medium of data storage (a database) and the business rules that govern the data itself. But I guess that's the the sign of a good talk. It's open to interpretation. It also c…

Kind of makes you wish he watched a couple more Rich Hickey talks, like any of the ones around Datomic. The solution there is not "stick more business logic in the database", it's "split up the part responsible for writes from the part that queries it".

Re: Simplify: move code into database functions

#27

Post by lesingerouge »

I'm currently reading Martin Fowler's "Patterns of Enterprise Application Architecture"[0] and I think that one of the main points that stuck with me is his recommendation for separation between the various layers and functions of a software system.

Basically the whole system should be a layer cake of smaller modules/systems, as "opaque" as needed to one another, but interacting with each other solely through a well defined "internal API".

I think the approach proposed in the article is good when starting or prototyping projects, but the object oriented and layering approach, even if it's a bit more challenging to visualize correctly at the start of the development of an app, is worth its weight in gold as features start piling up.

[0] http://www.amazon.com/Enterprise-Application-Architecture-Ad...

later edit: for clarity.

Re: Simplify: move code into database functions

#30

Post by jessaustin »

erichmond wrote: post #21

It's incredible to me that he watched Simple Made Easy (which is an incredible talk), and his mind went to "stick more stuff in the database". Not because that approach wouldn't work, but to me a clear sign of complection would be conflating the medium of data storage (a database) and the business rules that govern the data itself. But I guess that's the the sign of a good talk. It's open to interpretation. It also c…

I think we're talking relational DBs here, right? In fairness you already have business rules in the DB, implicitly, just from the layout of your tables. You probably also have foreign keys. At that point, a stored proc that translates business needs like "at customer location X, stop service A on this date and replace it with service B" to the multiple table reads and inserts required, seems like a good idea. It's actually not that weird to keep most of your devs out of the database entirely, in which case they probably appreciate being able to just call a stored proc to get something done.
Post reply on HN