Topic
  • 3 replies
  • Latest Post - ‏2009-12-01T16:57:46Z by Sr1n1L
Sr1n1L
Sr1n1L
3 Posts

Pinned topic !!!! Urgent Help on Metadata Design Decisions !!!!

‏2009-11-24T16:08:47Z |
Hello:

We are faced with a challenge to our project where we have way too much business metadata we want to store for each record/document in P8. The decision has been made to externalize all the business data outside in a SQL DB. By using the Document ID that P8 stores for each record/document will be stored in the SQL DB as a foreign key. So all the application searches will go against the SQL DB and use the Document ID to retrieve the document from FileNet. I am sure this works and seem like a perfect solution to speed up the searches and indexing scheme on the metadata.

Question is, can we externalize the Document ID that FileNet generates for the record/document? Is this a best practice? Is this safe if ever the FileNet ObjectStore is upgraded from one version to the other or what ever?

Any help will be greatly appreciated.
Thank you
--
SL
Updated on 2009-12-01T16:57:46Z at 2009-12-01T16:57:46Z by Sr1n1L
  • Sr1n1L
    Sr1n1L
    3 Posts

    Re: !!!! Urgent Help on Metadata Design Decisions !!!!

    ‏2009-11-30T17:28:41Z  
    I am really shocked to see that there are no replies .... not even some IBM representation or monitoring for that big of a service company....

    Still looking for some answers please!!!!
  • SystemAdmin
    SystemAdmin
    40 Posts

    Re: !!!! Urgent Help on Metadata Design Decisions !!!!

    ‏2009-12-01T15:49:31Z  
    • Sr1n1L
    • ‏2009-11-30T17:28:41Z
    I am really shocked to see that there are no replies .... not even some IBM representation or monitoring for that big of a service company....

    Still looking for some answers please!!!!
    Hi,

    I did something like that in Content Services (few years ago) because Content Service metadata model is not that flexible as P8 metadata model. Regarding you concern about externalize the metadata to another database, from my point of view, is ok if you use a custom application who know how to deal this situation.

    For sure ... this is not a best practice, and will not speed up your searches. Will speed up the SQL search (may be) but if you need to apply security filters (authorization) on search results ... overall you will obtain a poor performance.

    I have two suggestions for you:
    1. keep in P8 all valuable metadata (all metadata for which you will perform searches) and "move" the other metadata in another SQL DB.
    or
    2. keep all valuable metadata (all metadata for which you will perform searches) on main document class, and use custom object classes to model the other metadata, and properties of type "object" to "link" custom object instances to document/record
  • Sr1n1L
    Sr1n1L
    3 Posts

    Re: !!!! Urgent Help on Metadata Design Decisions !!!!

    ‏2009-12-01T16:57:46Z  
    Hi,

    I did something like that in Content Services (few years ago) because Content Service metadata model is not that flexible as P8 metadata model. Regarding you concern about externalize the metadata to another database, from my point of view, is ok if you use a custom application who know how to deal this situation.

    For sure ... this is not a best practice, and will not speed up your searches. Will speed up the SQL search (may be) but if you need to apply security filters (authorization) on search results ... overall you will obtain a poor performance.

    I have two suggestions for you:
    1. keep in P8 all valuable metadata (all metadata for which you will perform searches) and "move" the other metadata in another SQL DB.
    or
    2. keep all valuable metadata (all metadata for which you will perform searches) on main document class, and use custom object classes to model the other metadata, and properties of type "object" to "link" custom object instances to document/record
    Thank you for your response. I think there is a push back from FileNet group internally to keep the metadata used for searches away from FileNet and do against the DB itself.