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

31–40 of 77 posts

Re: Simplify: move code into database functions

#31

Post by jos »

I find myself a bit thrown by encrypting passwords with a stored database function... which involves communicating with the database server with the unencrypted password.

The Microsoft SQL Server and Database Management Certifications and associated course work strongly discourage sending a password in that manner -- no matter how secure the connection is.

I'm unable to agree with the "simplify" aspect of the article title. My own personal experience tells me data should be validated where it is accepted rather than sent on to the next step -- the contrary may raise unintended additional security concerns or exploits.

Granted, my view stems from the article author's directive given towards "web or api developers." There are many situations where software makes a connection directly to a database rather than indirectly.

Re: Simplify: move code into database functions

#32

Post by tunesmith »

I think it can be a good idea for certain very predictable applications - predictable in terms of scaling and future feature enhancements.

But beyond that this strikes me as a bit too complicated. In particular, coupling business logic with database choice is risky. Martin Fowler, Bob Martin, and others underscore that the real cost of development is not the inability to predict the future, but in how difficult or time-consuming it is to change, when reality changes unexpectedly.

As soon as something happens that would bring repository choice into question, or would suggest the need to split parts of the business logic up into different locations, the choice to couple business logic with database implementation would start to feel really limiting.

Re: Simplify: move code into database functions

#34

Post by mistermann »

jalfresi wrote: post #14

In most of the example he gives, these solutions are ensuring the integrity of the data stored, which I personally have no problem with; that is the job of the database in my view. If I try and store crap the database should refuse, be that via constraints, triggers or stored procedures. As for returning the data in JSON, again, I see no problem with that; you were going to get the data out in rows and columns, what…

I would agree, at least on SQL Server, in my experience writing logic is just brutally painful, weak language and poor debugging.

Re: Simplify: move code into database functions

#35

Post by y0ghur7_xxx »

tunesmith wrote: post #32

I think it can be a good idea for certain very predictable applications - predictable in terms of scaling and future feature enhancements. But beyond that this strikes me as a bit too complicated. In particular, coupling business logic with database choice is risky. Martin Fowler, Bob Martin, and others underscore that the real cost of development is not the inability to predict the future, but in how difficult or ti…

> As soon as something happens that would bring repository choice into question

I don't know. Once a project is started with postgres/mysql/orcale, how often do you change the DB?

We have some projects that started with struts, then we changed the fe to jsp, the asp.net, then HTML/JS + MVC.net. But the DB was always Postgres. It never changed. In my experience what changes often is the frontend, not the stuff that keeps your data.

I would optimize for fe/middleware changes, not db changes.

Re: Simplify: move code into database functions

#36

Post by alkonaut »

devdas wrote: post #25
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.

*Citation needed

You wouldn't even need to switch the database, just add a cache between the storage an the app, or add/switch ORM etc.

There is a huge impedance mismatch between table storage and code, but I don't see how it gets more responsive to changed requirements by using logic in the DB.

And don't even get me started on the whole debugging/unit testing issue with logic-in-databases.

Re: Simplify: move code into database functions

#38

Post by y0ghur7_xxx »

BurningFrog wrote: post #8

A serious problem with this approach is scaling. When your code is in Ruby/JS/whatever on separate servers, and your traffic increases, you can easily scale up by adding more stateless servers. Going from 1 to 2 DB servers is much harder, and can easily mean a major rewrite, during which your site may not really work.

> A serious problem with this approach is scaling.

Stack overflow runs off one SqlServer. Do you think your app is going beyond that? If yes, maybe this approach will not work for you. If no, you are in the 99,99999% of all other sites/apps that are not as big as SO, FB or google and you can use this simple way to make your site or app.

Re: Simplify: move code into database functions

#39

Post by tunesmith »

y0ghur7_xxx wrote: post #35
tunesmith wrote: post #32

I think it can be a good idea for certain very predictable applications - predictable in terms of scaling and future feature enhancements. But beyond that this strikes me as a bit too complicated. In particular, coupling business logic with database choice is risky. Martin Fowler, Bob Martin, and others underscore that the real cost of development is not the inability to predict the future, but in how difficult or ti…

> As soon as something happens that would bring repository choice into question I don't know. Once a project is started with postgres/mysql/orcale, how often do you change the DB? We have some projects that started with struts, then we changed the fe to jsp, the asp.net, then HTML/JS + MVC.net. But the DB was always Postgres. It never changed. In my experience what changes often is the frontend, not the stuff that ke…

Plenty of examples, although they all tend to be higher-scale considerations that might not apply for your small business or side project:

1) You have "friends" or "friends of friends" modeled in Postgres, but then you realize that you want/need to do more social graph stuff in particular, so it makes more sense to use a graph database like Neo4J

2) You're saving a ton of activity data in postgres but your site is slowing down, and you realize you don't need the archived data, so it makes more sense to use something like Redis for that chunk of data

3) You're saving a ton of log data but the storage of it is going way up, and you're only querying it for big data / data warehouse purposes, so it makes more sense to use something like Cassandra

4) You're wanting to write a new feature set that relies on existing normalized data but would require new complicated queries and joins and business logic to deal with it, plus you're running into scaling considerations, so it makes more sense to convert to a reactive event-based system, such as micro services consuming a kafka topic, where each micro service has its own dedicated repository

In each of those cases, if you have used Postgres combined with sprocs, it's much harder to transition than if you had coded to interfaces and relied on your db in a dumb sense.

Post reply on HN