I need to associate several dozens of pieces of data with each user at create time. Should I extend the existing meteor.users document layout by adding a new field, by putting the data in the profile field or create a new collection indexed by _id? I need the data on both the client and the server at different times. None of the data is especially large, mostly things like 2nd email address, time of last login, etc.
I’ve searched through the forums for an answer but the related questions all seem to deal with how to write data to the fields at create time rather than where to put the fields. I’m more interested if there is a suggested “best practice” on how to layout additional user data.
Thanks, good point, I’m new to meteor and Mongo so I’m still feeling my way around schema layouts. I know how I would layout the data in Oracle or Cassandra but Mongo’s structure is a bit different from either of those.
That would potentially argue for splitting the data between profile and one or more other collections (the user should be able to modify their 2nd email address but definitely not their time of last login or password expiration date!)
You can add whatever fields to Meteor.users and publish them like you do with any other collection. Avoid using the profile field, as it will probably be deprecated in the near future.
I think MDG is going toward considering Meteor.users as a standard collection without any particular behavior (which is good IMO).
I agree with @Steve.
In my case I created a separate collection – Profiles – and I put every user profile data there. another reason because I prefer this approach is one problem I got few months ago discussed in this post
It was probably my fault, but now after months I’m happy with my profiles collection.
Note that in with some packages - like avatars - you are forced to use a field of Meteor.users.profile to store data like the link to the user custom picture.