Databases
StackOverflow2013
Postsdbo
PO
 

Note that there are some explanatory texts on larger screens.

plurals
  1. PO
    primarykey
    data
    text
    <h2>EDIT:</h2> <p>Just found <a href="https://groups.google.com/d/msg/mongodb-casbah-users/VkJ-aIxSIs8/8N4yvlMMaAIJ" rel="nofollow">an answer</a> of Brendan McAdams, guy from 10gen, who is obviously way way authoritative than me, and he recommends to embed documents.</p> <hr> <h2>older text:</h2> <p>The first one is to manually include to each comment ObjectID of user they're belong.</p> <pre><code>comment: { text : "...", date: "...", user: ObjectId("4b866f08234ae01d21d89604"), votes: 7 } </code></pre> <p>The second one, and clever way is to <a href="http://www.mongodb.org/display/DOCS/Database+References" rel="nofollow">use DBRefs</a></p> <p><em>we add extra I/O to our disk, losing performance am i right? (i'm not sure how this work internally) therefore we need to avoid linking if possible, right?</em></p> <p>Yes - there would be one more query, but driver will do it for you - you can think of this as of kind of syntax sugar. Does it affect performance? Actually, it is depends too :) One of the reasons why Mongo so freaking fast is that it is using <a href="http://en.wikipedia.org/wiki/Memory-mapped_file" rel="nofollow">memory mapped files </a> and mongo try it best to keep all of the working set (plus indexes) directly in RAM. And every 60 seconds (by default) it syncs RAM snapshot with disk based file.<br> When I'm saying <em>working set</em>, I mean things you are working with: you can have three collections - <strong>foo</strong>, <strong>bar</strong>, <strong>baz</strong>, but if you are working now only with foo and bar, they ought to be loaded into ram, while baz stays on disk abandoned. Moreover memory mapped files allow as to load only part of the collection. So if you're building something like engadget or techcrunch there is high probability that working set would be comments for the last few days and old pages will be revived way less frequently (comments would be spawned to memory on demand), so it doesn't affect performance significally.</p> <p>So recap: as long as you keep working set in memory (you may think that is read/write caching), fetching of those things is superfast and one more query wouldn't be a problem. If you working with a slices of data that doesn't fit into memory, there would be speed <a href="http://www.colinhowe.co.uk/2011/02/23/mongodb-performance-for-data-bigger-than-memor/" rel="nofollow">degradation</a>, but I don't now your circumstances -- it could be acceptable, so in both cases I tend to choose <em>do use</em> linking.</p>
    singulars
    1. This table or related slice is empty.
    1. POHow to deal with relationships while using mongodb
      singulars
      1. PTQuestion
    1. PTAnswer
    1. USom-nom-nom
    1. USom-nom-nom
    plurals
    1. This table or related slice is empty.
    1. This table or related slice is empty.
    1. POHow to deal with relationships while using mongodb
      singulars
      1. PTQuestion
    1. This table or related slice is empty.
    1. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTAcceptedByOriginator
    2. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    3. VO
      singulars
      1. PO
      1. This table or related slice is empty.
      1. VTUpMod
    1. COhmm, so using DBRefs ensures automatic process linking, without having to do extra query in the client side, am i right?
      singulars
      1. PO
      1. USzebnat
    2. CO@zebnat Well, it depends - e.g. C++ driver can't handle them, so you have to do all work for it manually, but many drivers can do that: in Ruby you call dereference method, Python can do that [automagically](http://github.com/mongodb/mongo-python-driver/blob/cd47b2475c5fe567e98696e6bc5af3c402891d12/examples/auto_reference.py).
      singulars
      1. PO
      1. USom-nom-nom
    3. COJust as a clarification - technically there will be one more query, but it goes under the hood, implicitly
      singulars
      1. PO
      1. USom-nom-nom
 

Querying!

 
Guidance
A row detail

Detail views are divided into sections. All the information in the data section comes from columns in the selected row. The other sections display data from other, related rows.

Related data can be related in a to-one or a to-many fashion. Captions of data related in a to-many fashion link to a list view showing a filtered view of the table.

Try moving around until you find a non-empty to-many entry and click on the label to get to one. You can move back to the root by clicking on the database name in the header.

SQuiL has stopped working due to an internal error.

If you are curious you may find further information in the browser console, which is accessible through the devtools (F12).

Reload