4 ms·

> People used to defend writing things in assembly language for similar reasons, as a way of getting more machine sympathy. I'm not buying it. I have to assume

> People used to defend writing things in assembly language for similar reasons, as a way of getting more machine sympathy. I'm not buying it. I have to assume those people did not first learn and use C, then went to assembly, but rather the opposite ;) So, the comparaison does not apply, here. > you're still writing the same basic SQL statements (for the 80% of your database interactions that are essentially CRUD) It's not the case, actually. My functions are way more expressive that the crud I did with orms. With PL/pgSQL, I group several queries in a same pg function, I always do more that a simple insert or update. I also fine tune my returned fields - which most of the time are composite from several tables / computations. This is really outsourcing all data manipulation to the database, the comparison that applies is more with a presenter/serializer than with an orm model.

neospice 10y ago
What are the typical trade-offs of outsourcing all the data manipulation & lookups to the DB. Are there cases when this is absolutely what you don't want to do? I realize this is a very general and vague question but it's something I've been pondering about.
- oelmekki 10y ago
  By far, it is dealing with migrations. Initially, I would use `\ef <func_name>` in psql and just write and try my function, but this turned out to be not as pleasant as writing code in an editor in a dedicated file. The annoying thing with pg functions is that, if you want to replace them, you have to provide exactly the same in and out parameters. This means that if you want to change the parameters, you have to drop the function and create a new one. This has been annoying at first, but now I'm more comfortable with it. I write my functions as migration files [1] and just migrate/rollback to do my tests. I guess I started to give more attention to the input and output parameters from the start in the mean time. The cases where I won't use functions is when I want to do something extremely simple, like `SELECT email FROM users WHERE id = 1`. It's just not worth writing a function for that. It doesn't happen often that this is all I need to process my request either. [1] I use https://github.com/mattes/migrate https://github.com/mattes/migrate

neospice 10y ago

What are the typical trade-offs of outsourcing all the data manipulation & lookups to the DB. Are there cases when this is absolutely what you don't want to do? I realize this is a very general and vague question but it's something I've been pondering about.

oelmekki 10y ago
By far, it is dealing with migrations. Initially, I would use `\ef <func_name>` in psql and just write and try my function, but this turned out to be not as pleasant as writing code in an editor in a dedicated file. The annoying thing with pg functions is that, if you want to replace them, you have to provide exactly the same in and out parameters. This means that if you want to change the parameters, you have to drop the function and create a new one. This has been annoying at first, but now I'm more comfortable with it. I write my functions as migration files [1] and just migrate/rollback to do my tests. I guess I started to give more attention to the input and output parameters from the start in the mean time. The cases where I won't use functions is when I want to do something extremely simple, like `SELECT email FROM users WHERE id = 1`. It's just not worth writing a function for that. It doesn't happen often that this is all I need to process my request either. [1] I use https://github.com/mattes/migrate https://github.com/mattes/migrate