Discussion:
Newbie question: Relational vs MongoDB
(too old to reply)
AverageJoe
2012-09-08 19:08:18 UTC
Permalink
How would I properly represent this simple 3 table structure in MongoDB?

customers
cust_id INTEGER
lastname VARCHAR(15)
firstname VARCHAR(15)

events
event_id INTEGER
event_title VARCHAR(50)
event_date DATE
event_location VARCHAR(50)

registrations
reg_id INTEGER
event_id INTEGER
cust_id INTEGER
signup_date DATE

Would I use something like ...

$doc = array( "event_title" => "Big Event Here", "event_date" => new
MongoDate(strtotime("2012-10-01 00:00:00")));
$events->Insert($doc);
$doc = array( "event_title" => "Another Event Here", "event_date" => new
MongoDate(strtotime("2012-10-15 00:00:00")));
$events->Insert($doc);

$doc = array ( "firstname" => "Joe", "lastname" => "Test",
"registrations" => array( "event_id" => *id of event*, "signup_date"
=> new MongoDate())
);
$customers->insert($doc);

That's seems very relational to me...I would also need another query to
determine the event date and location

Thoughts?

Thank you!
--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongodb-user-/***@public.gmane.org
To unsubscribe from this group, send email to
mongodb-user+unsubscribe-/***@public.gmane.org
See also the IRC channel -- freenode.net#mongodb
AverageJoe
2012-09-08 19:21:07 UTC
Permalink
How would I properly represent this simple 3 table structure in MongoDB?

customers
cust_id INTEGER
lastname VARCHAR(15)
firstname VARCHAR(15)

events
event_id INTEGER
event_title VARCHAR(50)
event_date DATE
event_location VARCHAR(50)

registrations
reg_id INTEGER
event_id INTEGER
cust_id INTEGER
signup_date DATE

Would I use something like ...
$doc = array( "event_title" => "Big Event Here", "event_date" => new
MongoDate(strtotime("2012-10-01 00:00:00")));
$events->Insert($doc);
$doc = array( "event_title" => "Another Event Here", "event_date" => new
MongoDate(strtotime("2012-10-15 00:00:00")));
$events->Insert($doc);

$doc = array ( "firstname" => "Joe", "lastname" => "Test",
"registrations" => array( "event_id" => *id of event*, "signup_date"
=> new MongoDate())
);
$customers->insert($doc);

That's seems very relational to me...
I would even need another query to lookup the event date and location

Thoughts? Advice?

Thank you!
--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongodb-user-/***@public.gmane.org
To unsubscribe from this group, send email to
mongodb-user+unsubscribe-/***@public.gmane.org
See also the IRC channel -- freenode.net#mongodb
aliane abdelouahab
2012-09-08 21:47:02 UTC
Permalink
am sorry if i dont answer about the content, but about the question,
i'll say: mongodb uses two things that you dont find in relational:
nested documents.
dynamic schema (you can add things whenever you want)
so, because am a newbie like you, i've made an e-commerce application
using mongodb db, and here is my experience:
made a user document.
then, "push" products to the user document! so your application will
be a "rocket" when "reading" :)
sorry for not asnwering for the content :)
Post by AverageJoe
How would I properly represent this simple 3 table structure in MongoDB?
customers
  cust_id   INTEGER
  lastname   VARCHAR(15)
  firstname   VARCHAR(15)
events
  event_id   INTEGER
  event_title   VARCHAR(50)
  event_date   DATE
  event_location   VARCHAR(50)
registrations
  reg_id   INTEGER
  event_id   INTEGER
  cust_id   INTEGER
  signup_date   DATE
Would I use something like ...
$doc = array( "event_title" => "Big Event Here", "event_date" => new
MongoDate(strtotime("2012-10-01 00:00:00")));
$events->Insert($doc);
$doc = array( "event_title" => "Another Event Here", "event_date" => new
MongoDate(strtotime("2012-10-15 00:00:00")));
$events->Insert($doc);
$doc = array ( "firstname" => "Joe", "lastname" => "Test",
     "registrations" => array( "event_id" => *id of event*, "signup_date"
=> new MongoDate())
);
$customers->insert($doc);
That's seems very relational to me...I would also need another query to
determine the event date and location
Thoughts?
Thank you!
--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongodb-user-/***@public.gmane.org
To unsubscribe from this group, send email to
mongodb-user+unsubscribe-/***@public.gmane.org
See also the IRC channel -- freenode.net#mongodb
Stephen Steneker
2012-09-09 13:20:57 UTC
Permalink
Post by AverageJoe
How would I properly represent this simple 3 table structure in MongoDB?
customers
..
events
Post by AverageJoe
..
registrations
Post by AverageJoe
..
That's seems very relational to me...I would also need another query to
determine the event date and location
Hi,

Unlike relational databases where some form of normalization might be
considered "proper" .. data modelling in MongoDB is driven by your
application requirements and common use cases for updating and querying the
data. The MongoDB data modelling approach is much more akin to that of a
data warehouse where you may choose to denormalize data to make queries
more efficient.

In your example of customers, events, and registrations you could choose to
have:
- customers as a collection
- events as a collection embedding registrations; registrations could
include a cust_id field which would be the related _id in the `customers`
collection

With this approach, customers could register for multiple events and their
full details would only be saved once in the customers collection. However
.. if you wanted to find a list of all customer details for a given event
you would have to perform multiple queries (one for the event and then one
for each customer who registered for that event). Some MongoDB language
drivers have helpers to perform the additional queries using the convention
of a Database Reference (DBRef) .. but this still translates to multiple
queries for the mongod server.

If customers are unlikely to change their details often (first name and
last name in your example), you could also decide to approach as:
- events as a collection embedding registrations (which include customer
details)

In this case you could efficiently query the data .. at the slight expense
of some duplication of customer's details (first name, last name). The
tradeoff is query efficiency versus extra cost in updates should the
customers first/last name need to be changed in future.

The information and presentations linked from the schema design page should
be a good starting point:
http://www.mongodb.org/display/DOCS/Schema+Design

.. as is this blog post on schema considerations:
https://openshift.redhat.com/community/blogs/designing-mongodb-schemas-with-embedded-non-embedded-and-bucket-structures

Cheers,
Stephen
--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongodb-user-/***@public.gmane.org
To unsubscribe from this group, send email to
mongodb-user+unsubscribe-/***@public.gmane.org
See also the IRC channel -- freenode.net#mongodb
AverageJoe
2012-09-09 17:54:45 UTC
Permalink
Thank you for the response. I guess I'm going to have to fumble my way
through to find the BEST way to use this.

My primary reason for seeking out a NoSQL tool is because I'm designing
something for a client where each user can be a member of one or more
groups within their organization, and each group may have it own, different
descriptive fields. Instead of custom coding a new table for every type of
group, I am hoping that I can use MongoDB to use one collection with
varying document details depending upon the group(s) people are members of.
Post by AverageJoe
How would I properly represent this simple 3 table structure in MongoDB?
Post by AverageJoe
customers
..
events
Post by AverageJoe
..
registrations
Post by AverageJoe
..
That's seems very relational to me...I would also need another query to
determine the event date and location
Hi,
Unlike relational databases where some form of normalization might be
considered "proper" .. data modelling in MongoDB is driven by your
application requirements and common use cases for updating and querying the
data. The MongoDB data modelling approach is much more akin to that of a
data warehouse where you may choose to denormalize data to make queries
more efficient.
In your example of customers, events, and registrations you could choose
- customers as a collection
- events as a collection embedding registrations; registrations could
include a cust_id field which would be the related _id in the `customers`
collection
With this approach, customers could register for multiple events and their
full details would only be saved once in the customers collection. However
.. if you wanted to find a list of all customer details for a given event
you would have to perform multiple queries (one for the event and then one
for each customer who registered for that event). Some MongoDB language
drivers have helpers to perform the additional queries using the convention
of a Database Reference (DBRef) .. but this still translates to multiple
queries for the mongod server.
If customers are unlikely to change their details often (first name and
- events as a collection embedding registrations (which include customer
details)
In this case you could efficiently query the data .. at the slight expense
of some duplication of customer's details (first name, last name). The
tradeoff is query efficiency versus extra cost in updates should the
customers first/last name need to be changed in future.
The information and presentations linked from the schema design page
http://www.mongodb.org/display/DOCS/Schema+Design
https://openshift.redhat.com/community/blogs/designing-mongodb-schemas-with-embedded-non-embedded-and-bucket-structures
Cheers,
Stephen
--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongodb-user-/***@public.gmane.org
To unsubscribe from this group, send email to
mongodb-user+unsubscribe-/***@public.gmane.org
See also the IRC channel -- freenode.net#mongodb
aliane abdelouahab
2012-09-09 19:29:58 UTC
Permalink
before designing your schema, think about: will your application be
heavy wright, or heavy read.
i give you an example, this group, because google uses a nosql
solution, you can't update your answer, you can only delete it or add
a new one ;)
or think about facebook in the past, they dident allow to modify your
comment, only deleting it.
hope this example make sense for your design ;)
Thank you for the response.  I guess I'm going to have to fumble my way
through to find the BEST way to use this.
My primary reason for seeking out a NoSQL tool is because I'm designing
something for a client where each user can be a member of one or more
groups within their organization, and each group may have it own, different
descriptive fields.  Instead of custom coding a new table for every type of
group, I am hoping that I can use MongoDB to use one collection with
varying document details depending upon the group(s) people are members of.
Post by AverageJoe
How would I properly represent this simple 3 table structure in MongoDB?
Post by AverageJoe
customers
..
events
Post by AverageJoe
..
registrations
Post by AverageJoe
..
That's seems very relational to me...I would also need another query to
determine the event date and location
Hi,
Unlike relational databases where some form of normalization might be
considered "proper" .. data modelling in MongoDB is driven by your
application requirements and common use cases for updating and querying the
data.  The MongoDB data modelling approach is much more akin to that of a
data warehouse where you may choose to denormalize data to make queries
more efficient.
In your example of customers, events, and registrations you could choose
 - customers as a collection
 - events as a collection embedding registrations; registrations could
include a cust_id field which would be the related _id in the `customers`
collection
With this approach, customers could register for multiple events and their
full details would only be saved once in the customers collection.  However
.. if you wanted to find a list of all customer details for a given event
you would have to perform multiple queries (one for the event and then one
for each customer who registered for that event).  Some MongoDB language
drivers have helpers to perform the additional queries using the convention
of a Database Reference (DBRef) .. but this still translates to multiple
queries for the mongod server.
If customers are unlikely to change their details often (first name and
 - events as a collection embedding registrations (which include customer
details)
In this case you could efficiently query the data .. at the slight expense
of some duplication of customer's details (first name, last name).  The
tradeoff is query efficiency versus extra cost in updates should the
customers first/last name need to be changed in future.
The information and presentations linked from the schema design page
   http://www.mongodb.org/display/DOCS/Schema+Design
https://openshift.redhat.com/community/blogs/designing-mongodb-schema...
Cheers,
Stephen
--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongodb-user-/***@public.gmane.org
To unsubscribe from this group, send email to
mongodb-user+unsubscribe-/***@public.gmane.org
See also the IRC channel -- freenode.net#mongodb
Sam Millman
2012-09-09 20:41:13 UTC
Permalink
The scenario of facebook was nothing to do with their DB, it was actually
to do with their policy.

They were an incredably simple site and they saw modification of content as
complexity, uneeded complexity. They have not changed DB nor DB structure
for your data (except using Cassandra for small things like inbox search).

Rarely does a site always stay read heavy or write heavy, however a lot of
time it is read heavy (about 80% read). But you will need to counter for
both if you were to ask me personally on the matter. Your schema (unless
dead set on a particular op pattern) should cater part in part for both
reads and writes.
Post by aliane abdelouahab
before designing your schema, think about: will your application be
heavy wright, or heavy read.
i give you an example, this group, because google uses a nosql
solution, you can't update your answer, you can only delete it or add
a new one ;)
or think about facebook in the past, they dident allow to modify your
comment, only deleting it.
hope this example make sense for your design ;)
Post by AverageJoe
Thank you for the response. I guess I'm going to have to fumble my way
through to find the BEST way to use this.
My primary reason for seeking out a NoSQL tool is because I'm designing
something for a client where each user can be a member of one or more
groups within their organization, and each group may have it own,
different
Post by AverageJoe
descriptive fields. Instead of custom coding a new table for every type
of
Post by AverageJoe
group, I am hoping that I can use MongoDB to use one collection with
varying document details depending upon the group(s) people are members
of.
Post by AverageJoe
Post by AverageJoe
How would I properly represent this simple 3 table structure in
MongoDB?
Post by AverageJoe
Post by AverageJoe
Post by AverageJoe
customers
..
events
Post by AverageJoe
..
registrations
Post by AverageJoe
..
That's seems very relational to me...I would also need another query
to
Post by AverageJoe
Post by AverageJoe
Post by AverageJoe
determine the event date and location
Hi,
Unlike relational databases where some form of normalization might be
considered "proper" .. data modelling in MongoDB is driven by your
application requirements and common use cases for updating and
querying the
Post by AverageJoe
Post by AverageJoe
data. The MongoDB data modelling approach is much more akin to that
of a
Post by AverageJoe
Post by AverageJoe
data warehouse where you may choose to denormalize data to make queries
more efficient.
In your example of customers, events, and registrations you could
choose
Post by AverageJoe
Post by AverageJoe
- customers as a collection
- events as a collection embedding registrations; registrations could
include a cust_id field which would be the related _id in the
`customers`
Post by AverageJoe
Post by AverageJoe
collection
With this approach, customers could register for multiple events and
their
Post by AverageJoe
Post by AverageJoe
full details would only be saved once in the customers collection.
However
Post by AverageJoe
Post by AverageJoe
.. if you wanted to find a list of all customer details for a given
event
Post by AverageJoe
Post by AverageJoe
you would have to perform multiple queries (one for the event and then
one
Post by AverageJoe
Post by AverageJoe
for each customer who registered for that event). Some MongoDB
language
Post by AverageJoe
Post by AverageJoe
drivers have helpers to perform the additional queries using the
convention
Post by AverageJoe
Post by AverageJoe
of a Database Reference (DBRef) .. but this still translates to
multiple
Post by AverageJoe
Post by AverageJoe
queries for the mongod server.
If customers are unlikely to change their details often (first name and
- events as a collection embedding registrations (which include
customer
Post by AverageJoe
Post by AverageJoe
details)
In this case you could efficiently query the data .. at the slight
expense
Post by AverageJoe
Post by AverageJoe
of some duplication of customer's details (first name, last name). The
tradeoff is query efficiency versus extra cost in updates should the
customers first/last name need to be changed in future.
The information and presentations linked from the schema design page
http://www.mongodb.org/display/DOCS/Schema+Design
https://openshift.redhat.com/community/blogs/designing-mongodb-schema.
..
Post by AverageJoe
Post by AverageJoe
Cheers,
Stephen
--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To unsubscribe from this group, send email to
See also the IRC channel -- freenode.net#mongodb
--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongodb-user-/***@public.gmane.org
To unsubscribe from this group, send email to
mongodb-user+unsubscribe-/***@public.gmane.org
See also the IRC channel -- freenode.net#mongodb
Sam Millman
2012-09-09 20:42:25 UTC
Permalink
"My primary reason for seeking out a NoSQL tool is because I'm designing
something for a client where each user can be a member of one or more
groups within their organization, and each group may have it own, different
descriptive fields. Instead of custom coding a new table for every type of
group, I am hoping that I can use MongoDB to use one collection with
varying document details depending upon the group(s) people are members of."

This is a perfect use case for MongoDb and should work quite well for you
here :)
Post by Sam Millman
The scenario of facebook was nothing to do with their DB, it was actually
to do with their policy.
They were an incredably simple site and they saw modification of content
as complexity, uneeded complexity. They have not changed DB nor DB
structure for your data (except using Cassandra for small things like inbox
search).
Rarely does a site always stay read heavy or write heavy, however a lot of
time it is read heavy (about 80% read). But you will need to counter for
both if you were to ask me personally on the matter. Your schema (unless
dead set on a particular op pattern) should cater part in part for both
reads and writes.
Post by aliane abdelouahab
before designing your schema, think about: will your application be
heavy wright, or heavy read.
i give you an example, this group, because google uses a nosql
solution, you can't update your answer, you can only delete it or add
a new one ;)
or think about facebook in the past, they dident allow to modify your
comment, only deleting it.
hope this example make sense for your design ;)
Post by AverageJoe
Thank you for the response. I guess I'm going to have to fumble my way
through to find the BEST way to use this.
My primary reason for seeking out a NoSQL tool is because I'm designing
something for a client where each user can be a member of one or more
groups within their organization, and each group may have it own,
different
Post by AverageJoe
descriptive fields. Instead of custom coding a new table for every
type of
Post by AverageJoe
group, I am hoping that I can use MongoDB to use one collection with
varying document details depending upon the group(s) people are members
of.
Post by AverageJoe
Post by AverageJoe
How would I properly represent this simple 3 table structure in
MongoDB?
Post by AverageJoe
Post by AverageJoe
Post by AverageJoe
customers
..
events
Post by AverageJoe
..
registrations
Post by AverageJoe
..
That's seems very relational to me...I would also need another query
to
Post by AverageJoe
Post by AverageJoe
Post by AverageJoe
determine the event date and location
Hi,
Unlike relational databases where some form of normalization might be
considered "proper" .. data modelling in MongoDB is driven by your
application requirements and common use cases for updating and
querying the
Post by AverageJoe
Post by AverageJoe
data. The MongoDB data modelling approach is much more akin to that
of a
Post by AverageJoe
Post by AverageJoe
data warehouse where you may choose to denormalize data to make
queries
Post by AverageJoe
Post by AverageJoe
more efficient.
In your example of customers, events, and registrations you could
choose
Post by AverageJoe
Post by AverageJoe
- customers as a collection
- events as a collection embedding registrations; registrations could
include a cust_id field which would be the related _id in the
`customers`
Post by AverageJoe
Post by AverageJoe
collection
With this approach, customers could register for multiple events and
their
Post by AverageJoe
Post by AverageJoe
full details would only be saved once in the customers collection.
However
Post by AverageJoe
Post by AverageJoe
.. if you wanted to find a list of all customer details for a given
event
Post by AverageJoe
Post by AverageJoe
you would have to perform multiple queries (one for the event and
then one
Post by AverageJoe
Post by AverageJoe
for each customer who registered for that event). Some MongoDB
language
Post by AverageJoe
Post by AverageJoe
drivers have helpers to perform the additional queries using the
convention
Post by AverageJoe
Post by AverageJoe
of a Database Reference (DBRef) .. but this still translates to
multiple
Post by AverageJoe
Post by AverageJoe
queries for the mongod server.
If customers are unlikely to change their details often (first name
and
Post by AverageJoe
Post by AverageJoe
- events as a collection embedding registrations (which include
customer
Post by AverageJoe
Post by AverageJoe
details)
In this case you could efficiently query the data .. at the slight
expense
Post by AverageJoe
Post by AverageJoe
of some duplication of customer's details (first name, last name).
The
Post by AverageJoe
Post by AverageJoe
tradeoff is query efficiency versus extra cost in updates should the
customers first/last name need to be changed in future.
The information and presentations linked from the schema design page
http://www.mongodb.org/display/DOCS/Schema+Design
https://openshift.redhat.com/community/blogs/designing-mongodb-schema.
..
Post by AverageJoe
Post by AverageJoe
Cheers,
Stephen
--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To unsubscribe from this group, send email to
See also the IRC channel -- freenode.net#mongodb
--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongodb-user-/***@public.gmane.org
To unsubscribe from this group, send email to
mongodb-user+unsubscribe-/***@public.gmane.org
See also the IRC channel -- freenode.net#mongodb
Russell Bateman
2012-09-09 22:17:47 UTC
Permalink
This is exactly my own case and why I chose MongoDB. It has not
disappointed.
Post by Sam Millman
"My primary reason for seeking out a NoSQL tool is because I'm
designing something for a client where each user can be a member of
one or more groups within their organization, and each group may have
it own, different descriptive fields. Instead of custom coding a new
table for every type of group, I am hoping that I can use MongoDB to
use one collection with varying document details depending upon the
group(s) people are members of."
This is a perfect use case for MongoDb and should work quite well for
you here :)
The scenario of facebook was nothing to do with their DB, it was
actually to do with their policy.
They were an incredably simple site and they saw modification of
content as complexity, uneeded complexity. They have not changed
DB nor DB structure for your data (except using Cassandra for
small things like inbox search).
Rarely does a site always stay read heavy or write heavy, however
a lot of time it is read heavy (about 80% read). But you will need
to counter for both if you were to ask me personally on the
matter. Your schema (unless dead set on a particular op pattern)
should cater part in part for both reads and writes.
On 9 September 2012 20:29, aliane abdelouahab
before designing your schema, think about: will your
application be
heavy wright, or heavy read.
i give you an example, this group, because google uses a nosql
solution, you can't update your answer, you can only delete it or add
a new one ;)
or think about facebook in the past, they dident allow to modify your
comment, only deleting it.
hope this example make sense for your design ;)
Post by AverageJoe
Thank you for the response. I guess I'm going to have to
fumble my way
Post by AverageJoe
through to find the BEST way to use this.
My primary reason for seeking out a NoSQL tool is because
I'm designing
Post by AverageJoe
something for a client where each user can be a member of
one or more
Post by AverageJoe
groups within their organization, and each group may have it
own, different
Post by AverageJoe
descriptive fields. Instead of custom coding a new table
for every type of
Post by AverageJoe
group, I am hoping that I can use MongoDB to use one
collection with
Post by AverageJoe
varying document details depending upon the group(s) people
are members of.
Post by AverageJoe
On Sunday, September 9, 2012 9:20:57 AM UTC-4, Stephen
Post by AverageJoe
How would I properly represent this simple 3 table
structure in MongoDB?
Post by AverageJoe
Post by AverageJoe
Post by AverageJoe
customers
..
events
Post by AverageJoe
..
registrations
Post by AverageJoe
..
That's seems very relational to me...I would also need
another query to
Post by AverageJoe
Post by AverageJoe
Post by AverageJoe
determine the event date and location
Hi,
Unlike relational databases where some form of
normalization might be
Post by AverageJoe
Post by AverageJoe
considered "proper" .. data modelling in MongoDB is driven
by your
Post by AverageJoe
Post by AverageJoe
application requirements and common use cases for updating
and querying the
Post by AverageJoe
Post by AverageJoe
data. The MongoDB data modelling approach is much more
akin to that of a
Post by AverageJoe
Post by AverageJoe
data warehouse where you may choose to denormalize data to
make queries
Post by AverageJoe
Post by AverageJoe
more efficient.
In your example of customers, events, and registrations
you could choose
Post by AverageJoe
Post by AverageJoe
- customers as a collection
- events as a collection embedding registrations;
registrations could
Post by AverageJoe
Post by AverageJoe
include a cust_id field which would be the related _id in
the `customers`
Post by AverageJoe
Post by AverageJoe
collection
With this approach, customers could register for multiple
events and their
Post by AverageJoe
Post by AverageJoe
full details would only be saved once in the customers
collection. However
Post by AverageJoe
Post by AverageJoe
.. if you wanted to find a list of all customer details
for a given event
Post by AverageJoe
Post by AverageJoe
you would have to perform multiple queries (one for the
event and then one
Post by AverageJoe
Post by AverageJoe
for each customer who registered for that event). Some
MongoDB language
Post by AverageJoe
Post by AverageJoe
drivers have helpers to perform the additional queries
using the convention
Post by AverageJoe
Post by AverageJoe
of a Database Reference (DBRef) .. but this still
translates to multiple
Post by AverageJoe
Post by AverageJoe
queries for the mongod server.
If customers are unlikely to change their details often
(first name and
Post by AverageJoe
Post by AverageJoe
last name in your example), you could also decide to
- events as a collection embedding registrations (which
include customer
Post by AverageJoe
Post by AverageJoe
details)
In this case you could efficiently query the data .. at
the slight expense
Post by AverageJoe
Post by AverageJoe
of some duplication of customer's details (first name,
last name). The
Post by AverageJoe
Post by AverageJoe
tradeoff is query efficiency versus extra cost in updates
should the
Post by AverageJoe
Post by AverageJoe
customers first/last name need to be changed in future.
The information and presentations linked from the schema
design page
Post by AverageJoe
Post by AverageJoe
http://www.mongodb.org/display/DOCS/Schema+Design
https://openshift.redhat.com/community/blogs/designing-mongodb-schema...
Post by AverageJoe
Cheers,
Stephen
--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to
To unsubscribe from this group, send email to
See also the IRC channel -- freenode.net#mongodb
<http://freenode.net#mongodb>
--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To unsubscribe from this group, send email to
See also the IRC channel -- freenode.net#mongodb
--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongodb-user-/***@public.gmane.org
To unsubscribe from this group, send email to
mongodb-user+unsubscribe-/***@public.gmane.org
See also the IRC channel -- freenode.net#mongodb
aliane abdelouahab
2012-09-09 21:15:12 UTC
Permalink
thank you for clarification :D
i thought because they were using Read-Many, Right-Once, so it was not
a good idea to let users update.
and about the schema, am designing e-commerce application that will
not let users modify their contents (policy, because someone can lie,
put a price, then modify it, since it's a C2C so no B2C services like
discounts), this is why, i'm using one single document to handle
everything:
-the user information (email, pseudo...)
--then comes a sub document of the uploaded product.
---then comes a subdocument of comments about that product by users
--then its cart in the same hierarchie than the uploaded product.
the only modification donce, is to add or remove a product, and in the
product there is a value that is incremented to see if users complain
about it.
Post by Sam Millman
The scenario of facebook was nothing to do with their DB, it was actually
to do with their policy.
They were an incredably simple site and they saw modification of content as
complexity, uneeded complexity. They have not changed DB nor DB structure
for your data (except using Cassandra for small things like inbox search).
Rarely does a site always stay read heavy or write heavy, however a lot of
time it is read heavy (about 80% read). But you will need to counter for
both if you were to ask me personally on the matter. Your schema (unless
dead set on a particular op pattern) should cater part in part for both
reads and writes.
Post by aliane abdelouahab
before designing your schema, think about: will your application be
heavy wright, or heavy read.
i give you an example, this group, because google uses a nosql
solution, you can't update your answer, you can only delete it or add
a new one ;)
or think about facebook in the past, they dident allow to modify your
comment, only deleting it.
hope this example make sense for your design ;)
Thank you for the response.  I guess I'm going to have to fumble my way
through to find the BEST way to use this.
My primary reason for seeking out a NoSQL tool is because I'm designing
something for a client where each user can be a member of one or more
groups within their organization, and each group may have it own,
different
descriptive fields.  Instead of custom coding a new table for every type
of
group, I am hoping that I can use MongoDB to use one collection with
varying document details depending upon the group(s) people are members
of.
Post by AverageJoe
How would I properly represent this simple 3 table structure in
MongoDB?
Post by AverageJoe
Post by AverageJoe
customers
..
events
Post by AverageJoe
..
registrations
Post by AverageJoe
..
That's seems very relational to me...I would also need another query
to
Post by AverageJoe
Post by AverageJoe
determine the event date and location
Hi,
Unlike relational databases where some form of normalization might be
considered "proper" .. data modelling in MongoDB is driven by your
application requirements and common use cases for updating and
querying the
Post by AverageJoe
data.  The MongoDB data modelling approach is much more akin to that
of a
Post by AverageJoe
data warehouse where you may choose to denormalize data to make queries
more efficient.
In your example of customers, events, and registrations you could
choose
Post by AverageJoe
 - customers as a collection
 - events as a collection embedding registrations; registrations could
include a cust_id field which would be the related _id in the
`customers`
Post by AverageJoe
collection
With this approach, customers could register for multiple events and
their
Post by AverageJoe
full details would only be saved once in the customers collection.
 However
Post by AverageJoe
.. if you wanted to find a list of all customer details for a given
event
Post by AverageJoe
you would have to perform multiple queries (one for the event and then
one
Post by AverageJoe
for each customer who registered for that event).  Some MongoDB
language
Post by AverageJoe
drivers have helpers to perform the additional queries using the
convention
Post by AverageJoe
of a Database Reference (DBRef) .. but this still translates to
multiple
Post by AverageJoe
queries for the mongod server.
If customers are unlikely to change their details often (first name and
 - events as a collection embedding registrations (which include
customer
Post by AverageJoe
details)
In this case you could efficiently query the data .. at the slight
expense
Post by AverageJoe
of some duplication of customer's details (first name, last name).  The
tradeoff is query efficiency versus extra cost in updates should the
customers first/last name need to be changed in future.
The information and presentations linked from the schema design page
   http://www.mongodb.org/display/DOCS/Schema+Design
https://openshift.redhat.com/community/blogs/designing-mongodb-schema.
..
Post by AverageJoe
Cheers,
Stephen
--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To unsubscribe from this group, send email to
See also the IRC channel -- freenode.net#mongodb
--
You received this message because you are subscribed to the Google
Groups "mongodb-user" group.
To post to this group, send email to mongodb-user-/***@public.gmane.org
To unsubscribe from this group, send email to
mongodb-user+unsubscribe-/***@public.gmane.org
See also the IRC channel -- freenode.net#mongodb
Continue reading on narkive:
Loading...