8 ms·

Enjoyed that read but to be honest I always had mixed feelings about PSQL Extensions. Logic in a database is wrong

snissn 5y ago
It’s so amazing to have the ability to enhance your database with custom methods. Keeps your data model really well organized across your infrastructure
- systemvoltage 5y ago
  That's the job of an API IMO.
  - uoaei 5y ago
    An API makes sense for this case when you won't be throwing away a lot of the raw data in favor of the processed/transformed data. But doing a lot of these operations on-server makes sense when there's a significant volume of highly parallelizable transformations which need to be done on the data before it's usable. Of course the best solution is likely to be a happy medium between the two, where simple low-level transformations are done on-server and the rest of the data preparation is done as the data is transferred to the client.
  - mrbungie 5y ago
    Not in data processing. There are cases where you have so much data that is better to bring computation to data rather than the other way around.
    - FridgeSeal 5y ago
      Having dealt with the fallout of a database that’s had hundreds of stored procedures and custom code stapled into it: never again. It was so hard to debug, so hard to safely maintain these procs, and a general nightmare
arthurcolle 5y ago
Do what thou wilt shall be the whole of the Law
deleted 5y ago
[deleted]
CameronNemo 5y ago
Can you expand on why you think it is wrong or problematic?
- systemvoltage 5y ago
  Database is the last thing that scales usually so if you put a bunch of computational load on it besides queries, you've set yourself up for scaling/sharding sooner than later.
  - lowwave 5y ago
    Not always! If computation involves math over set of records, then Postgres is great for that. Have the operation inside the db reduce connection pooling on the application level.
  - jamesfinlayson 5y ago
    I remember a friend telling me in a previous job me they loaded the database with stored procedures because it ran on the most powerful server when the product launched. And then the database server hit its capacity very quickly.
    - rbanffy 5y ago
      Reminds me of why I learned to program in PostScript - the PostScript printer was, by far, the fastest computer I had access to - also it had a ton of memory and its very own SCSI hard disk. Plotting a Mandelbrot on the Mac would take a lot longer, even in C, than just making the printer do it. Usually overnight, because the program took a couple hours to run most of the time.
  - rbanffy 5y ago
    > you've set yourself up for scaling/sharding sooner than later. OTOH, if you can pre-process the data (or shards) in the server (or servers), you won't need to move it across the network for processing. Hard problems are hard and one of the reasons databases outlive their systems and developers is because moving that data is a Royal Pain.

It’s so amazing to have the ability to enhance your database with custom methods. Keeps your data model really well organized across your infrastructure

systemvoltage 5y ago
That's the job of an API IMO.
- uoaei 5y ago
  An API makes sense for this case when you won't be throwing away a lot of the raw data in favor of the processed/transformed data. But doing a lot of these operations on-server makes sense when there's a significant volume of highly parallelizable transformations which need to be done on the data before it's usable. Of course the best solution is likely to be a happy medium between the two, where simple low-level transformations are done on-server and the rest of the data preparation is done as the data is transferred to the client.
- mrbungie 5y ago
  Not in data processing. There are cases where you have so much data that is better to bring computation to data rather than the other way around.
  - FridgeSeal 5y ago
    Having dealt with the fallout of a database that’s had hundreds of stored procedures and custom code stapled into it: never again. It was so hard to debug, so hard to safely maintain these procs, and a general nightmare

arthurcolle 5y ago

Do what thou wilt shall be the whole of the Law

deleted 5y ago

[deleted]

CameronNemo 5y ago

Can you expand on why you think it is wrong or problematic?

systemvoltage 5y ago
Database is the last thing that scales usually so if you put a bunch of computational load on it besides queries, you've set yourself up for scaling/sharding sooner than later.
- lowwave 5y ago
  Not always! If computation involves math over set of records, then Postgres is great for that. Have the operation inside the db reduce connection pooling on the application level.
- jamesfinlayson 5y ago
  I remember a friend telling me in a previous job me they loaded the database with stored procedures because it ran on the most powerful server when the product launched. And then the database server hit its capacity very quickly.
  - rbanffy 5y ago
    Reminds me of why I learned to program in PostScript - the PostScript printer was, by far, the fastest computer I had access to - also it had a ton of memory and its very own SCSI hard disk. Plotting a Mandelbrot on the Mac would take a lot longer, even in C, than just making the printer do it. Usually overnight, because the program took a couple hours to run most of the time.
- rbanffy 5y ago
  > you've set yourself up for scaling/sharding sooner than later. OTOH, if you can pre-process the data (or shards) in the server (or servers), you won't need to move it across the network for processing. Hard problems are hard and one of the reasons databases outlive their systems and developers is because moving that data is a Royal Pain.