Is there a limit on number of fields that can be added to a Custom Resource in ACS?
Solved! Go to Solution.
Hi Asish,
There is no limit theoretically. It completely depends on how many columns a table at Postgres can handle which I know is very large.
Question is what is your use case.
To have 200-250 fields in a resource doesn't sound valid if this is the number if fields you are trying to achieve.
The resources should adhere to database normalization and you should define resources to respect 3rd Normal form of RDBMS
Hope this helps.
Regards,
Vipul
Hi Asish,
There is no limit theoretically. It completely depends on how many columns a table at Postgres can handle which I know is very large.
Question is what is your use case.
To have 200-250 fields in a resource doesn't sound valid if this is the number if fields you are trying to achieve.
The resources should adhere to database normalization and you should define resources to respect 3rd Normal form of RDBMS
Hope this helps.
Regards,
Vipul
Hi Vipul,
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?
Views
Replies
Total Likes