No, avoid DDS. it should not be used for any data set more than a few dozens items (I would say it should not be used at all)
If I recall correctly, then Profiles is just a table with a key-value format. i.e. you have ProfileId, PropertyName, PropertyValue. A simple table + EF should do. Unless if you have complex queries like getting profiles with this property has value = x, an index on ProfileId should be enough
Thank you!
So it is good practice (and possible) to add a table to the Optimizely database, even if the site is a DXP site?
To store the migrated EpiServer.Profiles?
yes, you can. just don't overuse it (for example store 10B rows in it), within reasonable size and usage, sure
I have made a migration functionality which, using EF, is fetching the EpiServerProfile data from the database. Then creating new tables and saving them. This seems to work fine 😄
Hi!
I'm working with migrating a CMS 11 site to CMS 12.
The site uses EpiserverProfile for subscription. The visitors can add a subscription to specific pages and sub pages, like news, articles and such. We use the profiles to save what pages the user wants to subscribe to. The visitors do not need to login.
But as EpiserverProfiles is gone in CMS 12, I have a bit of a problem.
After looking in the forums and asking in another thread, I understand that I need to migrate the data and use another way to store the subscription data. But I dont understand how.
The site is in the DXP, and as I understand it, it is not possible, or atleast we shouldn't add tables or such to the database.
I was thinking of using the DDS to store the subscription data. Is this a good way to do it?
How do I get the data out from where EpiserverProfiles is stored?
It seems like our solution in the CMS 11 should have been used by others, how did you migrate the subscription data?
As the site is a live site, and changes to the subscriptions is happening all the time, it is not a good solution to copy the database and migrate the data before going live. So I was thinking of creating a scheduled job that will be run once to, somehow, migrate the data from EpiserverProfiles to the new way to handle the subscriptions.
Any advice?
Best Regards
Niklas