Having some issues on backend regarding a social networking project on ROR

I am working on a social networking project. I need to store about 10-15
user profile information like movies,music,books,relationship-status and
so
on. I am confused about which database should i use to store user
profile
info. There are NOSQL solutions like MONGODB as well as Neo4j(graph). Or
should i store it in relational database like mysql. Needless to say,
but
the solution should be scalable and efficient. Any guidance on this
would
be of great help.

The information would seem to fit a RDMS perfectly. But then as you have
not given us any idea as to how simple or complex you expect this data
to
be no one can tell. Tell us what the data is like and we will be able to
give you a better answer.

Thanx for your reply.My problem is that at a later point of time this
would
account for very large data set as the users will increase. I want to
optimize my website and want to save time on data query from the
database.Also, i will be looking for similar user profile based on
user’s
attribute like(taste in music,movies,interests etc).I want this to be
done
very efficiently and in a proper manner so that there is less complexity
in
writing the code.

Thanx for your reply.My problem is that at a later point of time this
would
account for very large data set as the users will increase. I want to
optimize my website and want to save time on data query from the
database.Also, i will be looking for similar user profile based on
user’s
attribute like(taste in music,movies,interests etc).I want this to be
done
very efficiently and in a proper manner so that there is less complexity
in
writing the code.

I would suggest MongoDB is a right choice…

On 12 September 2013 16:44, Yash L. [email protected] wrote:

Thanx for your reply.My problem is that at a later point of time this
would account for very large data set as the users will increase. I want to
optimize my website and want to save time on data query from the
database.Also, i will be looking for similar user profile based on user’s
attribute like(taste in music,movies,interests etc).I want this to be done
very efficiently and in a proper manner so that there is less complexity in
writing the code.

Having a large amount of simple data is not the same problem as having
complex data. If all you are storing is key value pairs you could have a
table like this

class Interest < ActiveRecord::Migration
def change
create_table :interests do |t|
t.integer :user_id, :null => false
t.string :type, :null => false
t.string :value, :null => false
t.timestamps
end
end
end

And you would store it as:

Interest.create(:user_id => user.id, :type => ‘music’, :value => ‘Status
Quo’)
Interest.create(:user_id => user.id, :type => ‘movie’, :value => ‘The
Color
Purple’)
Interest.create(:user_id => user.id, :type => ‘hobby’, :value =>
‘Fishing’)
Interest.create(:user_id => user.id, :type => ‘food’, :value =>
‘Cheese’)

and have a has_many link from the User model to retrieve the data. This
sort of data is exactly what an RDBMS is best suited for. Of course if
it
is just key value pairs then something like Redis is also a good tool
too.

MongoDBs strength is document storage for unstructured data. The problem
is
that the data you have is neither a document nor unstructured. This is
not
to say that you cannot store key value pairs in MongoDB but it is not
the
best tool for the problem you describe.

I think the User->HasOne->Profile association will be OK. From there
you
can go searching for more efficient database calls.

Don’t fool yourself into thinking that Facebook is using a single data
store. Facebook has a massive set of resources Remember that they have
their own PHP compiler.

They are most certainly using multiple data stores redundantly and
querying
the right one for the job at hand for each particular piece of
functionality.

Ok I got your point behind not using Mongodb. But the project is similar
to
facebook and facebook uses graph. So, what advantage can one get by
using
graph. And why shouldn’t I use graph for this project. In this project,
users will post status updates too and those updates will have tags. So
think of a share model that has like 5 tags. So, should I create a tag
model and then a share has many tags, or is there a better solution?

So for the job at hand, what do you suggest? Mysql or graph?

So for the job at hand, what do you suggest? Mysql or graph?