Search Postgresql Archives

Re: LYDB: What advice about stored procedures and other server side code?

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



> On 27 Dec 2016, at 23:03, Guyren Howe <guyren@xxxxxxxxx> 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@xxxxxxxxxxxxxx)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general




[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
[Index of Archives]     [Postgresql Jobs]     [Postgresql Admin]     [Postgresql Performance]     [Linux Clusters]     [PHP Home]     [PHP on Windows]     [Kernel Newbies]     [PHP Classes]     [PHP Books]     [PHP Databases]     [Postgresql & PHP]     [Yosemite]
  Powered by Linux