Skip to content
  • Categories
  • Recent
  • Tags
  • Popular
  • World
  • Users
  • Groups
Skins
  • Light
  • Cerulean
  • Cosmo
  • Flatly
  • Journal
  • Litera
  • Lumen
  • Lux
  • Materia
  • Minty
  • Morph
  • Pulse
  • Sandstone
  • Simplex
  • Sketchy
  • Spacelab
  • United
  • Yeti
  • Zephyr
  • Dark
  • Cyborg
  • Darkly
  • Quartz
  • Slate
  • Solar
  • Superhero
  • Vapor

  • Default (No Skin)
  • No Skin
Collapse
Code Project
CODE PROJECT For Those Who Code
  • Home
  • Articles
  • FAQ
Community
  1. Home
  2. Database & SysAdmin
  3. Database
  4. Adding custom attributes to tables

Adding custom attributes to tables

Scheduled Pinned Locked Moved Database
databasetutorialquestion
3 Posts 3 Posters 1 Views 1 Watching
  • Oldest to Newest
  • Newest to Oldest
  • Most Votes
Reply
  • Reply as topic
Log in to reply
This topic has been deleted. Only users with topic management privileges can see it.
  • B Offline
    B Offline
    Brady Kelly
    wrote on last edited by
    #1

    It came up again today how to handle allowing users to add custom fields to the standard entity schemas delivered in your product's database. I favour actually providing a function that gives the user limited DDL functions, so they can actually add a new, custom field to a table. Another approach is to have a separate table for custom fields, e.g. Customers, and CustomersEx, where only CustomersEx can change, but here updates become trickier than normal. The last and most badass option that we discussed was providing a EAV table, where rows are entity name, field name, field value. Which approach is best?

    I M 2 Replies Last reply
    0
    • B Brady Kelly

      It came up again today how to handle allowing users to add custom fields to the standard entity schemas delivered in your product's database. I favour actually providing a function that gives the user limited DDL functions, so they can actually add a new, custom field to a table. Another approach is to have a separate table for custom fields, e.g. Customers, and CustomersEx, where only CustomersEx can change, but here updates become trickier than normal. The last and most badass option that we discussed was providing a EAV table, where rows are entity name, field name, field value. Which approach is best?

      I Offline
      I Offline
      i j russell
      wrote on last edited by
      #2

      EAVs look like a good idea but the practicalities of use (no datatyping, hard to query etc) mean that they should be avoided at all costs. I have only ever seen this problem handled reasonably well once. They created an Entity table and an attributes table for meta data. They then generated the system and custom tables for each entity from the meta data. They then generated views for querying and stored procedures for insert, update and delete. Views and SPs were regenerated as needed when custom attributes were added or removed. The other reason for having custom tables for each entity is that there is a limit of 8k on the total row size in Sql Server (at least prior to 2008).

      1 Reply Last reply
      0
      • B Brady Kelly

        It came up again today how to handle allowing users to add custom fields to the standard entity schemas delivered in your product's database. I favour actually providing a function that gives the user limited DDL functions, so they can actually add a new, custom field to a table. Another approach is to have a separate table for custom fields, e.g. Customers, and CustomersEx, where only CustomersEx can change, but here updates become trickier than normal. The last and most badass option that we discussed was providing a EAV table, where rows are entity name, field name, field value. Which approach is best?

        M Offline
        M Offline
        Mycroft Holmes
        wrote on last edited by
        #3

        We are currently using the EAV (what is that by the way) method with an attribute table with AttributeType and AttributeValue. Always varchar of course so yes data typing is an issue. It has allowed us to create a dynamic, extensible solution but there is a definite cost, some of the queries are just horrendous. If I was going to go down the path RJ suggested I would have a customer table with fixed columns and a CustomerEx where the user can add custom columns and the system will rewrite the DDL. I would disallow any custom column from being in the core processing, IE reference only. I'm not sure if this is different from RJs proposal. [edit] IJ not RJ, sorry mate [/edit]

        Never underestimate the power of human stupidity RAH

        1 Reply Last reply
        0
        Reply
        • Reply as topic
        Log in to reply
        • Oldest to Newest
        • Newest to Oldest
        • Most Votes


        • Login

        • Don't have an account? Register

        • Login or register to search.
        • First post
          Last post
        0
        • Categories
        • Recent
        • Tags
        • Popular
        • World
        • Users
        • Groups