4 ms·
> For some reason most people throw out principles we follow in other languages such as... composability just for SQL This is because the most common API for a
by ef4 13y ago
> For some reason most people throw out principles we follow in other languages such as... composability just for SQL
This is because the most common API for accessing databases is wrong and doesn't support composition.
Imagine designing a general-purpose, rich API that has only one method. The method takes one giant string argument. Insane? Absolutely.
SQL is actually awesome and amazing, but many programmers hate it because their API for accessing it is horribly broken. The whole point of relational algebra is that it's... an algebra. None of which is usefully exposed if you're just mashing strings of SQL together.
- bunderbunder 13y agoI'll one up you on that. . . the common approach of treating the database as if it were an API that you shove string arguments into is wrong. Imagine if you developed your website without ever editing a *.js file directly, and instead just programmatically mashed together strings of JavaScript code and emitted them inline in the HTML wherever necessary. You'd probably end up generating much crummier JavaScript code, too. But should you blame JavaScript or your Web application framework for the fact that your client-side scripting is crummy? No, of course not. The real problem is that you're horribly misusing your tools.
- dllthomas 13y agoEsqueleto is a pretty interesting take at putting together SQL without messing with strings. Doesn't quite expose the relational algebra in its full generality, but I've been finding it quite usable. http://hackage.haskell.org/package/esqueleto-1.2.4/docs/Database-Esqueleto.html http://hackage.haskell.org/package/esqueleto-1.2.4/docs/Data...
- einhverfr 13y agoPart of the reason I wrote this: http://search.cpan.org/~einhverfr/PGObject-Simple-Role-0.51/lib/PGObject/Simple/Role.pm http://search.cpan.org/~einhverfr/PGObject-Simple-Role-0.51/... (read the PGObject::Simple docs too, and both are on github). The idea is that you write your sql in .sql files as user defined functions, and then run them as parameterized queries in your code using a declarative interface. No SQL in your Perl, and you get the benefit of encapsulating your database in an API that is not so tightly tied to your application (you can add new optional parameters without throwing off your application).