To remove all fields (aside from _id
), you can just update with an empty document:
<?php
$collection->update(array('name' => 'Amy'), array());
?>
That will update the document leaving only the _id
field.
Note that this won't free up any of the preallocated space for your capped collection.
Short version: use a manual reference, not a DBRef
.
Explanation:
There is no particular benefit to the use of a DBRef
beyond giving you the collection and database that the referenced document resides in. If you know the reference is only between categories and products, then that is not particularly useful. A DBRef
simply contains the _id
of the referenced document, the collection name and optionally the database name. You will usually have all that information in your application (i.e. you have the _id and you know that db/collection it resides in already).
If that were not the case, let's say you had references to documents in a slew of databases and collections and it was difficult or cumbersome application side to keep track of which one each document resided in, then it may be a benefit to use DBRefs
. After all, the easiest way to do a manual reference in that case would be to store the database and collection that you are referencing in the document too, and that is what DBRefs
do for you in any case.
That (referencing multiple collections from a single source collection) is not a terribly common pattern though and not what you have outlined above, and so unless you have such a compelling reason to use them, manual references are recommended instead.
Some of the drivers have helper methods which may save a few lines of code versus a manual reference, but not all drivers do, and it may make the code harder to understand (without some nice comments/documentation to explain it). As well as that, the DBREF approach is more fixed than a manual implementation - what if you want to reference a field other than _id
for example.
Finally, in terms of product catalog design, I would highly recommend reading these two excellent and detailed blog posts from Antoine Girbal:
There were also three presentations given at MongoDB World 2014 on this very topic, so I would recommend reviewing those also as you progress:
Best Answer
In the context of MongoDB, a document means any piece of valid BSON* (binary JSON). The word does not have the everyday meaning of, say, an MS Word file or PDF.
A collection is a container for zero or more documents. There is no requirement for all documents in a collection to have the same structure. Indeed, that is one of the drivers behind the NoSQL movement. So it would be possible to store a shopping cart, a birth certificate and a recipie for chocolate cake in the same collection. (Though possible it would be an exceedingly poor design.) A collection is also the boundary for some management tasks, like copying, and authorisation.
* BSON is actually an important distinction as there are more data types than JSON. For example, the default primary key (
_id
field) is anObjectId
, which doesn't exist as a standard JSON type.For more context see:
BSON and MongoDB Extended JSON are JSON-like in terms of document structure, but definitely not interchangeable.