• I have n number of geometric shapes like triangle, square, rectangle, circle, cone, pyramid, cylinder etc.

    Hi

    I hate to say that but maybe the EAV design may be an option for requirements. You may consider if you create more than one description table as we call it in our company. So there could be one to store measures (as steveb already described), one to store natural numbers, one for references - if you need - one for any text information (not indexed) and so on.

    I'm just getting rid of this design by redeveloping the whole system. EAV databases have the benefit that they are flexible to hold any information but they have also many issues:

    * You may ran into bad performance issues because you have always to join many and many of tables

    * Getting analytic information from this database is almost impossible... Sure it is possible, but also the performance is quiet bad. The only way we have to realize this is using NOLOCK hints what causes incorrect data sometimes...

    * Another big problem is that you never know if your objects are valid. Due to the fact that your objects are not stored in their own tables you don't know if the stored data for each object are correct. E.g. a square may have a radius attribute or your circle may have an angle. You don't see from outside.

    * Next problem, are your objects still correct. Maybe you have some more complex objects and you add a new property to them or just conclude that your pyramid gets a new property for color which it did not have before. The existing data still don't have the property so you have to INSERT the new property with any default value into the description tables for all existing objects or the front end has to handle the possibility (forever) that the required fields are not available.

    You see the EAV design is very flexible, but this is the main problem of this structure.

    Sorry for my subjectivity but I fought about fife years against this database design... But this is the reason why I know the issues.

    If your object types are finite you should always use own tables for objects! The EAV database design is very simple to start with but you should consider the problems.

    Greets

    Flo