Home/ Questions/Q 7895171
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-06-03T07:34:41+00:00

I’m going to be creating competitions on the current site I’m working on. Each

  • 0

I’m going to be creating competitions on the current site I’m working on. Each competition is not going to be the same and may have a varying number of input fields that a user must enter to be part of the competition eg.

Competition 1 might just require a firstname

Competition 2 might require a firstname, lastname and email address.

I will also be building a tool to observe these entries so that I can look at each individual entry.

My question is what is the best way to store an arbitrary number of fields? I was thinking of two options, one being to write each entry to a CSV file containing all the entries of the competition, the other being to have a db table with a varchar field in the database that just stores an entire entry as text. Both of these methods seem messy, is there any common practice for this sort of task?

I could in theory create a db table with a column for every possible field, but it won’t work when the competition has specific requirements such as “Tell us in 100 words why…” or “Enter your 5 favourite things that..”

ANSWERED:

I have decided to use the method described below where there are multiple generic columns that can be utilized for different purposes per competition.

Initially I was going to use EAV, and I still think it might be slightly more appropriate for this specific scenario. But it is generally recommended against because of it’s poor scalability and complicated querying, and I wouldn’t want to get into a habit of using it. Both answers worked absolutely fine in my tests.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    I think you are right to be cautious about EAV as it will make your code a bit more complex, and it will be a bit more difficult to do ad-hoc queries against the table.

    I’ve seen many enterprise apps simply adopt something like the following schema – 

    t_Comp_Data
-----------    
CompId  
Name  
Surname  
Email 
Field1 
Field2 
Field3 
... 
Fieldn

    In this instance, the generic fields (Field1 etc) mean different things for the different competitions. For ease of querying, you might create a different view for each competition, with the proper field names aliased in.

    • 0