Recent Features
| |||||||||||||
PostgreSQL 9.0 arrives with many new featuresPostgreSQL 9.0 arrives with many new featuresPosted Sep 21, 2010 21:46 UTC (Tue) by jberkus (guest, #55561)In reply to: PostgreSQL 9.0 arrives with many new features by flewellyn Parent article: PostgreSQL 9.0 arrives with many new features
The primary utility for an added key-value store is for attributes which need to be extended at runtime, and don't need referential integrity.
A good example of this would be a multi-tenant "personals" site where most of the search criteria were built-in (age, height, weight, marital status, etc.) but where each reseller of the service was allowed to add additional "profile items". Or a web CRM (think SugarCRM) where each salesperson was allowed to add their own "tags".
The alternatives to do this in SQL are all unpalatable: Entity-Attribute-Value tables (crappy performance, huge on-disk size), DDL at runtime (dangerous), or "option_1_id" columns (awkward & confusing to query).
Of course, if you're using Hstore for your core application data, then you're probably using the wrong database. But there's a lot of cases where applications need something like a key-value store for *just one thing*.
(Log in to post comments)
PostgreSQL 9.0 arrives with many new features Posted Sep 21, 2010 22:09 UTC (Tue) by flewellyn (subscriber, #5047) [Link]
I've written applications that do controlled DDL at runtime without problems. I don't see why that's so dangerous.
PostgreSQL 9.0 arrives with many new features Posted Sep 21, 2010 22:19 UTC (Tue) by jberkus (guest, #55561) [Link]
In order for the application to make DDL changes at runtime, the application role needs to have unrestricted permissions on at least some tables. This creates a security hole if the web application is compromised.
The alternative is SECURITY DEFINER functions. However, most web developers don't care much for stored procedures. And, like setuid bits on files, security definer functions are potentially dangerous if not completely locked down.
In either case, you've given someone a complex way of solving their problem which requires more than a bit of database knowledge. If that person is a web GUI developer who is Just Trying To Get The Job Done, they instead end up running the web app with superuser or database owner permissions. As, indeed, SugarCRM did (and maybe still does).
PostgreSQL 9.0 arrives with many new features Posted Sep 22, 2010 5:06 UTC (Wed) by flewellyn (subscriber, #5047) [Link]
Fair enough. I suppose if all you need is extensible attributes without integrity checks, runtime DDL is overkill as well.
PostgreSQL 9.0 arrives with many new features Posted Sep 22, 2010 11:36 UTC (Wed) by tialaramex (subscriber, #21167) [Link]
Flexibility is also (at least for now) the key reason to look at an RDF storage engine.
I guess from a relational database perspective these are just "Entity-Attribute-Value tables" except that of course the attributes and values are also (potentially) entities...
If you actually have a schema that reflects your system's unchanging reality, an RDBMS remains an excellent choice, with lots of mature offerings, excellent performance, etc. RDF will not ever be a competitor for the certainty of "Every X has exactly one Y, which is a unique integer" if you can bludgeon reality to fit such rules.
The interest in key-value stores suggests that more and more people are realising that their problem isn't entirely amenable to this approach. But I'd argue that key-value is not quite flexible enough either.
But it could be that I've been using a hammer so long that now all the more sophisticated problems just look like they haven't been hit hard enough or from the right angle.
PostgreSQL 9.0 arrives with many new features Posted Sep 22, 2010 18:31 UTC (Wed) by jberkus (guest, #55561) [Link]
tialaramex,
There are definitely problems for which RDF is the right answer, and trying to use a relational database for those problems is painful at best. For example, while you *could* do a semantic web thing using a relational database, you wouldn't want to.
On the other hand, there are definitely tasks for which RDF is wildly unsuitable. Just at the moment, I'm working on an inventory management application. Again, you could do such a thing in RDF, but you'd very quickly regret it.
Any database is a model of your real-world data. All models require reductionism, and thus the model format you use should be based on what it is you want to do with the data you have. Claims that one or another data model form is "more realistic" or "more natural" than another are specious. All models are equally artificial.
PostgreSQL 9.0 arrives with many new features Posted Oct 3, 2010 23:01 UTC (Sun) by Wol (guest, #4433) [Link]
Hmm...
Speaking as a mathematician, all models are equal, true.
But speaking as a scientist, that's not true!
Some models (Newtonian Mechanics) are good enough. Some models are a very good fit (Relativity). And some models are just plain irrelevant (toroidal geometry on a ball).
Pick the right model. The "more natural" one. Because the wrong one doesn't approximate to nature (reality).
Cheers,
|
|||||||||||||