Specify 6 offers a greater flexibility with the new tables collectionobjectattr and collectingeventattr associated with a custom definition attributedef.
Question : should we use the Specify 6 tables by default ? Or can we still use the Specify 5 tables if the predefined attributes are more than enough for our needs ?
Corollary question : could Specify 5 tables collectingeventattribute and collectionobjectattribute be marked as deprecated and removed from the schema in future release?
The CollectionObjectAttrs relationship and table are not meant to be used at this time. You can however use the CollectionObjectAttribute relationship and table!
Regarding your question, we recommend using the “Specify 5” tables, collectionobjectattribute and collectingeventattribute, by default. These tables are the ones we currently support and encourage users to use despite the Specify 6 tables, collectionobjectattr and collectingeventattr, being included in the database.
These *attr tables were part of an earlier plan (>15 years ago) that was never fully developed. We discourage using these tables and instead point users to the *attribute tables for their needs.
Regarding your corollary question, we may eventually mark the *attr tables as deprecated and remove them from the schema in a future release. However, they remain in the current version, and we have no plans to remove them at this time. The *attribute tables, however, are here to stay.
If you require a one-to-many relationship, we recommend using the *property tables, such as collectionobjectproperty and preparationproperty, which are designed for such cases.
The guidance to use the collectionobjectattribute relationship and table still stands!
I have a question, and I’ll try to be as precise as possible as it’s not easy to describe.
Is it possible to use the Collecting Event Attribute table as a many-to-one relationship, or is its behavior the same as the Collecting Object Attribute table?
Or is it better to use another table with a many-to-one relationship, such as Collecting Trip, to really have a Collecting Event grouping?
Because when you use the Collection Object Attribute table, during mass integration it automatically creates a one-to-one relationship with the Collection Object (and not many-to-one).
I hope my explanation is clear. Thank you in advance for your help.
The Collecting Event Attribute table has the same behavior as the Collection Object Attribute table, meaning the software treats it as a one-to-one rather than a many-to-one despite the data model and database technically supporting that relationship.
Collecting Trip is designed specifically for grouping Collecting Event records. If that is your goal, I highly recommend pursuing that option!