Rob,
There are many users of hstore, so you can get support here. Also, someone
is working on the new improved version of hstore, check pgfoundry and
-hackers mailing list.
Oleg
On Mon, 28 Sep 2009, InterRob wrote:
Second glance: brilliant again! Even support for indexing is available; nice
j
Second glance: brilliant again! Even support for indexing is available; nice
job.
I found the hstore.sql -- that will add type, functions and stuff to my db.
I will give it a serious try!
Rob
2009/9/28 InterRob
> At first glance: brilliant! I was about to implement this key/value thing
> with
At first glance: brilliant! I was about to implement this key/value thing
with an XML type... I will take a closer look at this, thanks a lot, Oleg!
Tips & tricks to get this going in PostgreSQL?
Rob
2009/9/28 Oleg Bartunov
> Have you considered contrib/hstore to build flexible database scheme
Have you considered contrib/hstore to build flexible database scheme ?
Oleg
On Sun, 27 Sep 2009, InterRob wrote:
Dear David, dear Peter, dear all,
Peter, I was happy reading your reply right after I opened and read Davids.
I do think I am on the right track; it is not a matter of building the
o
Hi Rob,
InterRob wrote:
If you think so, then I we do in fact agree on that... Still, however,
implementing this transparently (that is: back-end/server side; using
VIEWs, is the only way I can think of) is a major challenge.
Implementing the use of USER DEFINED additional fields within a cer
On Sun, Sep 27, 2009 at 5:44 PM, InterRob wrote:
> Oliver,
> Would you say it is not valid for proposition 2 (people wanting to be able
> to quickly add (and remove?) attributes) because within the relational model
> this can be done reasonably well?
Actually that's what I think it's best at, as
Oliver,
Would you say it is not valid for proposition 2 (people wanting to be able
to quickly add (and remove?) attributes) because within the relational model
this can be done reasonably well?
If you think so, then I we do in fact agree on that... Still, however,
implementing this transparently (
On 27 Sep 2009, at 21:10, InterRob wrote:
Peter, may I invite you to privately share some more details on the
system you are using and the design of it? Did you implement it
using PostgreSQL? Looking forward to your reply.
(And with respect to your previous message: whom are you actually
Dear David, dear Peter, dear all,
Peter, I was happy reading your reply right after I opened and read Davids.
I do think I am on the right track; it is not a matter of building the
one-and-only right schema, not in this case. Archaeology has the same twist
as has ethnography, antropology and alike:
On Sun, Sep 27, 2009 at 2:22 PM, David Fetter wrote:
> On Sun, Sep 27, 2009 at 08:26:27PM +0200, InterRob wrote:
>> Dear David, dear all,
>> I very well understand what you are saying...
>
> Clearly you do not. What you are proposing has been tried many, many
> times before, and universally fails
On Sun, Sep 27, 2009 at 08:26:27PM +0200, InterRob wrote:
> Dear David, dear all,
> I very well understand what you are saying...
Clearly you do not. What you are proposing has been tried many, many
times before, and universally fails.
That your people are failing to get together and agree to a
In fact, I considered doing so, yes... But no luck: to complicate things, I
will need the support for spatial datatypes, as implemented by the contrib
"PostGIS"... Moreover: various applications that will make-up the front-end,
will only be able to talk with mainstraim or ODBC-compatible databases
Dear David, dear all,
I very well understand what you are saying... However, the solution won't be
found in the direction you are suggesting: the system I am designing will be
used by archaeologists, involved in archaeological research (fieldwork).
Their research strategy (and with it their methodo
On Thu, Sep 24, 2009 at 06:28:28PM +0200, InterRob wrote:
> Dear List,
> I am trying to implement the following:
>
> In a database I wish to implement a GENERIC datamodel, thus on a
> meta-level.
That's not a very bright idea, even though it seems so when you first
think of it.
Relational databa
On Sep 24, 2009, at 2:07 PM, InterRob wrote:
I guess it IS quite overengineered indeed...
What I'm trying to do is to facilitate different fieldwork
methodologies for archaeological research (on project basis); there
is no final agreement on data structure and semantics; however, on a
me
Drifting off topic so I'm no longer ccing the lists.
Sam Mason wrote:
>
>> The perl Fuse::DBI module's example sounds pretty similar to the
>> system you described where he "file" seems to be a column in a table.
>> http://www.rot13.org/~dpavlin/fuse_dbi.html
>
> FUSE looks pretty easy to get g
On Fri, Sep 25, 2009 at 11:01:02AM -0700, Ron Mayer wrote:
> Sam Mason wrote:
> > It all depends on the problem domain of course, but this seems to work
> > OK for us! I really want to hack Samba around so that the users can
> > view the files directly from inside the database, but I'm not sure ho
Sam Mason wrote:
> It all depends on the problem domain of course, but this seems to work
> OK for us! I really want to hack Samba around so that the users can
> view the files directly from inside the database, but I'm not sure how
> good an idea this really.
"hack Samba"? Wouldn't it be easie
On Thu, Sep 24, 2009 at 11:07:31PM +0200, InterRob wrote:
> What I'm trying to do is to facilitate different fieldwork methodologies for
> archaeological research (on project basis); there is no final agreement on
> data structure and semantics; however, on a meta-level all choices are
> rational a
Hi Rob,
In a database I wish to implement a GENERIC datamodel, thus on a
meta-level. All RELATIONS (part of a MODEL) will be a view on some base
(being a table) JOINed with (an) extra column(s). Thus, this view
consists of a number of FIELDS. I whish to make this view editable
(INSERT, UPDATE
On 25 Sep 2009, at 07:22, InterRob wrote:
I guess it IS quite overengineered indeed...
What I'm trying to do is to facilitate different fieldwork
methodologies for archaeological research (on project basis); there
is no final agreement on data structure and semantics; however, on a
meta-
I guess it IS quite overengineered indeed...
What I'm trying to do is to facilitate different fieldwork methodologies for
archaeological research (on project basis); there is no final agreement on
data structure and semantics; however, on a meta-level all choices are
rational and can be modelled...
On Thu, Sep 24, 2009 at 10:33:37PM +0200, InterRob wrote:
> I came to think of another option: putting additional columns (that is:
> addittional to the default set of fields) in xml, in a column that is part
> of row (=object) it belongs to.
> Any body has done so before? Any body has experience w
Sam, Thanks for thinking along.
The thing is that a SINGLE constraint might apply to MULTIPLE fields;
therefore it seems best to build a set of key/value pairs... Multiple
doesComply()s won't do the job :(
BY THE WAY:
I came to think of another option: putting additional columns (that is:
addittio
Thank you, Ben. Well, I'm afraid you got the basic idea... I intend to
implement a hybrid between a fixed schema and an Entity-Attribute-Value
scheme. The schema will be able to cover 90% of the data needs; in other
cases (specific projects) additional fields (and/or tables/relations) will
be neede
On Thu, Sep 24, 2009 at 09:23:35PM +0200, Rob Marjot wrote:
> SELECT doesComply('relationname', keyValues.*) FROM (VALUES('col1',
> CAST(col1 AS TEXT)), VALUES('col2', CAST(col2 AS TEXT))) AS
> keyValues(the_key, the_value);
>
> The function "doesComply()" will then process the CONSTRAINTS table a
Rob Marjot wrote:
Thank you, Ben. Well, I'm afraid you got the basic idea... I intend to
implement a hybrid between a fixed schema and an
Entity-Attribute-Value scheme. The schema will be able to cover 90% of
the data needs; in other cases (specific projects) additional fields
(and/or tables/r
Thank you, Ben. Well, I'm afraid you got the basic idea... I intend to
implement a hybrid between a fixed schema and an Entity-Attribute-Value
scheme. The schema will be able to cover 90% of the data needs; in other
cases (specific projects) additional fields (and/or tables/relations) will
be neede
On Thu, Sep 24, 2009 at 06:28:28PM +0200, InterRob wrote:
> I am trying to implement the following:
>
> In a database I wish to implement a GENERIC datamodel, thus on a meta-level.
Sounds like you're describing an EAV design:
http://en.wikipedia.org/wiki/Entity-attribute-value_model
Designs l
InterRob wrote:
Dear List,
I am trying to implement the following:
[snip]
All suggestions are very much appreciated,
regards,
Rob
It's not clear to me what you're asking, but I suspect the suggestion
you need is the same as if you had asked how to best implement an
Entity-Attribute-Val
Dear List,
I am trying to implement the following:
In a database I wish to implement a GENERIC datamodel, thus on a meta-level.
All RELATIONS (part of a MODEL) will be a view on some base (being a table)
JOINed with (an) extra column(s). Thus, this view consists of a number of
FIELDS. I whish to m
31 matches
Mail list logo
