We are migrating content from an older filenet system in which compound documents were utilized.  There are a number of cases in which a single child document has hundreds of parents (maximum is 300) and the parents have a unique identifier - provider id.  Our plan for this scenario is to move the child and then attach all of the provider ids via a multivalue property.  Is there a limitation to the number of values that can be stored in a multivalue property?  One of the developers involved is concerned with performance when users attempt to search for documents using this property.   The ids themselves are less than ten digits.  

Not sure what you are aiming at. Are you trying to get rid of the parents/compound documents and attaching their attribute(s) to the child?

Anyway, as soon as you utilize multivalue properties the database has to do a join between (default) ListOfStrings (e.g.) and docversion. If there are lots of values I recommend creating an extra table for those mv values as not to convolute the default tables.

Naturally a join is less efficient as as a single table access (in this case docversion) but unless your system is already overutilzed I'd be surprised if you - as a user -noticed a difference. Modern relational dbs make a good job of optimzing that kind access.

I'd be more concerned if the data model you choose is good for our apps. E.g. ICN has no CD support...

Hope this helps,

/Gerold

We are migrating content from an older filenet system in which compound documents were utilized.  There are a number of cases in which a single child document has hundreds of parents (maximum is 300) and the parents have a unique identifier - provider id.  Our plan for this scenario is to move the child and then attach all of the provider ids via a multivalue property.  Is there a limitation to the number of values that can be stored in a multivalue property?  One of the developers involved is concerned with performance when users attempt to search for documents using this property.   The ids themselves are less than ten digits.  

Hello Gerold

Thank you for the response.  

Yes, our objective is to eliminate the compound document relationship and attach certain attributes of the parents to the children.  

You would recommend a new table for each of the multivalue attributes that could have a large number of values?  Or one new one to capture all of these cases?

Not sure what you are aiming at. Are you trying to get rid of the parents/compound documents and attaching their attribute(s) to the child?

Anyway, as soon as you utilize multivalue properties the database has to do a join between (default) ListOfStrings (e.g.) and docversion. If there are lots of values I recommend creating an extra table for those mv values as not to convolute the default tables.

Naturally a join is less efficient as as a single table access (in this case docversion) but unless your system is already overutilzed I'd be surprised if you - as a user -noticed a difference. Modern relational dbs make a good job of optimzing that kind access.

I'd be more concerned if the data model you choose is good for our apps. E.g. ICN has no CD support...

Hope this helps,

/Gerold

We are migrating content from an older filenet system in which compound documents were utilized.  There are a number of cases in which a single child document has hundreds of parents (maximum is 300) and the parents have a unique identifier - provider id.  Our plan for this scenario is to move the child and then attach all of the provider ids via a multivalue property.  Is there a limitation to the number of values that can be stored in a multivalue property?  One of the developers involved is concerned with performance when users attempt to search for documents using this property.   The ids themselves are less than ten digits.