3

I had a good debate with friends at work to decide where we should keep user profile and why?

As the discussion goes on we had these key points below which I feel our competency is up to only a certain extend. So I thought I would ask for your opinion here.

Background: We setup a Sitecore instance to serve websites for Europe continent with multiple domain name, 60% common layouts, different content, different languages. We know there are common data fields among the sites. There should be around 500K users in the core database when the system rolled out.

Custom data in new table

  • Small data I/O foot print
  • Easier to code for CRUD data
  • Easier to write export to Excel code by put DataTable object to the existing function. The outstanding data fields get normalize before save to DB.

But

  • I don't know when was the last time there was a problem in our SQL servers. I believe our database server is quite strong.

All in Sitecore

  • Fully engaged with Sitecore
  • All fields can be found in Sitecore admin UI
  • The data might be usable in xDB

But

  • The code can be complicated
  • it is really bad question, because eveyrhing depends on what kind of data you are trying to store and how do you plan to utilize it in future – Andrey Bobrov Jan 24 '17 at 14:55
6

If you have a lot of custom user profile data, especially if you have 500k+ users, then your best bet is probably going to be to create a custom SQL database and store your user data, with a key for the each user's record(s) in the database stored in a custom Sitecore user profile field (assuming you are using Sitecore membership, which I believe your question implies)

This is especially true when you store complex objects, since all properties must be serializable and you really don't want to slow your UserProvider and user access logic down. By the same token, if you add a large amount of data to your user profiles, especially when you have a large number of users (like you're expecting), you will likely experience a noticeable decrease in performance.

Given the above, we can conclude from an extensibility and performance standpoint that a custom database is the right decision, but how about from a GUI perspective? What if your authors want to be able to view the data for each user in Sitecore? The reality is that, given the number of users that you are describing, you should probably create a custom interface anyway for viewing user data. Sitecore's User Manager is meant more for managing securities, roles, etc. than viewing user data. Performance is not optimized and searching in this tool is neither robust nor extensible. If viewing user data is a requirement for you, then this question may come down to cost and budget for your project.

| improve this answer | |
3

Typically I like to keep users in Sitecore unless there is a third party membership provider, active directory, OAuth, or SSO solution. If you do not need to use an external membership provider, then use Sitecore.

Also, with external users, you have to make the decision of using a virtual user to authenticate the user or create a Custom Membership Provider, which may not be worth it.

Since you know there will be 500K users when the system rolls out with multiple domains, I would recommend using Sitecore.

| improve this answer | |
  • 1
    I don't believe the question was Sitecore membership vs. third-party/custom provider, but rather whether to keep custom Sitecore profile data in Sitecore or in an external database. – Zachary Kniebel Jan 24 '17 at 16:08
  • If we keep the users in Sitecore, we would want to keep the profile information in Sitecore, IMHO. If the users are not in Sitecore, we would want to create the profile when we create the virtual user. – C Sigmon Jan 24 '17 at 16:12
  • I don't think we have enough information about the data that is being stored in the profiles to say, at this point, that Sitecore would be more performant. If a large amount of custom data is being stored then Sitecore performance will degrade quickly if you try to store that data directly on the user profiles, especially if any of that data includes complex objects. Sitecore is not optimized for storing medium-to-large amounts of custom user data. Typically, the most extensible and performant solutions, in this case, will make use of an external database for housing the custom user data. – Zachary Kniebel Jan 24 '17 at 16:16
  • Thank you both for opinion. I really appreciate. What if I add the fact that we do have many existing databases holding user information for the existing ASP.NET system. Obviously we would want to have only 1 table at the end by migrate those existing data into this 1 table. What would then be more prominent option. – Atit J Jan 24 '17 at 16:48
  • 1
    I must agree with @ZacharyKniebel. You have several options available to you, most likely with a complex system. Without more information about the data structures, it would be difficult to say. From a username, password and roles - that can go into Sitecore. Profile properties (this also depends on how you define what a "profile" is) - you have the options we have both given opinions on. – C Sigmon Jan 24 '17 at 20:10

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.