Expand my Community achievements bar.

SOLVED

Is there a limit on number of fields that can be added to a Custom Resource in ACS?

Avatar

Level 4

Is there a limit on number of fields that can be added to a Custom Resource in ACS?

1 Accepted Solution

Avatar

Correct answer by
Employee

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

View solution in original post

2 Replies

Avatar

Correct answer by
Employee

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

Avatar

Level 4

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?