Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
foxprorawks
Starting Member
17 Posts |
 Posted - 2011-01-26 : 09:37:26
|
| We are researching how best to provide our customers with user-customisable forms written in ASP.NET.Rather than allowing the users to add new fields to a table, we are trying to represent each field as a row in a table. This gets around the problem of elevated privileges being required to modify the structure.However, it presents us with the problem of querying and reporting on the data, particularly if we wish to provide statistics (e.g. lost time by department, trend analysis etc.).Has anyone tried anything like this? |
|
|
denis_the_thief
Aged Yak Warrior
596 Posts |
Posted - 2011-01-26 : 14:45:13
|
| We did. I still can't say wether it was good or bad. Here were some of the pitfalls:- no system can be completely customizable - so somebody has to be able to define the limits of the customizability - to keep evyone on the same page- your system will be more complex = harder to change = higher maintenance costs - hopefully this will be offset by your ability to make a customizable system???- customizable systems are usually with the intent that anyone can customize the system but in reality it won't be that easy and the people doing the customizing must be smart- when there is a problem, whose at fault - the Developement team for creating the system or the customer who customized it?Like you said it makes it harder to report (and slower). So we made all these views to combine tables/columns into flat tables so we could easily do the reporting like we always would have. Then it was like why did we go through all that just to emulate the data the way we could have in the first place if we did it old school. |
 |
|
|
|
|
|
User Customisable Data Structure