> On 27 Dec 2016, at 23:03, Guyren Howe <guyren@gmail.com> wrote:
>
> I am putting together some advice for developers about getting the most out of SQL servers in general and Postgres in
particular.I have in mind the likes of most web developers, who through ignorance or a strange cultural preference that
hasemerged, tend to treat their database server as a dumb data bucket.
>
> I call the project Love Your Database (LYDB). It is starting as a series of blog posts:
>
> https://medium.com/@gisborne/love-your-database-lydb-23c69f480a1d#.4jngp2rcb
> https://medium.com/@gisborne/love-your-database-simple-validations-68d5d6d0bbf3#.az4o2s152
>
> I would next like to cover server-side code such as stored procedures and triggers.
I think there's an objection that most developers would come up with: Namely that stored procedures living in the
centralrelational database can usually not be changed as easily as client-side code, without disrupting development (or
worse,operation of the production system) for other users. I think that needs some thought - I don't have the answer to
thatone.
IMO, as long as those stored procedures are part of the model (ensuring data integrity, interpreting database values,
etc.),there shouldn't be a problem, but it's a terrain I haven't trodden much. There are things you usually don't want
tohandle at the database side, such as firing off other applications to perform tasks or user interface related
operations,things like that. I once was tasked with writing a library on a database server (Oracle 8i) to handle
printingof data and sending out faxes etc. That was a nightmare and in hindsight it just doesn't belong in a database.
That'sa task for middleware. Where the dividing line is is probably an interesting topic.
Another thought related to seeing the database as a model server; since we're apparently in the model-view-controller
paradigm,it seems to me that database views would probably be useful to the view-part of MVC. That's just something
thatstruck me to make more than a bit of sense…
Of course, for the actual view in the MVC paradigm there should be some kind of user interface, but database views
couldbe really useful in preparing the data required for those, to make it fit the shape of the view.
So far I like what you're writing, so keep it coming!
Alban Hertroys
--
If you can't see the forest for the trees,
cut the trees and you'll find there is no forest.