"Andrew Meador" <an****@meadorcrafts.comwrote in message
news:28**********************************@s50g2000 hsb.googlegroups.com...
I have searched and found where this has been discussed, but the
suggestions I have found have all ended up tuning into debated about
whether it needs to be done - but - as far as I can tell - I need to.
I am trying to setup a database that tracks parcel history. I want
to be able to choose a parcel and see a list of its children (smaller
pieces to the property that have been sold off) and a list of its
parents (previous tracts/parcels that created the current parcel).
This does happen, where I have had pieces of larger parcels that were
sold off from the larger parcels and combined into a single new
parcel. I would like to represent this in some hierarchy 'tree' view
to make it easy for users to select a parcel to see it's details, but
to be able to quickly move up and down the 'tree' studying details of
the selected parcel.
I figured on using a database table with a parcelID, parentParcelID
and other parcel related fields. I could then use selects to return
the parents and childrent o populate some control to display them.
TreeView can't do this since it only supports a single parent. Is
there any other control or method you could recommend to accomplish
this?
Thanks!
With respect to the data modelling, I'd start with the thought that you have
a directed acyclic graph (DAG). Where the 'acyclic' comes in is due to the
fact that logically, if parcel A is subdivided into parcels A1 and A2, that
if sometime later A1 and A2 are combined into a new parcel, that will be B,
not A, even though the plot of land is identical.
The vertices of the DAG represent parcels. You'd store history (start/end
dates) here as well as other parcel information. This system would easily
account for changes in ownership or appurtenances, not just fragmentation
and consolidation of parcels. So you'd have one table to store vertex
(parcel) data.
The edges represent lineage. Another table would store edge data, and each
row would have two parcel IDs - parcelID and parentID. Bear in mind that
"parent" means not just spatial parent but also temporal parents. For a
graph these are the predecessor vertices.
The edge table makes it easy, for any vertex/node V, to find what the
predecessors (parents) and successors (children) are. In the first case you
are looking for all parentIDs for a given parcelID. In the second case you
want all parcelIDs for a given parentID.
I may have just taught my grandmother how to suck eggs, for which I
apologize in advance. But you did mention _one_ database table.
For viewing, well, I'd look for something that just displays graphs. I'm
taking a gander at this:
http://www.codeproject.com/KB/miscctrl/quickgraph.aspx
AHS