4 ms·

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.
• FridgeSeal 5y ago
  Data and its structure outlives the developer, and often the application. Tightly coupling a lot of the application-specific compute in with how the day is stored and accessed says you up for even more difficulties when you need to debug, scale, migrate storage/compute or evolve your application faster or more radically than your data organisation.