Multi-value fields, parent/child designs, and workflows...how's that work? Doug Finner 6.May.14 02:52 PM a Web browser General 7.0.3Windows 2000
So I'm curious. I've played around a little with SP and from what I see, moving simple raw document data from Notes to SP is likely to be relatively simple.
Multi-value fields will be more interesting since SQL dbs don't have that concept. I presume your system somehow normalizes multi-value fields into linked tables (at the SQL level anyway).
It seems to me that workflows would need to be totally rewritten. I see this as the hard part of a migration. Apps have real-time workflows that are user driven and may depend on the user's role, and/or the state of one to many records. Apps also have scheduled agents that drive docs through the workflow, generate notifications, and manage any escalation process. Worflows can be managed by code written in @Function, LS, JS, or even Java.
I also see complexity in moving from a doc/response doc/response to response doc heirarchy to a SQL design especially if the parent and child docs update each other based on program logic. As a ferinstance, I have a parent with 5 child 'action' docs. When the last action is completed, the parent is updated to a 'done' status.
Any information you can publically share about howyour product handles these issues would be appreciated.