So for the job at hand, what do you suggest? Mysql or graph? On Saturday, 14 September 2013 00:04:18 UTC+5:30, Josh Jordan wrote: > > 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. > > On Friday, September 13, 2013 10:29:24 AM UTC-4, Yash Ladia wrote: >> >> 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? >> >> On Friday, 13 September 2013 14:46:32 UTC+5:30, Peter Hickman wrote: >>> >>> On 12 September 2013 16:44, Yash Ladia <ladi...@gmail.com> 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. >>> >>
-- You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" group. To unsubscribe from this group and stop receiving emails from it, send an email to rubyonrails-talk+unsubscr...@googlegroups.com. To post to this group, send email to rubyonrails-talk@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/rubyonrails-talk/ebf3a586-8c02-4154-9c16-22ac5f7d695d%40googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
