4 ms·
In most of the example he gives, these solutions are ensuring the integrity of the data stored, which I personally have no problem with; that is the job of the
by jalfresi 11y ago
In most of the example he gives, these solutions are ensuring the integrity of the data stored, which I personally have no problem with; that is the job of the database in my view. If I try and store crap the database should refuse, be that via constraints, triggers or stored procedures.
As for returning the data in JSON, again, I see no problem with that; you were going to get the data out in rows and columns, what difference does JSON make, especially if it simplifies things, as he is arguing.
My main concern is business logic; should business logic be stored in the database. At this point things become a little grey, primarily due to the difficulty in maintaining and managing SQL code. I suppose that PostGres is better that most of the DBs I have had to deal with in the past in this respect in that it supports a wider range of languages for this purpose, but I'd be interested to hear others opinions and experience in this regard.
- calpaterson 11y agoSadly, to some extent the data integrity is part of the business logic. For example, if products can or cannot be sourced from multiple suppliers
- mistermann 11y agoI would agree, at least on SQL Server, in my experience writing logic is just brutally painful, weak language and poor debugging.