Forum | Appery.io

I have a bit of a best practices question.

In my app users register/login. I'm using the standard user collection with a few extra columns for email, fname, lname, birthday, etc.

The primary functionality of the app is to sync with users facebook and instagram accounts, provide lists of their friends, and allow them to select some or all of these connections to track within my app. I will be storing (and subsequently using) the IDs (facebook/instagram) of their friends to pull pictures, posts, etc. but I want to compile these (and possibly other social services in the future) within a 'friend profile' in my app.

i.e. I have a entry in my app with a unique ID, named John Smith that also contains an image a tagline and the IDs to identify that person in facebook/instagram/etc. for later use. Each of these entries (objects?) obviously need to be tied to my app user who is adding them and 'owns' them.

My question is, what is the best/most efficient way to handle this structure.

Should I simply add a column to the user collection of type 'object' and store (what could be 5-100) arrays of information in the single column? This seems like the simplest approach as I will only really need this one collection and all user info is neatly contained within a single row - however this one column could become quite large as each user could have dozens of these profiles stored, each with 10+ primitive data types in each.

Alternatively should I create a new collection called 'friend_profiles' where each profile is on a new row and has a separate column for the 10+ data points (plus another which is a 'pointer' back to the user ID)? This spreads out the information into a bunch more columns and seems cleaner in some ways, but also seems like it might be unnecessary and make listing all the 'friend profiles' of one of my apps users more difficult.

Is one better than the other? Will it make the app quicker, make it easier to add/remove/edit/list results? Is there another way that I'm not even considering?

Hoping someone with more data architecture experience can help point me in the right direction and maybe save me some grief down the road.

Thanks so much. Appery.io is making my dreams come true!

Hi Case -

When modeling your data to be stored and queried (Appery.io uses MongoDB), you should consider how you plan to actually use and query your data, what part of this data structures will be called frequently. Based on the answer to that, you should be able to come up with a good data structure for storing the data.

It would be good for you to to familiarize yourself with query methods: http://docs.appery.io/documentation/b...

When you think about embedding, here is some guidelines, hope that they will help you:

Embedding is frequently the choice for:
ul
li“contains” relationships between entities./li
lione-to-many relationships when the “many” objects always appear with or are viewed in the context of their parents./li
/ul

You should also consider embedding for performance reasons if you have a collection with a large number of small documents. Nevertheless, if small, separate documents represent the natural model for the data, then you should maintain that model.

If, however, you can group these small documents by some logical relationship and you frequently retrieve the documents by this grouping, you might consider “rolling-up” the small documents into larger documents that contain an array of subdocuments. Keep in mind that if you often only need to retrieve a subset of the documents within the group, then “rolling-up” the documents may not provide better performance.

“Rolling up” these small documents into logical groupings means that queries to retrieve a group of documents involve sequential reads and fewer random disk accesses.

Thanks Illya, this is a big help.

Based on my current understanding of Mongo DB query methods it seems that a separate collection pointing (referencing seems like the term used?) to user info would be simplest for someone (like me) coming from relational databases - that said, not the most efficient.

The idea of 'rolling-up' (same as embedding right?) seems like it is preferable as when I retrieve/list the small documents I will do so for all of them at once and simply grabbing the entire contents of a large document (single row in a column?) and mapping out the arrays of info within seems straightforward. I believe based on your description this would also perform better as it would be the sequential reads. My only concern is with removing/editing/adding these small document arrays since it seems querying may be a little more confusing (but doable).

Off to read more MongoDB on one-to-many relationships

Hi Case,

Yes, you understand everything correctly.