<FromGitter>
<damianham> Hey guys a question for you all. I am building out 3 plugins at the moment for Amber as part of developing the plugin architecture. I am actually starting with these example plugins (which I need for my project) and I will implement the plugin CLI later. At this stage I am certain it is going to be generator based and similar to recipes. Anyway while developing the plugins I am adding lots of fields to the User
<FromGitter>
... record as each plugin needs to keep track of data associated with a User. I don't suppose this is too much of a problem in that if you add a plugin to a project it means you want to use it's features and so will accept many fields being added to the *users* database table. I had the thought this morning that it mi ... [https://gitter.im/amberframework/amber?at=5e9be6954711086205421e49]
_whitelogger has joined #amber
<FromGitter>
<sam0x17> as someone who helps companies fix / speed up aging rails apps, always go with the fewer tables solution when given a choice
feepbot has quit [Ping timeout: 250 seconds]
feepbot has joined #amber
<FromGitter>
<drujensen> It depends on the context of the data. If the data needs to be searchable, it will need to be indexable. It it’s unstructured data or dynamic in nature, json is an option. If it’s structured and you know the name and type, it probably should be a column. If it’s temporary like session data, a caching service is best.