So I read through all the documents on relationship classes and I am still confused about how to go about it. What I am trying to do is this:
We have a hydrant feature class in our water feature dataset. (which is an enterprise gdb, 10.3.1) I recently created an editable web application for our field guys to enter flushing data for when they flush particular hydrants. This data is used to account for waterloss. But I was told that they need to keep archival data on the hydrants that they flush. And because my original set-up was just adding the fields they needed to put info into directly into the hydrants feature class this only allows for one time data input. So, in order to get around this it was suggested that I create a relationship class (1-M) where I create a new sde table have this be my destintion table and use our existing hydrant feature class as the origin table. Then just have them edit the destintion table this allow for entering multiple flow data for one hydrant thus keeping old readings.
So, I guess where I am confused is in the creation of the new table that will be edited to, or the destination table. Because our sde default is versioned and has replication I was jsut going to use the Global ID field as my PK. So to do this do i just create a new table and import my schema from my hydrants layer or do I want to import all data into the new table that way Global ID field is populated with the Global Id from my Hydrants FC. and that would be my FK in the destination table. Then my last question is if I get this succesfully set up how do I get the table to be the one that is edited when they click on the hydrant in the map instead of the actual hydrant FC.
If any of this makes sense, any guidence would be appreciated. Thanks.
I think you are on the right track and if I am reading correctly you want to use the GUID of the hydrant as your relate item? If so, I suggest using another unique identifier.
In my versioned and replicated feature classes that need relates, I like to add an attribute called JoinId. I calc it to equal the OID of the feature. That way I am ensured of a unique identifier, and if/when I replicate to a child database that unique id remains unique and constant since it based on the original OID.