I don't know of anything to handle what your asking, although there must be an off the shelf solution for such a task.
If your considering Roll Your Own, I would recommend taking a look at CouchDB as it has many similarities with Lotus Notes and features that have greatly enhanced the whole experience.
what kind of workflow management software other people are using to handle something like this?
At work we have people using a system called Gotcha, I just googled it and can't find it (!) and I'm not at work so can't easily get more info.
The main LOB workflow is provided by an old legacy Main-Frame system (don't go there!).
I was involved in building a major workflow system in .Net a few years ago - we used K2 Workflow (current product name is 'BlackPearl') as the core workflow system. K2 is really powerful and is well suited to a .Net / Microsoft environment,and (in theory at least) it will integrate with SharePoint.
My current planning path is to have completely dynamic forms ... what major pitfalls would you encounter with the above design?
Not so much a pitfall - but managing the data will be a challenge. Having Dynamic Forms is probably going to mean one of several things in terms of the physical design of the database:
The table structure reflects the forms structure; adding a field to the form means adding a column to the DB; and adding a new form means adding a new table to the DB. This is probably ok if the forms aren't going to change much - the more they change the harder it will be to maintain.
Semi generic table structure: some common columns and then some generic columns like FormField1, FormField2, etc. This would be more manageable, and you could realistically automate this so that users could self provision fields. The downside is that you'd be working to a constrained number of columns / table schema. Changes to this would be very challenging.
In both of the cases above the physical data structure closely matches the logical one. One of the key problems with this is that for your app to auto-magically make extra columns requires it to have greater security rights on the system - so you won't want to do that on anything that was public internet facing. Alternatively:
Have a single 'narrow' table where the field values are stored more like key-value pairs.
This approach would support a solution that let users self provision fields and forms, and there's no limit. The downside is that reporting is much more difficult and will be slower; you can get around that by migrating the 'volatile' transactional data to a database designed for reporting.
A term often used for this sort of database design is 'NoSql Database', CouchDB (suggested by @WeNeedAnswers) is an example of this.
A related pitfall (if you allow users to self provision forms/fields) is managing the data and it's quality; you don't want people using different terms for the same thing, or the same term meaning multiple things.
I've been looking around and haven't found anything that looks entirely promising, and so I have been contemplating how to homeroll one should the need arise
Look harder. No offense!
From an architectural perspective my first question would be 'do we really need to build'? Building software is non-trivial, specifically one that you're going to maintain overtime.
It's not clear what your functional requirements or existing technology standards are, but both will influence which options in the market are best for you. Then of course you have the support aspects, licensing, etc.
I'd say you need to draw up a list of relevant evaluation criteria and evaluate any likely candidate COTS solutions you can find (Open Source might be an option too), as well as a custom build; you need to evaluate against a firm set of criteria and work out the TCO (Total Cost of Ownership). Yes TCO might sound like marketing hype / business buzzword - but at the end of the day it's something you simply have to do (unless you're a millionaire and money is no issue).
Tools that do the kind of thing you're after are pretty common - hence my initial (and admittedly somewhat flippant) response.
发布评论
评论（3）
我不知道有什么可以处理你的要求，尽管必须有一个现成的解决方案来完成这样的任务。
如果您考虑 Roll Your Own，我建议您看一下 CouchDB，因为它与 Lotus Notes 有许多相似之处，并且功能极大地增强了整体体验。
http://couchdb.apache.org
http://en.wikipedia.org/wiki/CouchDB
您需要快速熟悉它，但由于您熟悉 Lotus Notes，所以应该很容易学习曲线。
希望这有帮助。
I don't know of anything to handle what your asking, although there must be an off the shelf solution for such a task.
If your considering Roll Your Own, I would recommend taking a look at CouchDB as it has many similarities with Lotus Notes and features that have greatly enhanced the whole experience.
http://couchdb.apache.org
http://en.wikipedia.org/wiki/CouchDB
You would need to get up to speed with it, but since you are familiar with Lotus notes, should be an easy learning curve.
Hope this helps.
与其说是一个陷阱，不如说管理数据将是一个挑战。就数据库的物理设计而言，拥有动态表单可能意味着以下几件事之一：
FormField1、FormField2等。这将更易于管理，并且您可以实际上将其自动化，以便用户可以自我提供字段。缺点是您将使用有限数量的列/表模式。对此进行改变将非常具有挑战性。在上述两种情况下，物理数据结构与逻辑数据结构紧密匹配。这样做的关键问题之一是，要让您的应用程序自动神奇地创建额外的列，需要它在系统上拥有更大的安全权限 - 因此您不会希望在面向公共互联网的任何内容上执行此操作。或者：
这种方法将支持允许用户自行配置字段和表单的解决方案，并且没有限制。缺点是报告更加困难并且速度会更慢；您可以通过将“易失性”事务数据迁移到专为报告而设计的数据库来解决这个问题。
此类数据库设计经常使用的术语是“NoSql 数据库”，CouchDB（由 @ 建议） WeNeedAnswers）就是一个例子。
一个相关的陷阱（如果您允许用户自行配置表单/字段）是管理数据及其质量；您不希望人们对同一件事使用不同的术语，或者同一术语表示多个事物。
Not so much a pitfall - but managing the data will be a challenge. Having Dynamic Forms is probably going to mean one of several things in terms of the physical design of the database:
FormField1,FormField2, etc. This would be more manageable, and you could realistically automate this so that users could self provision fields. The downside is that you'd be working to a constrained number of columns / table schema. Changes to this would be very challenging.In both of the cases above the physical data structure closely matches the logical one. One of the key problems with this is that for your app to auto-magically make extra columns requires it to have greater security rights on the system - so you won't want to do that on anything that was public internet facing. Alternatively:
This approach would support a solution that let users self provision fields and forms, and there's no limit. The downside is that reporting is much more difficult and will be slower; you can get around that by migrating the 'volatile' transactional data to a database designed for reporting.
A term often used for this sort of database design is 'NoSql Database', CouchDB (suggested by @WeNeedAnswers) is an example of this.
A related pitfall (if you allow users to self provision forms/fields) is managing the data and it's quality; you don't want people using different terms for the same thing, or the same term meaning multiple things.
更加努力地寻找。无意冒犯！
从建筑学的角度来看，我的第一个问题是“我们真的需要建造吗”？构建软件并非易事，特别是需要加班维护的软件。
目前尚不清楚您的功能要求或现有技术标准是什么，但这两者都会影响市场上最适合您的选择。当然，你还有支持方面、许可等。
我想说你需要制定一份相关评估标准列表，并评估你能找到的任何可能的候选 COTS 解决方案（开源也可能是一个选择）作为定制构建；您需要根据一套严格的标准进行评估并计算出 TCO（总拥有成本）。是的，TCO 可能听起来像是营销炒作/商业流行语 - 但归根结底，这是您必须要做的事情（除非您是百万富翁，而且钱不是问题）。
完成您所追求的那种事情的工具非常常见 - 因此我最初的反应（诚然有些轻率）。
Look harder. No offense!
From an architectural perspective my first question would be 'do we really need to build'? Building software is non-trivial, specifically one that you're going to maintain overtime.
It's not clear what your functional requirements or existing technology standards are, but both will influence which options in the market are best for you. Then of course you have the support aspects, licensing, etc.
I'd say you need to draw up a list of relevant evaluation criteria and evaluate any likely candidate COTS solutions you can find (Open Source might be an option too), as well as a custom build; you need to evaluate against a firm set of criteria and work out the TCO (Total Cost of Ownership). Yes TCO might sound like marketing hype / business buzzword - but at the end of the day it's something you simply have to do (unless you're a millionaire and money is no issue).
Tools that do the kind of thing you're after are pretty common - hence my initial (and admittedly somewhat flippant) response.