| |||||||||||||
Why jsonWhy jsonPosted Sep 11, 2012 4:37 UTC (Tue) by aristedes (guest, #35729)In reply to: Why json by JohnLenz Parent article: PostgreSQL 9.2 released
That makes sense to some extent, but I'm still unclear what real-world environment would exist where there is no server application to manage sessions, authorisation, and enforce data validation. And of course the scary "let's give all our users the complete source code of the application so they can modify it with Firebug to write anything they want to the live database."
Perhaps I am just used to thinking of a database as a big interchangeable repository of data and not an integral part of the application code. Even stored procedures are something I avoid.
I did however discover that you can create functional indexes on json data like this:
CREATE INDEX x_in_json ON mytable (jmember(jsonfield,'x'));
so I can see the point of being able to store certain types of data in this way and still have indexed access to it.
(Log in to post comments)
Why json Posted Sep 11, 2012 13:35 UTC (Tue) by beagnach (guest, #32987) [Link]
>> I'm still unclear what real-world environment would exist where there is
>> no server application to manage sessions, authorisation, and enforce >> data validation.
there's a new generation of client-side JavaScript frameworks - http://backbonejs.org/ is what I'm most familiar with. The client side interface has become so rich that it now needs a proper ORM.
This is _not_ to say we do away with all the sever-side infrastructure you mention (though a few sites seem to go most of the way) - in general there seems to be a hybrid approach where a subset of date is mapped client side for manipulation by the rich interface there.
Of course you want to avoid duplication of models between client and server-side, and of course you still need to validate data - the trend is to reduce the server-side representation, not eliminate it completely.
Why json Posted Sep 13, 2012 19:17 UTC (Thu) by jberkus (subscriber, #55561) [Link]
> Perhaps I am just used to thinking of a database as a big interchangeable
> repository of data and not an integral part of the application code. Even > stored procedures are something I avoid.
Well, the feature is certainly less compelling if that's your orientation towards database systems. However, a modern DBMS is a powerful, feature-rich parallel execution engine, and some users like to harness that capability. If you don't want to use it, you don't have to.
The main benefit to this is that some users can eliminate the need to use a document database alongside PostgreSQL in mixed environments. This simplifies administration and provisioning.
|
|||||||||||||