Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> Also, stored procedures is a bad thing - business logic should be written in code, not in data and not in the database.

Why?

Your post generally makes a lot of criticisms, but fails to back up any of the points made.



Lot of reasons. Refactoring, unit-tests, readability... If you don't understand my points, it doesn't means they falls :)


You did not mention any of these things in your original post. Why would you assume that he doesn't understand them, if you didn't even bother to type them?

But yes, completely failing to mention a point when attempting to make an argument generally means they fail :)


You talk like teenager.


Dude, that's like, totally SO not true.

You might want to read the HN posting guidelines - your comment history suggests you have not done so yet. I have no interest in continuing a conversation with you, based on the level of discourse evident in your previous comments. Have a good day.


Primarily, because the stored procedures are not effectively under version control.


Maybe yours aren't, but mine are. I've been using this simple tool for three years now.

https://github.com/gluefinance/PgDeploy

It gives you an extra safety net, in case the version in the database would differ compared to the version in the VCS, even though they shouldn't, someone might have been evil behind your back. :)

PgDeploy lets you preview the change and show you a diff. If the diff is expected, you can proceed and deploy.


Only if your workflow is bad and you're editing stuff directly on the DB. Stored procedures work fine with VCS if you write them on files and then run those. Where I work, creating a new database with all the procedures is just a matter of loading the right .sql file.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: