locked
Best to handle extra properties defined at runtime? RRS feed

  • Question

  • I need to allow my customers to add extra properties to our system at runtime. What is the best way to handle this scenario? Possible solutions seem to include...

    1, Have some extra columns in the database that map to properties on the Entity and only use them when the customer needs extra properties.

    For example, a Person entity would have ExtraString1, ExtraString2 etc and at runtime they could decide to start using them or not. Obviously it has the limitation that you can only define a fixed number of extra fields and once that limit is reached the user is stuck. Also is wasteful for customers that don't need many or any of the extra fields.

    2, Have a single string property and backing database column and the client has to persist in and out the comma separated actual values.

    Looks like alot of hard work for the client as all the extra fields must be persisted into a string and back again later on. Also make it hard to query against that extra catch-all column as it is containing multiple values.

    3, Have an extra table with a 1-to-many relationship for storing extra values.

    Seem to offer the correct level of expandability and allows queryies to work against the extra values. But loading an entity could be slow when every entity needs to be joined to pull in the collection of extra values.

    Any other ideas? Best practice is what?

    Wednesday, May 30, 2012 2:30 AM

Answers

  • Hi Philip Wright,

    Welcome to MSDN Forum.

    I agree with @RohitArora. For the first solution, we have no idea how many properties may be added in the future, so if the extra columns are not enough, it is too terrible, we have to create the database again. For the second solution, splitting in saving and loading period seems not better than join tables, it certainly will make the lower performance too. Compared with the former two, the third solution obviously more flexible. Though join tables will affect the performance, but it is not necessarily worse than splitting columns.

    Best Regards


    Allen Li [MSFT]
    MSDN Community Support | Feedback to us

    • Marked as answer by Philip Wright Wednesday, June 6, 2012 2:28 AM
    Sunday, June 3, 2012 2:06 PM

All replies

  • I would recommend to go with last solution. That would be much flexible and easy to maintain.

    Mark Answered, if it solves your question
    Rohit Arora

    Wednesday, May 30, 2012 10:40 AM
  • Hi Philip Wright,

    Welcome to MSDN Forum.

    I agree with @RohitArora. For the first solution, we have no idea how many properties may be added in the future, so if the extra columns are not enough, it is too terrible, we have to create the database again. For the second solution, splitting in saving and loading period seems not better than join tables, it certainly will make the lower performance too. Compared with the former two, the third solution obviously more flexible. Though join tables will affect the performance, but it is not necessarily worse than splitting columns.

    Best Regards


    Allen Li [MSFT]
    MSDN Community Support | Feedback to us

    • Marked as answer by Philip Wright Wednesday, June 6, 2012 2:28 AM
    Sunday, June 3, 2012 2:06 PM