3 ms·

When I first started out, I treated my database as just a dumb datastore. Thankfully my database was Postgres (a decision made by the team I got a job with, who

When I first started out, I treated my database as just a dumb datastore. Thankfully my database was Postgres (a decision made by the team I got a job with, who obviously were much smarter than me). I think most programmers start out this way, probably because they learn a procedural language (PHP, Python, Perl) before SQL. So it's easier to write their application rules there. Regardless, even when I was using Postgres as a dumb store, I was still using it to enforce uniqueness --- which is otherwise very hard to do anywhere else. Later I started to add foreign-key constraints (I know!). Slowly I found out that other things, like eligibility checking, complex calculations, and other processing, were always much shorter in SQL than in my procedural language (which had to pull the data from the database anyway to work on it). And all other things being equal, my criterion for how to do something is, "Which way is shorter?" That's usually also the fastest to run and the easiest to maintain (though I'm not talking about using one-letter names for variables and functions --- at least not always ;). Now I'm slowly moving toward my middle language (PHP) being little more than a templating language. I think I heard that Oracle had even moved HTML formatting to the database in one of their products, but that's going a little too far.

einhverfr 10y ago
I think part of the issue is that SQL is not a programming language. You cannot really express algorithms in the normal sense in SQL. Instead you specify a result and let the db decide the algorithm. So SQL is a language you program around, not a language you program in. I.e. you can extend and consume SQL. BTW, don't move your HTML into the db :-) Separate presentation and data logic. (We are teaching a course[1] in Sweden on programming against PostgreSQL. It focuses on much of this as well as trying to look under the hood to deal with what happens when the abstraction fails to deliver what is expected.) At the end, this is a longish path and one that took me personally a long time to make. But it is something that he more we share, the better off others will be I think. [1]https://edument.se/education/categories/sql/advanced-postgresql https://edument.se/education/categories/sql/advanced-postgre...
- dozzie 10y ago
  > I think part of the issue is that SQL is not a programming language. You cannot really express algorithms in the normal sense in SQL. 1) You can (namely: PL/SQL). 2) The same situation as in SQL (the query part, not procedural language) you have in Prolog (though SQL query is not Turing-complete). It's a different paradigm of working with data, but it's still a programming language. > Instead you specify a result and let the db decide the algorithm. The term you're looking for is declarative programming.

einhverfr 10y ago

I think part of the issue is that SQL is not a programming language. You cannot really express algorithms in the normal sense in SQL. Instead you specify a result and let the db decide the algorithm. So SQL is a language you program around, not a language you program in. I.e. you can extend and consume SQL. BTW, don't move your HTML into the db :-) Separate presentation and data logic. (We are teaching a course[1] in Sweden on programming against PostgreSQL. It focuses on much of this as well as trying to look under the hood to deal with what happens when the abstraction fails to deliver what is expected.) At the end, this is a longish path and one that took me personally a long time to make. But it is something that he more we share, the better off others will be I think. [1]https://edument.se/education/categories/sql/advanced-postgresql https://edument.se/education/categories/sql/advanced-postgre...

dozzie 10y ago
> I think part of the issue is that SQL is not a programming language. You cannot really express algorithms in the normal sense in SQL. 1) You can (namely: PL/SQL). 2) The same situation as in SQL (the query part, not procedural language) you have in Prolog (though SQL query is not Turing-complete). It's a different paradigm of working with data, but it's still a programming language. > Instead you specify a result and let the db decide the algorithm. The term you're looking for is declarative programming.