I am building a digital marketplace app. I would like to know what the best practice design patterns are for the backend (No SQL) object store.

The primary characteristics of the app are as follows:

  1. The app presents users with a series of editable lists (with CRUD functionality: create, read, update, delete).
  2. There is a main marketplace (list of items viewable and editable with user-specific data. An example of this would be a list of products for sale. And every user would be allowed to enter their bid on the product. All the users might be able to see the other bids but only edit their own bid).
  3. Users will have views of their own activity. And the ability to work from those lists. An example of this would be all unaccepted offers. Or all products being offered for sale by the user that have received bids from other users.

My question is, are there any guidelines for how to best design the data architecture when the back end is a No SQL object store like Firebase?

The following is an example of one such best-practice architecture I seek. However, it only deals with one list view. Those items added by a user but are only viewable to the user who created the items. Are there others?

 - users/
    - uid-xxxxxxxxxxxxxxxxxxxxxxxxxxxx/
       - items/
          + Xxxxxxxxxxxxxxxxxxxxxabc123
          + Xxxxxxxxxxxxxxxxxxxxxabc124
          + Xxxxxxxxxxxxxxxxxxxxxabc125

1 Answer 1


NoSQL is a term that covers very different families of databases, such as column stores, document stores, key-value stores, graph databases,etc... each having very different best practices.

If you specifically target Firebase, it's a JSON objects database, i.e. a document store:

  • Those are good practices for most any kind of data. Sep 1, 2016 at 14:40

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.