locked
Which solution should I consider? RRS feed

  • Question

  • problem:

    We have some forms that their fields may change in the future.these changes may need every 2 year.(not surely).As with this the database will change too.I came to two solution:

    1.making every form staticly with their related tables in database.and if any changes occur in any year i will change the forms and their related tables.maybe it will need me to add some more columns in their tables.The benefits are UI is more appreciate and neat, and ofcourse very user friendly. and easy to develop.

    2.making every form dynamicly using form generator technics.Benefits are if any changes occur there is no need to change code but making the forms are absolutely difficult and also the UI will be so ugly and off course not user friendly.

    What are your suggestion?If any other solution please feed us?

    Thanks

     

     


    Brainstorm your Brain and find solution,if no result stuck to Brainstormer.
    Wednesday, January 26, 2011 3:02 PM

Answers

  • Hi,

    The simpiest option that delivers the most value quickest should be picked.

    I'd go with option 1 as well for the same reasons Andy mentioned.

    You say the database MAY need to change in 2 years so that's an unknown, never factor into software features that MAY happen in the future.

    More work and more code complexity for something that might not happen; or might happen but not in a way that you expected and built.

     


    …we each have more potential than we might ever presume to guess. (Blog: http://dsmyth.blogspot.com/)
    • Marked as answer by simosi Saturday, January 29, 2011 3:18 PM
    Thursday, January 27, 2011 12:57 PM
  • Almost every system will have such changes in similar timeframes.

    The cost of making your forms and database dynamic is such that it's rarely worth the effort.  Making people think about changing schemas is a plus rather than a minus.  If you make it easy then the chances are that things won't get thought through and your data will end up being a mess.  That's bad.

     

    So I'd strongly recommend option 1).

    • Marked as answer by simosi Saturday, January 29, 2011 3:18 PM
    Thursday, January 27, 2011 10:50 AM

All replies

  • What Database you are planning to use?

    What is the volume of schema change you are thinking off?

     

    If you are using SQL server 2005, you can consider of creating a column of type XML and store UI data inform of Node inside XML.

    in future if there is a need of new column you can add a node in above column so that you can avoid of changing DB schema

     


    Lingaraj Mishra
    Wednesday, January 26, 2011 8:15 PM
  • Hi Lingaraj ,

    I have a same problem so could you please address some sample about that

    thank you

    Thursday, January 27, 2011 5:11 AM
  • Almost every system will have such changes in similar timeframes.

    The cost of making your forms and database dynamic is such that it's rarely worth the effort.  Making people think about changing schemas is a plus rather than a minus.  If you make it easy then the chances are that things won't get thought through and your data will end up being a mess.  That's bad.

     

    So I'd strongly recommend option 1).

    • Marked as answer by simosi Saturday, January 29, 2011 3:18 PM
    Thursday, January 27, 2011 10:50 AM
  • Hi,

    The simpiest option that delivers the most value quickest should be picked.

    I'd go with option 1 as well for the same reasons Andy mentioned.

    You say the database MAY need to change in 2 years so that's an unknown, never factor into software features that MAY happen in the future.

    More work and more code complexity for something that might not happen; or might happen but not in a way that you expected and built.

     


    …we each have more potential than we might ever presume to guess. (Blog: http://dsmyth.blogspot.com/)
    • Marked as answer by simosi Saturday, January 29, 2011 3:18 PM
    Thursday, January 27, 2011 12:57 PM