• zonic
  • Ticketholder
  • Offline
  • Registered: 2012-03-30
  • Posts: 2

Topic: Dynamic forms gem development

HI!

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.

Last edited by zonic (2012-03-30 12:03:18)

  • From: Los Angeles CA
  • Registered: 2008-03-17
  • Posts: 1,701

Re: Dynamic forms gem development

What's more important,  speed or database size?

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.

Joe got a job, on the day shift, at the Utility Muffin Research Kitchen, arrogantly twisting the sterile canvas snout of a fully charged icing anointment utensil.
  • zonic
  • Ticketholder
  • Offline
  • Registered: 2012-03-30
  • Posts: 2

Re: Dynamic forms gem development

Im pretty fixed on the first approach, but some of the people in my team (we are stablishing a sofware developer foundation in our small city, to incentivize young developers) argue that the second approach keeps things simplier for the developer that uses the gem.

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

  • From: Los Angeles CA
  • Registered: 2008-03-17
  • Posts: 1,701

Re: Dynamic forms gem development

Here's what I'd say to the team.

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.

Joe got a job, on the day shift, at the Utility Muffin Research Kitchen, arrogantly twisting the sterile canvas snout of a fully charged icing anointment utensil.