If you want to get some attention for your endeavor,  you'll want to be able to say 'Used by Google, or Amazon,  or whomever.

To get to that level,  you will have to scale! 

Put scalability first!

Do some benchmarking using both approaches.

Young developers often over engineer just because it's more interesting,  loosing site of what really matters some times.   You can always invest that eagerness to engineer cool software in the tools used by the developer that is developing with the Gem.  But in the big picture,  if you are successful,  99.9% of the usage of your Gem will be in a production environment,  where scalability is very important.

Thanks for your answer, at least i can tell that we are moving in the right direction

For speed, I'd do the first approach,  having a blank unused integer, date time, boolean, etc. is the trade off over not having to parse out of the blob for every data value.

Im building a gem to add Dynamic Forms functionality to any Rails App. I have most of the specification working.

Im having some philosophical issues about the structure in where to store the answers to each form. The idea is that a "question" could have a reply in one specific type (string, text, boolea, etc) including lists of values (of the same type).

Im wondering how should i create the model for the replies. Should i make a column for each type of reply or should i use one blob column, using the question descriptor to transform the value back to it specific type?

Sorry for my bad english, its not my native language.