Create table relates using complex primary and foreign keys (more than 1 field)

05-03-2010 09:40 AM
Status: Open
Occasional Contributor

In the ArcGIS Desktop help topic, Modeling limitations of relationship classes, please allow multiple fields to be used to define the primary and/or secondary keys that define the relationship classes, as well as in-memory relates:

The primary and foreign keys can each be based on one field only; complex primary and foreign keys are not supported in ArcGIS.

I was hoping that this would be resolved back when 9.0 came out, and was yet again disappointed seeing it didn't make it into 10.0 even.

This idea is in here at least three time: see nadiguy and steen suggestions. So it is higher than 180 points...
Yes - I agree regarding the joining of tables in ArcMap - allowing multiple fields to join to multiple fields would be so much easier. There are times where I have to create a new field and calculate it to equal the concatenation of two or more other fields (and do this for both the tables I want to join). Also, sometimes my tables are in an uneditable ArcSDE geodatabase - so I first have to export the datasets to shapefile or file geodatabase to add the new concatenation fields.
What hurts is that I see support for composite keys in the XML Schema of the Geodatabase. So evidently, one could write code to use them--or it's just a stub for future development. In any case, the ability to use composite keys should be part of core and exposed via the GUI. Part of the beauty of the geodatabase, and an oft-marketed benefit, is the ability to get more done without having to write code.
This idea has almost 1 year and doesn´t get enough points. I consider it very useful even now i need it but i had to change my datamodel to 1-M.
I agree I would like to join tables/feature classes using more than one field. I often find myself creating new fields that are a combination of  a number of fields in the feature class just to perform a join even though this now new unique identifer field is meaningless in the real world.
This would be very useful!
I agree.  This would be very useful.  I have a case where features relate based on 2 columns, and I need to find out where the shapes are different for related features in different featureclasses.  By relating on multiple columns, I could then leverage a core function of GIS, spatial comparisons.  Right now, I can't do this without manipulating the data to combine the keys into one field.
This would be great for both relationships and joining.  So many times I have to make a temporary copy of a table just so I can create my own join key by calculating 2 or more fields together.  All RDBMS systems can do this, so many of their tables do no have a single unique identifier that will join well, most use joins with compound keys