> On 27 Dec 2016, at 23:03, Guyren Howe <guy...@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 has emerged, 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 central relational 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 that one.

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 to handle 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 
printing of data and sending out faxes etc. That was a nightmare and in 
hindsight it just doesn't belong in a database. That's a 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 
that struck 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 could be 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.



-- 
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general

Reply via email to