2

I am creating a new database using Firestore. I am new to NoSQL and trying to determine best practices for modeling my data. I know that Firestore data is shallow by default (as opposed to the Realtime Database) so nesting isn't a problem. That said, what would be the best way to model a more-or-less standard user object?

Option 1 — Parent Level Only:

users {
    uid {
        name: 'Bob',
        officeNumber: 1234567890,
        faxNumber: 0987654321,
        email: 'test@test.com',
        domain: '@test.com',
        facebook: 'bobdylan97',
        twitter: 'bobbystwitter',
        instagram: 'bobinsta',
        street: '111 N Elm St',
        city: 'Brooklyn',
        state: 'NY',
        zip: 12345,
        height: 72,
        weight: 200,
        hairColor: 'brown',
        eyeColor: 'blue'
    }
}

Option 2 — Nest Multiple Levels:

users {
    uid {
        personal {
            name {
                first: 'Bob',
                last: 'Dylan'
            },
            attributes {
                height: 72,
                weight: 200,
                hairColor: 'brown',
                eyeColor: 'blue'
            }
        },
        contact {
            phone {
                office: 1234567890,
                fax: 0987654321
            },
            email: 'test@test.com',
            domain: '@test.com',
            social {
                facebook: 'bobdylan97',
                twitter: 'bobbystwitter',
                instagram: 'bobinsta'
            }
        },
        address {
            street: '111 N Elm St',
            city: 'Brooklyn',
            state: 'NY',
            zip: 12345
        }
    }
}

The company I am building this for is growing and there may be additional data added at various points, so scaling is a potential concern. Are there any problems or concerns with grouping data like in Option 2? What is the best practice for modeling data like this? Is the best practice to optimize the model for querying or for organization?

Matt Campbell
  • 171
  • 4
  • 14
  • I just now stumbled upon this other question that is perhaps worded better than my own and addresses some of the questions that I am facing. [Firestore: Working with nested single queries](https://stackoverflow.com/questions/46724996/firestore-working-with-nested-single-queries?utm_medium=organic&utm_source=google_rich_qa&utm_campaign=google_rich_qa) – Matt Campbell Mar 30 '18 at 18:31
  • if you are using a OOP, then you can store it as #1 for ease of filtering/ordering/queries, and on your solution you'll have a User object more like #2 and a mapper to map #1 to #2, – Linxy Mar 30 '18 at 18:58

2 Answers2

0

I would reccomend you to watch: What is a NoSQL Database? - Get to Know Cloud Firestore Ep.1

It perfectly explains the basic concepts of Firestore.

JayJamesJay
  • 603
  • 4
  • 8
  • I've actually watched that video and many others on the channel but I don't think it quite answers what I am asking. That video is great and I've used that information to model everything as well as I can based on that; I have created subcollections or references to everything which will grow in size a lot to allow scaling. However, the question I have is in regard to organizing the data that won't necessarily grow a lot. For example, is it better practice to nest all the address info into an object? What about the contact info? Based on everything I know, I would guess that is better. – Matt Campbell Mar 30 '18 at 18:18
  • First option is easier to query. I mean you choose user, then property and done. On the other hand the second approach is more organized and more readable but it also requires more complex queries. – JayJamesJay Mar 30 '18 at 18:50
  • Yes, that is ultimately my question I guess. Is there a standard or best practice in regards to modeling the data? Is it best practice to model data so that it is easier to query or better to have it more organized? – Matt Campbell Mar 30 '18 at 18:52
  • 1
    IMHO it's better to keep data more organized and make them easily expandable. – JayJamesJay Mar 30 '18 at 19:31
0

If you are storing users in a users collection and the uid is the document ID, then Option 2 should work fine for you.

You are only storing a fairly small amount of data about each user in a document, so you shouldn't hit the 1Mb limit. You could probably squeeze a base64 encoded profile picture in here, too, without problem.

Jason Berryman
  • 4,760
  • 1
  • 26
  • 42