Hi, Just something interesting I noticed today.. As you've probably already seen, PostgreSQL 9.2 added support for storing JSON documents in a 'json' type field. It also adds the V8 javascript engine as a first-class procedural language. Initially I thought that you'd probably end up with a lot of tables with key metadata separated out into your int/char/etc types so you could index it.. but someone has pointed out that you can index into the json data using the v8 engine and Postgres' functional indexes. That is reasonably nifty. Currently you need to write a couple of helper functions yourself, but I suspect we'll see more of this brought into the built-in functions by 9.3. For examples, see: http://people.planetpostgresql.org/andrew/index.php?/archives/249-Using-PLV8... Cheers, Toby
On Thu, Oct 04, 2012 at 09:56:44AM +1000, Toby Corkindale wrote:
Hi, Just something interesting I noticed today..
As you've probably already seen, PostgreSQL 9.2 added support for storing JSON documents in a 'json' type field.
this is a cool and interesting feature but it will serve to encourage even more morons to avoid even basic/minimalist database normalisation methods. i'm getting tired of seeing FOSS programs that use databases just stuff JSON or XML or CSV or similar into a text field. their reasoning seems to be that the data will only ever be used by their own web app or via their REST API so there's no need to spend any time thinking about or designing the database schema (or maybe there's no reasoning and they're just ignorant and stupid). Data lock-in is no less irritating in FOSS apps than it is in proprietary apps. also, why do something in the database server when you can do a half-arsed emulation of it 10,000 times less efficiently in your crappy php web app? pg's support for JSON fields isn't a bad thing - overall, it's a good thing...it will mitigate some of the problems - but it won't do anything to educate web-dev morons about database design. craig -- craig sanders <cas@taz.net.au> BOFH excuse #233: TCP/IP UDP alarm threshold is set too low.
Just something interesting I noticed today..
As you've probably already seen, PostgreSQL 9.2 added support for storing JSON documents in a 'json' type field.
this is a cool and interesting feature but it will serve to encourage even more morons to avoid even basic/minimalist database normalisation methods.
[snipped]
pg's support for JSON fields isn't a bad thing - overall, it's a good thing...it will mitigate some of the problems - but it won't do anything to educate web-dev morons about database design.
While having support for more languages within the server, is generally a good thing... I am generally in agreement that storing JSON directly to the database, is a bad thing -> as it will encourage developers to no bother to sanitize their inputs. cheers, Mathew
Craig Sanders <cas@taz.net.au> wrote:
pg's support for JSON fields isn't a bad thing - overall, it's a good thing...it will mitigate some of the problems - but it won't do anything to educate web-dev morons about database design.
They're supposed to have been educated in it if they studied information systems or computer science at university, but Web development does seem to attract people from a wide variety of backgrounds, many of whom may not have seen fit to educate themselves if they didn't formally study this material. I know there's some set theory involved (n-tuples, relations, etc.), and that's about the extent of my knowledge, but then I don't work with databases. And I think the database world is where B-trees come from, too. At least I know what I would have to learn should the need arise; there are people who wouldn't even realize such knowledge existed, including some who ought to know better.
On 10/10/12 09:18, Craig Sanders wrote:
On Thu, Oct 04, 2012 at 09:56:44AM +1000, Toby Corkindale wrote:
Hi, Just something interesting I noticed today..
As you've probably already seen, PostgreSQL 9.2 added support for storing JSON documents in a 'json' type field.
this is a cool and interesting feature but it will serve to encourage even more morons to avoid even basic/minimalist database normalisation methods.
i'm getting tired of seeing FOSS programs that use databases just stuff JSON or XML or CSV or similar into a text field.
their reasoning seems to be that the data will only ever be used by their own web app or via their REST API so there's no need to spend any time thinking about or designing the database schema (or maybe there's no reasoning and they're just ignorant and stupid). Data lock-in is no less irritating in FOSS apps than it is in proprietary apps.
also, why do something in the database server when you can do a half-arsed emulation of it 10,000 times less efficiently in your crappy php web app?
pg's support for JSON fields isn't a bad thing - overall, it's a good thing...it will mitigate some of the problems - but it won't do anything to educate web-dev morons about database design.
Nothing has stopped people putting arbitrary documents into TEXT or BYTEA fields before -- I've seen plenty of cases where people use Perl's Storable, Python's Pickles, YAML, or custom serialisation, and just dump that into a text field in the database. In one company I worked at, someone had even written a query-creator which would build the appropriate LIKE phrase to search within the serialised format! (But needless to say, it performed atrociously slowly, because you're doing a full table scan every time..) I agree with you, that this practice is usually indicative of poor design -- even if the database offers ways to index and query the document natively. (Which is still a big improvement though) However, I think you're missing a point. Sometimes you are really storing a whole document, or at least a large amount of very structured, self-contained data. For these cases, JSON storage is quite useful and document storage is a lot neater (and performant) than having to write a whole heap of code to deparse and reparse it into all the constituent components. -Toby
Toby Corkindale <toby.corkindale@strategicdata.com.au> wrote:
However, I think you're missing a point. Sometimes you are really storing a whole document, or at least a large amount of very structured, self-contained data. For these cases, JSON storage is quite useful and document storage is a lot neater (and performant) than having to write a whole heap of code to deparse and reparse it into all the constituent components.
As I recall, this is where database systems differ from information retrieval systems. The latter are designed to store documents (or at least document fragments). Their search strategies and result ranking algorithms are designed accordingly.
Toby Corkindale writes:
However, I think you're missing a point. Sometimes you are really storing a whole document, or at least a large amount of very structured, self-contained data.
If the data are hierarchical (JSON) rather than relational, especially if they're of arbitrary depth, is it even appropriate to use an RDBMS? Like Jason, this is not my field, but I get the impression the moronic end of the spectrum reasons thusly: "I have data, therefore I need a [relational] database". All they know are spanners, so they are madly spannering nails into 2x4s and enthusiastic about the new claw-sided spanners to help pry out old nails.
participants (5)
-
Craig Sanders -
Jason White -
Mathew Robertson -
Toby Corkindale -
trentbuck＠gmail.com