Data Model of BPM applications

SQLServerCentral is supported by Red Gate Software Ltd.

Popular Topics

Home

Members

Calendar

Who's On

Home » SQL Server 7,2000 » Strategies » Data Model of BPM applications

Data Model of BPM applications

Rate Topic

Display Mode

Topic Options

Author

Message

adeel alvi

Posted Saturday, April 11, 2009 1:15 AM

Forum Newbie

Group: General Forum Members
Last Login: Thursday, April 23, 2009 11:18 PM
Points: 2, Visits: 17

Hi guys , we have created a simple asp.net/sqlserver 2000 based Buisneess Process Management tool in which we have a feature that user can create simple one column form and attached to the process and define rules and path.

We save the dynaimcally created forms controls values in EAV design tables but as the transactions is increasing we are have the performance issue on reporting on that custom forms value , my question is whats the alternative to this problem in which main req of the BPM solution is that user will create forms dynamically ,and what do u guys thing the implementation of big vendors of BPM like Skelta or Ultmus manages this problem. do u thing xml can save me ?? if yes then how or how u guys will design the model of BPM applications

Post #695133

Florian Reischl

Posted Saturday, April 11, 2009 3:17 AM

SSCrazy

Group: General Forum Members
Last Login: Sunday, November 04, 2012 12:23 PM
Points: 2,087, Visits: 3,932

Hi

An EAV database structure is by design a performance issue.

Maybe you can design a hybrid solution. You create tables for all (or most) possible objects which have to be represented by your database with most possible fields. So if you have "Order" objects there some fields which would be needed in most cases like OrderDate, ConfirmationDate, Reference, CustomerId, ... there also some main object types which are needed in most cases like "Customer", "Address", "Contact", ... . In addition you should add some generic fields to your tables as placeholder for other fields like "Reference1" to "Reference10", "OtherDate1" to "OtherDateN", "OtherText1" to "OtherTextN". For any additional fields which are not covered by your main structure use the EAV concept.

Another approach, but hard do handle, could be a dynamic database. You have a describing table which holds all the meta information and your database will be created automatically. So if the user defines a "Order" object create a new table "DYN_Order1" and hold this information in your meta information table. Same for the fields. Always add sequence numbers to all fields to ensure that two users define objects with same name but different meanings.

Hope this helps!

Flo

The more I learn, the more I know what I do not know
Blog: Things about Software Architecture, .NET development and T-SQL

How to Post Data/Code to get the best Help How to Post Performance Problems

Post #695144

adeel alvi

Posted Saturday, April 11, 2009 5:26 AM

Forum Newbie

Group: General Forum Members
Last Login: Thursday, April 23, 2009 11:18 PM
Points: 2, Visits: 17

Thankx for the reply

Main Problem is that any Business Process Management is build on this main requirement that u dont know any thing about the forms that will be created , u just have to provide tools to busineess users in which they can create their forms and process steps.

for e.g user can create expense claims process in which he has to create expense claim form dynamically.

you dont know how many and of which type of forms that will be created , we are handling the web form desiger part but saving the values in EAV tables , so should i use saparate xml for each forms.??

Post #695159

Florian Reischl

Posted Saturday, April 11, 2009 7:00 AM

SSCrazy

Group: General Forum Members
Last Login: Sunday, November 04, 2012 12:23 PM
Points: 2,087, Visits: 3,932

Hi

Sure you don't know all possible objects (forms) to be created but maybe there are many common business processes as "Claim", "Order", "OrderPosition", "Shipment", "Physical Unit", "Contract", "Partner", "Customer", "Contact", "Customer Group", "Location", "Address". You could define some (as much as possible Wink

) common objects with their common fields and some additional fields in different types. The rest of the fields within the EAV typed tables. Categorical avoid one description table with a huge text field to store any data type. Use typed attribute tables like EAV_DateTime, EAV_References (indexed varchar field), EAV_AnyText (non indexed), EAV_HugeText (varchar(max)), EAV_NaturalNuber, EAV_FloatingNumber, EAV_Blob, ... .

The approach to store your forms as XML is a good approach in my opinion! Maybe use two XML columns. One for the form designer XML and one for the data mapping. So one contains the graph XML which defines the form and one which maps the fields of the form to one or more tables (objects) within your database.

Greets
Flo

Post #695173

« Prev Topic | Next Topic »

Permissions