Thanks for your response and questions! We are definitely not looking at having so many fields for now. It will be 40-50 fields. We would like to go with 3NF data model but there are some technical(performance) challenges from application team (where our landing page is hosted) to store in realtime the multiple rows per email address(profile) in custom resource table directly using adobe io apis. The landing page is capturing multiple(30 as of now) customer preference per each customer. Right now we have 3 options on the table 1) Normalized tables storing multiple rows per each customer in custom resource table. Cons: Performance issue from application server doing multiple api calls for multiple inserts 2) Concatenate the customer preference values in the table store it as a string one row per each customer. Cons: Table is not normalized. DB query performance issue querying the field using like operator which will be full table scan. 3) Stores the Data in flat table each preference translates to one column in the table with values Y or N. one row per each customer Cons- Denormalized. so many columns to manage. Pros- addresses application performance issue. No DB performance issue as such. We thought going with option 3 as it keeps balance on the performance issues on both DB and App server. But compromising with normalized approach. Hope this makes sense to you?