Using SQLite, I had a table of products, one category and one subcategory.
The subcategory had FK of the category, and the product had FK of subcategory.
But since Cloud Firestore is a non-relational database, Id like to understand how it works
the relationship of collections or documents.
Any relationships between documents and collections is purely one that you express in code. Unlike many SQL databases, you can't force referential integrity between items. You can create reference type fields that point to other documents, but those documents don't have to exist. You can also simply store document IDs as string within other related documents. It's entirely flexible and up to you to decide what's best for your specific case.
Related
I have a question about querying with Firestore.
Indeed, I am developing a mobile application of the social network type with a feed of publications from its subscribers.
However, I can't find any solution using Firestore to view posts from all my subscriptions.
Currently, I have a collection "Users" (which contains a uid and my user information), "Publications" (which lists all the publications of the application) and a document with my list of uid to who I am subscriber.
I was thinking of doing a query like "Show all publications in the collection 'Publications' where uid = one of the uid in my array of uid and order by date.
However, I haven't found a solution to do it because the solution I found is to use the IN operator which is limited to 10 items, while I can have thousands of subscriptions.
ref.orderBy('date', 'desc').where('uid', 'in', arrayOfUid).get();
Do you have an idea ?
You can't exceed the limits of the "in" query. If you need more, you will have to perform multiple queries, and merge their results in the app. There are no workarounds to this.
I am planning my database structure for one of my projects and keep seeing that Firestore querying works best when all of your documents of similar type are in one collection such as this
[Posts] [Users]
- id1 - uid1
:doc1 :doc1
- id2 - uid2
:doc2 :doc2
However, is this always best for querying even if one collection has lets say 1 million documents?
In my current project, I anticipate several "post" documents and am wondering if it would be best to organize them in sub-collections based on year to make sure a certain collection won't be overfilled.
The size of the collection doesn't matter at all. Firestore scales massively, and queries will not slow down as a collection grows. If you need all your documents to be in a single collection for effective querying, then just do that. If you need billions of document in a collection, that is no problem.
Is there a way with Firebase or Angularfire2 to get all the docs in a collection, as well as, one or all of the immediate subcollections.
For example, if I have a collection of categories where each category has a name, as well as a subcollection of subcategories, is there a way to get all the categories with their subcategory collection?
In my head, I'd want to do something like this:
afs.collection("categories").withSubcollection("subcategories");
Another idea I was thinking of that would work but isn't possible, would be to use a wildcard in the path like this:
afs.collection("categories/{categoryId}/subcategories");
I know neither of these are possible, just wanted to see if there was a way to do what I am showing.
At the moment, I store the subcategories in an array on the category document, but documents have a maximum size, a category could theoretically have an unlimited number of subcategories.
Read operations in Firestore are always shallow, and only return document(s) from a single collection. To read documents from multiple collections, you'll need multiple read operations.
The only exception to this is when the collections you want to query have the same name, in which case you can use a collection group query.
I honestly doubt if storing the categories in a subcollection is worth the hassle. While a document has a maximum size, it's 1MB. I'd highly recommend doing the path on how many categories you can store in that, and whether that is a reasonable limit for your app.
I'm totally new to Firebase, and I'm trying to get my head round the best db model design for 'relational' data, both 1-1 and 1-many.
We are using the Firestore db (not the realtime db).
Say we have Projects which can contain many Users, and a User can be in multiple Projects
The UI needs to show a list of Users in a Project which shows things like email, firstname, lastname and department.
What is the best way to store the relationship?
An array of User ids in the Project document?
A map of Ids in the Project document?
Ive read the above approaches were recommended, but was that for realtime database? Firestore supports Sub Collections, which sound more appropriate...
A sub collection of Users in the Project document?
A separate collection mapping Project id to User id?
A Reference data type? I've read here https://firebase.google.com/docs/firestore/manage-data/data-types about Reference data type, which sounds like what I want, but I cant find any more on it!
If its just a map or array of Ids, how would you then retrieve the remaining data about the user? Would this have to sit in the application UI?
If its a sub collection of Users documents, is there any way to maintain data integrity? If a user changed their name, would the UI / a cloudFunction then have to update every entry of that users name in the Sub collections?
any help / pointers appreciated...
The approach for modeling many-to-many relationships in Firestore is pretty much the same as it was in Firebase's Realtime Database, which I've answered here: Many to Many relationship in Firebase. The only difference is indeed that you can store the lookup list in a sub-collection of each project/user.
Looking up the linked item is also the same as before, it indeed requires loading them individually from the client. Such a client-side join is not nearly as slow as you may initially expect, so test it before assuming it can't possibly be fast enough.
Ensuring data integrity can be accomplished by performing batched writes or using transactions. These either completely succeed or completely fail.
I have thousands of documents of different types and therefore different fields. My task is to find pairs or a group of documents, with specific relations:
A.race='dwarf' and B.race='elfe' and C.profession='thief'
A.haircolor = C.haircolor and B.favorite_meal = C.favorite_meal
Is there a database which is schema-less and relational?
Having a schema is part of the definition of a relational database, so a database can not be both schemaless and relational.
But when you are searching for a database which is good for modeling and analyzing relations between entities without enforcing a consistent schema, you could take a look at graph databases like Neo4j. These databases focus on defining entities mostly by their relation to other entities. They make it really easy to find entities which have common relations to other entities.