Home/ Questions/Q 829899
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-15T03:57:18+00:00

My application has one table called ‘events’ and each event has approx 30 standard

  • 0

My application has one table called ‘events’ and each event has approx 30 standard fields, but also user defined fields that could be any name or type, in an ‘eventdata’ table. Users can define these event data tables, by specifying x number of fields (either text/double/datetime/boolean) and the names of these fields. This ‘eventdata’ (table) can be different for each ‘event’.

My current approach is to create a lookup table for the definitions. So if i need to query all ‘event’ and ‘eventdata’ per record, i do so in a M-D relaitionship using two queries (i.e. select * from events, then for each record in ‘events’, select * from ‘some table’).

Is there a better approach to doing this? I have implemented this so far, but most of my queries require two distinct calls to the DB – i cannot simply join my master ‘events’ table with different ‘eventdata’ tables for each record in in ‘events’.

I guess my main question is: can i join my master table with different detail tables for each record?

E.g. 

SELECT E.*, E.Tablename 
FROM events E 
LEFT JOIN 'E.tablename' T ON E._ID = T.ID

If not, is there a better way to design my database considering i have no idea on how many user defined fields there may be and what type they will be.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    There are four ways of handling this.

    1. Add several additional fields named “Custom1”, “Custom2”, “Custom3”, etc. These should have a datatype of varchar(?) or similiar

    2. Add a field to hold the unstructured data (like an XML column).

    3. Create a table of name /value pairs which are associated with some type of template. Let them manage the template. You’ll have to use pivot tables or similiar to get the data out.

    4. Use a database like MongoDB or another NoSql style product to store this.

    The above said, The first one has the advantage of being fast but limits the number of custom fields to the number you defined. Older main frame type applications work this way. SalesForce CRM used to.

    The second option means that each record can have it’s own custom fields. However, depending on your database there are definite challenges here. Tried this, don’t recommend it.

    The third one is generally harder to code for but allows for extreme flexibility. SalesForce and other applications have gone this route; including a couple I’m responsible for. The downside is that Microsoft apparently acquired a patent on doing things this way and is in the process of suing a few companies over it. Personally, I think that’s bullcrap; but whatever. Point is, use at your own risk.

    The fourth option is interesting. We’ve played with it a bit and the performance is great while coding is pretty darn simple. This might be your best bet for the unstructured data.

    • 0