Performance Implications of Smart Object Database design

  • 15 December 2009
  • 1 reply
  • 0 views

Badge +1

We are planning on using the SQL Service to access smart objects in a custom designed sql server database.   My first question is if it is even possible to map smart objects to this sort of database design, and second, if it is possible, than what are the performance and other implications.


The design we are thinking of using is a data driven design where there are 3 basic tables.


Table1 has two columns. TableName and TableID.


Table 2 has two columns ColumnName and ColumnID.


Table 3 has two columns ColumnValue and ColumnValudID.


There would also be "JOIN" tables to link the Table1-Table2 and Table 2-Table3.



I believe the reason they are considering this design is because the flexibility it would give to the data model. Can K2 smart objects be mapped to this sort of structure? If so, what are some good arguing points to avoid using this structure?



Thanks!


1 reply

Badge +9

There are custom SQL brokers for Stored Procs, Views and Tables.  So could you map the SmartObject to a view or Stored Proc call.  The official support version for the Dynamic SQL broker will be in the upcoming 4.5 release in Q1 2010.  There's also a bunch of SO performance improvements including the ability to do direct queries to the custom SQL source (bypassing the K2 server as the intermediate broker).

Reply