Jimmy as I think about this, I really don't see adding dynamic columns as being of any help at all. I did a bit of a mental exercise and the following became glaringly obvious:



- unless the users are developers/dba, managing dynamic adds to a database is going to be hard. You have to consider indexing, valid names, defaults, constraints and any server specific issues, such as row size limit on SQL Server 2000 (8060 bytes) or the related row size performance issues with SQL server 2005. I just see all sort of issues and no solutions for trouble the users could get themselves into. (Image the users adding varchar(8000) comments fields to the 10 fields in a table...booom!)



- Allowing user to change the database will make updating the database on your end even harder. I.e. if you need to add a column to a table for some base functionality, but the user already maxed out the table width, your screwed. You won't be able to use the DDT as it would remove any user customizations. I'm sure there are ways around all of this...but wow, that's a lot of work.



- Assuming you manage the dynamic changes (and I mean really dynamic, were you don't know what they might do), then you would need to make your BOs dynamic enough to get to this data. You'd probably have to use regular .NET binding, as new custom properties wouldn't have a bindable property associated with it.



- As Trent mentioned, managing a UI for this will be...er...fun. You'll have to track all those custom columns, the display names, control types, if they are a list, the list source and some how get that on the screen so the user can see it and use it...wow.



The two examples you mentioned are fairly contained though and Ivan's suggestions seem like they'd work better anyway.

1. Dynamic business rules. It seems to me to be more feasible to build a dynamic rule engine than change the db. The BOs are all wired to process any business logic already, you'd just use a dynamic engine for that process. Imagine allowing the users to specify, for example, what fields are required. You could easily just update the RequiredFields property of the BO at run time, based on a set of fields the user has configured and you stored in a db table (which will have its own BO, with a method to get the fields for that table...that you call from the check business rules event each bo, or better in a base business layer that just passed in the table name).



2. Adding comment fields. I see two ways to do this. The easier way is what Ivan suggested, of simply allowing a set number of fields to have optional comments. They simply turn them on off, perhaps set a name. Store this in a configuration table, your good. You could also have a common "comments" table, that tracked the comment, the table the comment is associated with and the PK for the row. This allows for more flexibility, but makes development more complex and can have some performance issues too.



In any case, I'm just throwing out some thoughts and hope they stimulate your development process a bit!