0

I'm have put together a schema in MongoDB to model my domain but I'm not sure what's the best approach considering what I will need to search on (premise: it's my first "big" project with a document database and I have quite a strong RDBMS background).

Here's an example document:

{
  id: 1,
  name: "Building A",
  description: "blah blah",
  geoLocation: [long, lat],
  flats: [
           {
              id: 1,
              name: "Flat A",
              squareFeet: 800
            },
           {
              id: 2,
              name: "Flat B",
              squareFeet: 900
           }
         ] 
}

I then have a search functionality which is supposed to search for flats. Assuming that that document is my whole DB, a blank search should return 2 results (the 2 flats).

This makes me think that I should change my schema to have a document per flat. The main issue I have with that is that the search will mainly be a location search and the location information lives with the Building and not with the flats. At the same time I need to be able to filter on square feet which is obviously a Flat level field.

Should I just create a document per Flat and duplicate the building information ? Problem with that obviously being updates at the Building level which can end up updating a lot of documents (1 update per flat).

I then thought about having to separate collections and create a relationship between the 2 (RDBMS style). Is that the best approach on a document database though ? If so, will that mean that after I search I have to query again and retrieve the buildings details ? Also, how will I handle the location search if the location information will be on the buildings document ?

I hope I did explain it decently well.

Any help ?

Thanks

Alessandro Di Lello
  • 1,181
  • 1
  • 9
  • 22
  • Welcome to NoSQL and one possible solution that might suit your needs. The basic premise here is "what works best for you" which is mostly governed by "how you actually use it". So if indeed you are doing more "updating" here than reading then you probably want a "flatter" more "referenced" model. And if you need to just read the "related" data then it is better in a "referenced" collection. On the other hand if you wan t "all" of the information ( master and related ) all at once, then you want the "embedded" model you are using. Read http://docs.mongodb.org/manual/core/data-model-design/ –  Jun 15 '15 at 14:27
  • The one thing I will add here is please consider using [GeoJSON](http://docs.mongodb.org/manual/reference/geojson/) for location data as it is most widely supported over legacy co-ordinate pairs as you seem to be using here. –  Jun 15 '15 at 14:30
  • Hi ! thanks for your comment ! The main thing is I would like to get the info all at once (as I'll always need the building information together with the flats) but I need to be able to search for flats, so I guess I will definitely need to change that so to have the "Flat" collection, correct ? To then be able to do a location search I will need to duplicate the GeoJSON info on every flat that belongs to the same building. There's no way I can avoid this right ? – Alessandro Di Lello Jun 15 '15 at 14:53
  • Again, it's not as simple as all of that. It all really depends on your total usage patterns. You have likely been taught the RDBMS way of doing things with normalized forms as "the way" of doing things. The reason NoSQL solutions exist is because "the way" does not always apply. If there is any lesson to learn here it is probably that you should not be using the NoSQL solution unless you truly understand why. And that is a much broader topic than answers here should deal with. –  Jun 15 '15 at 14:58
  • Thanks again, even if it wasn't a very helpful comment :) Anyway, I'm not looking for "the way" of doing it but I was simply asking for suggestions :) And usage patterns are important in RDBMS as well. I might have not explained my problem fully, anyway I'll research a bit more and see if I can post a valid answer. Thanks anyway – Alessandro Di Lello Jun 15 '15 at 15:18
  • I thought it was "helpful" to realize that your question as you have posted it is way "too broad" (and point out a valid source for reading ) for usefulness here. But if you don't want to listen then I suppose you'll just need to learn bad things from useless answers ( which I will not provide because the question is too broad ) or otherwise accept the question being closed for that very reason. I can only try and prompt you to be more specific. But if that does not work then good luck finding your solution. –  Jun 15 '15 at 15:26
  • I'll try and be more specific: assuming that I'll have way more searches than updates and considering that document structure. My application will need to search for is Flats. The search criteria is made of a location and I want then to be able to filter on squareFeet. Is it possible to do it with that document structure ? I'd say no as searching that collection won't return the right number of results (I need a result per Flat not per Building). Which made me think to create a Flat collection and reference the Buildings one which then leads to replication of location info on the Flats coll. – Alessandro Di Lello Jun 15 '15 at 15:34
  • Let us [continue this discussion in chat](http://chat.stackoverflow.com/rooms/80583/discussion-between-alessandro-di-lello-and-user3561036). – Alessandro Di Lello Jun 15 '15 at 15:35

0 Answers0