I'm trying to model a database of an app that allows me to take the reading of water meters and then generate an invoice, but I'm a little confused about the subcollections, what I have so far is a collection that I call contract and within the document of that collection I have a collection. My question is are the other collections should go within the document of the user collection?
In the attached image I made a model where I have the contract collection and within the contract collection document I have a client collection within the client collection document I have the consumption collections, property type meter, could you guide me if this model is correct? If I am wrong I appreciate any suggestion.
Related
I am trying to build a database with Cloud Firestore and having read the documentation about hierarchic structure I have found another solution to the one present in the documentation example.
I have a collection of categories, and each category can have subcategories. Whereas I could use the system provided in the Firestore documentation example such as collection/document/subcollection/document... I have found another example for MongoDB where instead of having subcollections it uses nested data in a single document with parent-child relations as described in the image below
What approach is better if I want the user to be able to see all the subcategories so the user can categorize a certain event? By better I mean in terms of avoiding multiple connections to the DB (as this is what Firestore prices with).
This document discusses nested data and its tradeoffs, "Choose a Data Structure". I'm not sure that the statement about multiple connections for pricing is correct. Firestore charges for number of operations, storage, and network bandwidth.
If all users share a single categories list, you would be able to retrieve the entire list with one operation with your current structure. Note that there is a 1 MiB limit for document size.
I'm trying to build an ionic application which retrieves data from Cloudant using pouchdb. Cloudant allows creating only databases and documents.
How can I create some collections in Cloudant?
Two part answer:
A set of documents that meet certain criteria can be considered a collection in Cloudant/CouchDB. You can create views to fetch those documents. Such a view might check for the existence of a property in a document ("all documents with a property named type"), the value of a property ("all documents with a property named type having the value of book") or any other condition that makes sense for your application and return the appropriate documents.
You basically have to follow a three step process:
determine how you can identify documents in your database that you consider to be part of the collection
create a view based on your findings in the previous step
query the view to retrieve those documents
Above documentation link provides more details.
Properties in your document can represent collections as well, as in the following example, which defines a simple array of strings.
{
"mycollectionname": [
"element1",
"element2",
...
]
}
How you implement collections really depends on your use-case scenario.
Long post, but hope that helps.
I would like to explain this with a RDBMS analogy.
In any RDBMS, a new database would mean a different connection with different set of credentials.
A collection would mean the set of tables in that particular database.
A record would mean a row in a table.
Similarly, you can look at a single Cloudant service instance as a database(RDBMS terminology).
A collection would be a "database" in that service instance in Cloudant's terminology.
A document would correpond to a single row.
Hence, Cloudant has no concept of collection as such. If you need to store your related documents in a separate collection you must do it with multiple databases within the same service instance.
If you want to use only a single database, you could create a field like "record_index" to differentiate between the different documents. While querying these documents, you could use an index. For. e.g. I have a student database. But I do not want to store the records for Arts, Commerce, Science branches in different databases. I will add a field "record_type": "arts", etc. in the records. Create an index,
{ selector: {record_type: "arts"}}
Before doing any operation on the arts records, you can use this index and query the documents. In this way, you will be able to logically group your documents.
Consider this picture:
The book says documents store database struggle with highly connected domains because "relationships between aggregates aren’t firstclass citizens in the data model, most aggregate stores furnish only the insides of aggregates with structure, in the form of nested maps.
".
And besides: "Instead, the application that uses the database must build relationships from these flat, disconnected data structures."
I'm sorry, I don't understand what does it mean. Why documents store database struggle with a context based on highly relationships?
Because document stores do not support joins. Each time you need to get more data it is a separate query. Instead, document stores support the idea of nesting data within documents.
I am attempting to convert a large MySQL database of product information (dimensions, specifications, etc) to MongoDB for flexibility and to move away from the restriction of a column based table. I like the freedom of being able to add a new key-value, without making an update to table structure.
An example of my data is here: http://textuploader.com/9nwo. I envisioned my collection being "Products", with a nested collection for each product type (ex. Hand Chain Hoists), and a nested collected manufacturer (ex. Coffing & Harrington). Basically one large multidimensional array. I am learning that nested collections are not allowed in MongoDB, so I'm at a dead end.
How would you store this kind of dataset? Is NoSQL the right choice for this?
If the nested structure is not necessary, you can "flatten" your data by having each document in the collection be a specific product and each product can have manufacturer product type as fields. You can index these fields so you can still query them quickly without a nested structure.
If you need to preserve the hierarchy, mongodb actually has a tutorial on designing a product hierarchy model here: http://docs.mongodb.org/ecosystem/use-cases/category-hierarchy/. Essentially, each product has an ancestors array. It is a bit trickier keeping the hierarchy up to date on inserts and updates
The case:
There are users in system, and there are static documents (like books) Each user may work with some documents and have specific state/settings (like current position/page in document, bookmarks/notes) for each of his docs.
What is a better way to store that user and document specific information in flat collection with two keys userId and documentId or collection that have _id equal to userId and nested array of subdocuments that have _id equal to documentId (in that scenario collection is also used for storing non-document specific user data)?
1st scenaroio: find({userId: ..., documentId:...})
2nd scenaroio: findBy({_id:...}), then find sub doc with _id equal to documentId
PROS of 1st scenario:
1) I believe quicker find and save operations.
CONS of 1st scenario:
1) greater amount of documents
2) no way to store some non-doc related user-specific data in collection
PROS of 2nd scenario:
1) better representation of data relations (subjective though)
2) makes possible to use the same collection to store some other non particular document related user data.
CONS of 2nd:
1) more difficult search and more difficult save operations (I'm using using Mongoose ODM and code would not be complex), and I think the operations is less speedy then in 1st scenario.
Some things to consider:
1) In general in read operations I would to select only one document specific data
2) I would need OFTEN to save one document specific data (for example periodical saving of position in document that user is working with).
3) User/document state may have some nested arrays (bookmarks, notes) that have to be changed (docs inserted/removed)
Taking this considerations I would say that 1st scenario is more suitable for the task, but I would like to hear some pro opinions, whether two scenarios differ greatly.
What are your actual access paths? Do you start with a user id, and the look for the documents the user reads? Or do you start with a document and search for the users, that read it?
Is the document object lightweight (just title and author and suchlike information) or is it heavyweight (includes the contents)?
If documents are heavyweight, I'd keep them in a separate collection and go for scenario 2.
Basically scenario 1 mimics a relational solution and scenario looks like an object model.
I believe object models describe the reality better and are more efficient.
So I'd go for scenario 2, unless you frequently search the readers for a book.