Re: PostgreSQL as a triple store

From: Seref Arikan <serefarikan(at)gmail(dot)com>
To: PG-General Mailing List <pgsql-general(at)postgresql(dot)org>
Subject: Re: PostgreSQL as a triple store
Date: 2014-08-13 07:43:54
Message-ID: CA+4Thdp-BLc5Acw-RfByX1zVR6UVA+s2PUNxJwsKBA8YJXnbcg@mail.gmail.com
Views: Raw Message | Whole Thread | Download mbox | Resend email
Thread:
Lists: pgsql-general

Hi Jimmy,
I think you're going to need to perform experiments and decide if the
flexibility you get is worth the performance you're going to lose.
As you can see from John R Pierce's response it is only matter of time
before someone (correctly) warns you about the performance issues with EAV
derivatives, but then the conversation becomes too abstract, at least in my
opinion.
Why? Because we don't know how much data you're going to process with this
design, with what kind of hardware.

I've developed solutions where I've used EAV along with a more relational
design, they were delivered on time, performed at the expected/acceptable
level, so no problems. Then again, I've tried to use EAV bluntly in a
healthcare related project and it died on me quite quickly when the data
grew.

I always use on demand Amazon instances to test performance of the db
design to test performance using automatically generated data. It is a very
good way of testing your design as data grows and I suggest you consider
the same approach.

Also, your requirements sounds related to some projects that use PostGis,
have you taken a look at that?

Best regards
Seref

On Tue, Aug 12, 2014 at 2:19 PM, Jimmy Thrasibule <
thrasibule(dot)jimmy(at)gmail(dot)com> wrote:

> Hello,
>
> I'm looking into gathering information about geographical locations:
>
> - Coordinates
> - Place name
> - Pictures
> - etc.
>
> Since a place can be anything, a specific place may need any kind of data
> type to be described.
>
> I'm therefore looking into using the same method as the semantic Web and
> trying to describe a place with triples.
>
> 1. The "triples" table will reference a subject, attribute and value.
> 2. The "attributes" table will have an attribute name, a type and mauve a
> table name.
> 3. For each attribute type, a new table is created to store the values.
> 4. A "resources" table list all the available resources (location,
> picture, ...).
>
> Using this, I can easily add a new resource and describe it by adding new
> triples. Every item is identified using UUIDs as primary key.
>
> This seems too simple to be true so I falling back to you in case you see
> any pitfalls here.
>
> The "triples" table will grow very fast in this setup and may become a
> bottleneck. However, I don't see any other way to store information about
> something as wide as places around the world.
>
> Regards,
> Jimmy
>

In response to

Responses

Browse pgsql-general by date

  From Date Subject
Next Message pinker 2014-08-13 08:07:09 Re: Database block lifecycle
Previous Message Albe Laurenz 2014-08-13 06:59:22 Re: Inserting large binary data into lo type table