Currently (0.9.3), a Rice client application must include the KNS tables in their own database. There are a few issues with this, including (but not limited to):
- Results in 2 Document (DOC_HDR) tables, one in KNS, one in KEW
- Results in 2 Document Type (DOC_TYP) tables, one in KNS, one in KEW
- Since the KNS Document Types are stored in tables in the client application, this causes conflicts on the standalone server since there is only a single KEW document type table
List of KNS Tables
Analysis of Tables
Document Header Table - KRNS_DOC_HDR_T
Where this table ends up will depend upon what we decide to do with Document Header. I'm inclined to say this gets moved to the standalone server and combined with KREW_DOC_HDR_T. However, do client applications need to query this data? Does it make sense to keep a table client-side with references to document ids?
Maintenance Document Tables - KRNS_MAINT_DOC_T, KRNS_MAINT_DOC_ATT_T, KRNS_MAINT_LOCK_T
These tables store info about maintenance documents including their XML content, attachments and outstanding locks.
I can't think of a specific reason to require these to live server-side (although they certainly could). I do believe the attachment store should be located in the client application so one could argue for KRNS_MAINT_DOC_ATT_T to live in the client DB. Still, see discussion on KRNS_ATT_T below.
It is also interesting to note that KRNS_MAINT_DOC_T could be eliminated if the XML was stored in the Document's XML content.
Adhoc Recipients - KRNS_ADHOC_RTE_ACTN_RECIP_T
I believe this is just a temporary table for storing adhoc recipients prior to routing of the document? If so then this table could be either client-side or server-side.
Lookups - KRNS_LOOKUP_RSLT_T, KRNS_LOOKUP_SEL_T
These tables are related to storing lookup results and selections. These can remain client-side.
Session Documents - KRNS_SESN_DOC_T
This table is for serializing documents that use http session. This can remain client-side.
Pessimistic Locks - KRNS_PESSIMISTIC_LOCK_T
This could live server or client side. This should probably be handled the same way as KRNS_MAINT_LOCK_T since they seem to be performing similar functions (unless I'm mistaken?)
Notes and Attachments - KRNS_ATT_T, KRNS_NTE_T, KRNS_NTE_TYP_T
Since notes are attached to documents, these tables should live wherever the document table lives (server-side). However, attachments should probably be stored in the client application (although it may be possible to support server-side attachment storage in the future if desirable). Having the table server-side but the files client-side might be confusing.
Namespace and Parameters - KRNS_NMSPC_T, KRNS_PARM_DTL_TYP_T, KRNS_PARM_T, KRNS_PARM_TYP_T
The namespace table stores namespaces while the parameter tables store system parameters. These can be moved server-side, however some refactoring may need to be done to deal with "global" system parameters which should really be configurable on a per-application basis.
Tables which can move server-side
Tables which should remain client-side
Tables which can be dropped