Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [geogig-dev] Some questions about data modeling

I know. Given we can consider geogig's storage mechanism as an object database, associations could be represented too by a pointer to the related object instance following the same hashing techniques we already use. Just didn't want to extend so much for something not remotely near in the roadmap currently.
It's worth noting though that complex features also imply type inheritance, which geogig is prepared to support internally (you can have feature instances of heterogeneous feature types in the same tree), it's just something not really used right now.

El 8 nov. 2015 18:29, "Jody Garnett" <jgarnett@xxxxxxxxxxxxxxxx> escribió:
Complex features includes the idea of associations - which I usually represented as a foreign key in a database. 

It is a challenging question, I would relax the constraints for now (between buildings an addresses).


On Sun, Nov 8, 2015 at 9:22 PM, Gabriel Roldan <groldan@xxxxxxxxxxxxxxxx> wrote:
There's no way to preserve/enforce those relationships in a geogig repo.
You can import/export the individual tables but given the db constraints that's probably going to fail perhaps depending on the order you perform the operations.

geogig is not and will never be a relational database. It stores feature instances as single blobs, and right now it only supports "simple features".

In a (probably distant) future we could support "complex features" (or just features, in the OGC sense).





On Tue, Nov 3, 2015 at 5:14 AM, <Schmidt.Sebastian2@xxxxxx> wrote:

Hi all,

 

we have a data model modelled in PostGIS containing

·         some Foreign Key Constraints,

·         Some Unique Constraints

·         Some compound Keys (for M:N Join relationship tables)

·         Some specialized Indices for fast data access

 

Now my question is if there are ways to keep those elements inside a geogig repository?

Or do I need to maintain those objects in a different way outside geogig?

 

When doing a pg import I’m able to specify which row is the primary key for a feature – is there a way to deal with a compound key?

 

My use case is the following:

 

I have a table builidings and a table addresses, which can be m:n joined with a relationship table. It’s primary key is compound of (building_id, address_id) in order to disallow multiple relations. How could I preserve that behavior from pg import -> geogig -> pg export into a fresh database/schema?

 

Kind regards,

Sebastian

 

Mit freundlichen Grüßen

 

Sebastian Schmidt

S-IP-AN-TG Techn. Geschäftsfelder
Telefon: 171-4478

 


_______________________________________________
geogig-dev mailing list
geogig-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
http://www.locationtech.org/mailman/listinfo/geogig-dev



--

Gabriel Roldán
Software Developer | Boundless
groldan@xxxxxxxxxxxxxxxx
@boundlessgeo



_______________________________________________
geogig-dev mailing list
geogig-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
http://www.locationtech.org/mailman/listinfo/geogig-dev



--

--
Jody Garnett
Community Lead | Boundless
jgarnett@xxxxxxxxxxxxxxxx
@jodygarnett

http://boundlessgeo.com/


_______________________________________________
geogig-dev mailing list
geogig-dev@xxxxxxxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
http://www.locationtech.org/mailman/listinfo/geogig-dev

Back to the top