Guys, I've seen a few posts almost touch on the subject but not one that answers my design issue. If there is one out there, my apologies. My application requires that the user can create new 'attributes' and their associated 'values' for certain predefined entities. This means that some entity attributes will be defined at design-time and many others at run-time by the end user. My question is how to best implement the dynamic entity attributes within the LLBLGen framework. My initial table design of the dynamic attributes is as follows. Also, I plan on using the extended Entity 3rd party templates to help with a hybrid of the Domain and Manager models.

Table: EntityProperty Columns: EntityPropertyID (PK), EntityName (Table Name), EntityKeyID (FK to many unlinked tables), EntityPropertyValueID(FK)

Table:EntityPropertyValue Columns: EntityPropertyValueID(PK), EntityPropertyGroupID(FK), Number, Text, Value, Date, Bit (Most common data types to store property value)

Table: EntityPropertyGroup (not really needed for discussion but it will help group Values for comboboxes, etc) Columns: EntityPropertyGroupID(PK), Name

Now, in the article below, Frans mentioned having multiple entities per table.  I think this is what I'm trying to achieve in a sense, although forgive me for not understanding his post at first glance.

http://www.llblgen.com/TinyForum/Messages.aspx?ThreadID=694

I assume I will have to override both the Create and Save and maintain the custom attributes myself. But before I dive into the code, I wanted to see what you guys thought.

Thanks

Jeff

Don't make this more complex than it already is : you want to store name-value pairs and at runtime these name-value pairs have a semantical meaning, which depends on the context the name-value pairs are used in.

Very often, these name-value pairs are used to store information which is solely used for viewing purposes, things which mean things for the human reading them.

If you want to store values which take part in logic, like ints and dates, it will become a mess really fast and it's unnecessary: if the logic is pre-written (and often that's the case), you know what values to expect, so you can define these in your database.

Point taken and thanks for your feedback. It appears that you must spend a significant amount of time writing in this forum, where do you find the time to code anymore?

I think you're correct in my attempt to make a solution for too many scenarios. At this point, I think I will make a name-value pair entity as a 1-m relationship to the entities that I think need to be extended. Although I can bet a client will want to extend an entity that was not designed to be. That’s what I was trying to prevent.

Anyway, in order to give this post a tiny bit of dignity, I'll leave it at that until I can more clearly describe the scope of my issue. I’ll follow at a later date with what I end up using.

Thanks for your thoughts,

Jeff