> 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,
On Wed, Aug 13, 2014 at 12:43 AM, Seref Arikan
wrote:
> 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
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
deriva
On Tue, Aug 12, 2014 at 8:33 AM, Bill Moran
wrote:
> On Tue, 12 Aug 2014 16:57:32 +0200
> Jimmy Thrasibule wrote:
>
> > > Is there a reason why hstore or json is not an option? That may work
> a lot
> > > better than this approach.
> >
> > I don't want to move away from SQL common features so I
On 8/12/2014 6:19 AM, Jimmy Thrasibule wrote:
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 th
On Tue, 12 Aug 2014 16:57:32 +0200
Jimmy Thrasibule wrote:
> > Is there a reason why hstore or json is not an option? That may work a lot
> > better than this approach.
>
> I don't want to move away from SQL common features so I can have a
> test environment using SQLite and deploy on PostgreSQ
On 12/08/2014 15:57, Jimmy Thrasibule wrote:
>> Is there a reason why hstore or json is not an option? That may work a lot
>> better than this approach.
>
> I don't want to move away from SQL common features so I can have a
> test environment using SQLite and deploy on PostgreSQL. This approach
>
> Is there a reason why hstore or json is not an option? That may work a lot
> better than this approach.
I don't want to move away from SQL common features so I can have a
test environment using SQLite and deploy on PostgreSQL. This approach
looks elegant and simple to me. Using a new table per
We are currently working on in-database semantic reasoning.
However, if you do not need any T-Box or A-Box reasoning, maybe JSON is
a better choice in your case.
Am 12.08.2014 15:19, schrieb Jimmy Thrasibule:
Hello,
I'm looking into gathering information about geographical locations:
- Coor
Is there a reason why hstore or json is not an option? That may work a lot
better than this approach.
Another approach I have had is a set of additional catalog tables and
dynamically adding/removing columns from an extended attributes table.
On Tue, Aug 12, 2014 at 6:19 AM, Jimmy Thrasibule <
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
tryi
11 matches
Mail list logo
