I have a "project" entity and each project can have many "models" (files and some metadata) and each model is associated with a "user".
So far I have considered each of the entities as a document in MongoDB, However, I find myself going back to SQl style when trying to create the relationships between them (e.g. adding the project ID in each model's metadata). Is this okay in the NoSQL world? Should I have a nested document for project which contains a list of all linked models? If yes, how can I do that considering that I use GridFs for storing the model files, while the project is just a normal document?
In MongoDB your data model should be such that the most frequently accessed queries should be blazing fast. In this scenario , since you are using GridFS for storing model files, you can store project,user etc as metadata for a GridFS model entry. You can then query 'metadata' and GridFS together. You can refer to this for specifics : GRIDFS Metadata
Related
Iam using nosql in totajs4 .
Document structure in nosql database
{directoryName:{fileName:{"created": timestamp,"modified":timestamp,"deleted":timestamp}}}
unable to update this structure.
Changing nested objects isn't supported yet in Total.js 4. I recommend reading the specific document and modify only the nested property/key.
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.
Like most of us, I'm coming from a relational database world,
and I'm currently looking into the possibilities of the document database world.
One of my concerns is the handling of changes in the data model over time (new properties are added, properties are renamed, relationships are added, ..).
In relational databases, this is typically handled as follows:
Write a database migration
-> Modify the database schema
-> Fix data for existing rows (typically contains some business logic)
Modify the code (ORM updates, ..)
When using a document database, I have a feeling that changes to the data model
are much easier; there's no need to update a database schema, mostly it's just adding a property, .. and everything "just works".
I wonder how teams are managing this kind of migrations in real life, Enterprise projects with document databases:
Is there a strict policy for making changes to Types that are stored in the document db?
For instance, does every change to such a Type require a migration to update
existing documents?
As a consequence, is there a clear separation between the data model (types stored in the document db) and the business model?
Thanks for your time,
Koen
With RavenDB, you can do that with patching.
See: http://ayende.com/blog/157185/awesome-ravendb-feature-of-the-day-evil-patching
And: http://blog.hibernatingrhinos.com/12705/new-option-in-the-ravendb-studiondash-patching
There are three general strategies that you can take for "schema" modifications in MongoDB. I've seen all three work well; which one you'll use depends a lot on your particular use case.
First: you can simply add a new field to new documents, and write your code to handle the case where that field does not exist. For example, you could add an 'address' field to your "user" documents, but you'd have to write your client code to handle the case where that field does not exist.
Second: you can write your code to look at the existing document & update it when it sees an "old-style" document. For example, you could have code that checks to see if there is a "name" field in your "user" document. If it finds that field, it would split it up into "first_name" and "sur_name" fields, $unset the "name" field in that document, and $set the new "first_name" and "sur_name" fields to their calculated values.
Third: you can batch-update all of the documents in the collection to use the new schema. You'd write the same code as above, but instead of lazily applying it when your application reads a document, you'd apply it to all the documents in the collection.
Note that this last strategy can have performance impact: if you page in a lot of documents that haven't been accessed for a while, you'll put an extra load on your MongoDB system.
I want to create only the collections structure.
i.e.
Say Products collection contains a list of Categories.
I want to specify this container structure by creating this dependencies, but I do not want to create any collection entry (say there is a loader program somewhere that bulk uploads the data).
The closet analogy in RDBMS is; DBA creates the schema design with constraints and dependencies; application or ETL tool loads the actual data.
Most of the examples that I see simply create a sample collection and then invoke the
db.insert(document)
OR
db.save(document)
Is it even possible in MongoDB?
if the question is not clear, please let me know.
Thanks
The short answer is NO.
You cannot create a schema in MongoDB. A collection is just a set of documents. Furthermore, dependencies are likely to be represented with embedded documents (as opposed to referenced documents).
We can be more specific if you post the data you want to represent.
I've never came across an app/class like Zend Search Lucene before, as I've always queried my database.
Zend_Search_Lucene operates with
documents as atomic objects for
indexing. A document is divided into
named fields, and fields have content
that can be searched.
A document is represented by the
Zend_Search_Lucene_Document class, and
this objects of this class contain
instances of Zend_Search_Lucene_Field
that represent the fields on the
document.
It is important to note that any
information can be added to the index.
Application-specific information or
metadata can be stored in the document
fields, and later retrieved with the
document during search.
So this is basically saying that I can apply this to anything including databases, the key thing here is making indexes for searching.
What I'm trying to grasp is where exactly should I store the indexes in my application, let's take for example we have phones stored in a database, a manufacturers, models - how should I categorize the indexes?
If I'm making indexes of users with say, addresses I obviously wouldn't want them to be publically viewable, I'm just confused on how it all works out together, if there are known disadvantages, any gotchas I should know while using it.
A Lucene index is stored outside the database. I'd store it in a "data" directory as a sister to your controllers, models, and views. But you can store it anywhere; you just need to specify the path when you open the index for querying.
It's basically a redundant copy of the documents stored in your database, and you have to keep them in sync yourself. That's one of the disadvantages: you have to write code to populate the Lucene index based on results of a query against your database. As you add data to the database, you have to update your Lucene index as well.
An advantage of using an external full-text index solution is that you can reduce the workload on your RDBMS. To find a document, you execute a search using the Lucene API. The result should include a field containing the primary key value (as part of the document but no need to make it analyzed for FT search). You get this field back when you do a Lucene search, so you can look up the respective row in the database.
Does that help answer your question?
I gave a presentation recently for MySQL University comparing full-text search solutions:
http://forge.mysql.com/wiki/Practical_Full-Text_Search_in_MySQL
I also publish my slides at http://www.SlideShare.net/billkarwin.