Storing geometry deltas

Question

At my workplace for spatial tables they have a data management process where when a new version of a spatial table is ready to load - they delete all the rows in the existing table and drop all indexes on the table. Then the new data is loaded into the table and the indexes are created again.
However, for a few of the spatial tables I work on, what I would like is to be able to still retain all historic geometry. For example the primary key is site_no, I want to compare the geometry changes for site_number 1 between 2007, 2008, 2009 etc.
At first I thought that I would put all the geometry (both old and current) into a single table with a date column:
CREATE TABLE all_geom_test (
SITE_NO                   NUMBER,
GEOMETRY_DATE    DATE DEFAULT SYSDATE NOT NULL,
GEOMETRY              MDSYS.SDO_GEOMETRY);
I then made a view which selected the most recent geometry for each site_no.
However, I have found there are a couple of problems with this: A site_no might exist in 2008 but then be deleted - therefore not exist - in next year's version of the spatial data set. But the view is still selecting the 2008 geometry. The other problem is that the all_geom_test table is going to get very big. For the first problem the only solution I can think of is to have a 'deleted_flag' column.
What would be a better way to store this geometry? How could I store only the deltas between versions or a base version?

Answer 1

996454 wrote:
However, for a few of the spatial tables I work on, what I would like is to be able to still retain all historic geometry. For example the primary key is site_no, I want to compare the geometry changes for site_number 1 between 2007, 2008, 2009 etc.
Interesting challenge. Have you had a look at Workspace Manager? Contents
I then made a view which selected the most recent geometry for each site_no. However, I have found there are a couple of problems with this: A site_no might exist in 2008 but then be deleted - therefore not exist - in next year's version of the spatial data set. But the view is still selecting the 2008 geometry.
It would be helpful if you give the definition of your view. There's no way of knowing why the view is still selecting 2008 geometry if we don't have sample data and the query that is not supposed to select it.
996454 wrote:
The other problem is that the all_geom_test table is going to get very big. For the first problem the only solution I can think of is to have a 'deleted_flag' column.
What would be a better way to store this geometry? How could I store only the deltas between versions or a base version?
History tends to become very very big very quickly. So what you have to look at before you implement a solution is if you really really really need that history to be available (other than your normal backups). If the answer is yes, then I would suggest to have a look at partitioning your table and especially your spatial index. Works great, the partitioned spatial indexes will prune your table for you without the need to put the partitioning column in your where clause, and performance is superb.
As for the second part of your question: What do you mean by "deltas"? The actual changes in vertices of your geometry? That would be spossible, but at a cost. I currently maintain a database for a customer who simply puts the system date and time in an "ObjectEndTime" column when the record is updated or deleted, which means you can select older versions of your geometry quite easily. But calculating the difference between geometries takes a bit more work, and besides: what if one of the other columns has changed but the geometrie hasn't? You'll get and empty geometry if you calculate the differences between the geometries, because there is no difference. So I think you need to go back to the drawing board and re-think what it is you want to achieve -  and have a serious look at Workspace Manager.
Of course if you can describe what exactly it is you want to achieve you can ask here: there's always lot's of people around here with brilliant ideas that I have used quite a lot