Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
Is it possible/reasonable to have a voting system on NoSQL database ?
For example how would be possible to store StackOverflow question into the NoSQL database.
I can easily imagine almost everything except how the relation will work between question/vote/user. Everything else can be stored in one document, like tags, comments(assuming there are relatively small amount of comments on posts, in my case I will not have comments anyway), user information, etc... but can't imagine how to store user votes as document will become huge. One of the options is that I can have votes stored in separate collection/document, but it will mean that while loading a question there will be a need to send another request to check if the user have voted for a question or not.
A good reference is the MongoDB documentation on Embedded documents vs Referenced documents, since those are what you seem to be referring into your question. There's no perfect solution, as both have their trade offs. You just have to make the best decision based on the type of operations/queries and their frequencies that you're expecting to be run on your database.
Honestly, until your database starts getting some serious traffic, the difference between SQL and NoSQL won't matter. Pre optimization can end up doing more harm than good, so I would just go with the one that is easiest to get deployed and you're more comfortable with to begin with.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I am thinking of storing persons contact data centrally. So there will be so many persons and each will have their contact list. There will be more number of updates and selects on database as user will be searching their contacts or searching for a person not in his/her contact list. Person may be updating their contact details. But inserts in database will be limited because only one time enrollment will be there. I am confused in using databases MySQL or Neo4j. Because when I think of searching person from database neo4j seems better. But when I think of handling millions of records MySQL seems better. So can anyone suggest which database suits best? MySQL/Neo4j/ both MySQL and Neo4j or some other database?
Neo4j allows you to store the connections between the people via their contacts, so if you want to leverage the network effect in your application it makes sense to look into that.
It all depends on how you want people to search and interact with your app. If treat people as individual records with no connections then MySQL is good enough. Otherwise Neo4j would probably work better.
IF you have the time to a tiny PoC with some realistic data with both and then decide for yourself.
you can use MySQL latest version it is quite simple and relevant to your need , you need to just use locking system on your database or you can lock your table when inserting or updating.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am developing a Real Time messaging application (such as WhatsApp and co) and I am facing a big question.
The application itself is not as complicated as what exists on the market. However, I am no sure what storage system I should use. I have several ideas but I don't know which one is better that the others:
A simple mysql database with relations between messages/conversations/conversations
A mongodb with replicate of each conversations for all users in the conversations
A redis store with replicate conversations for all users in the conversations.
I don't know which one is better for what I want to do. If you have some advise so I can choose the right solution. (or if there is a solution I haven't listed which is even better :) )
Note : My API is developped in Ruby On Rails (if this can help make a decision)
Data volume and number of read/writes should be the key factor leading you to the decision. If the data volume and number of read/write is not going to be huge you can do with mysql. I believe few TB of data with few hundreds of read/writes per minute is SQL database territory. Beyond that it is NoSQL world. However, you should be ready to deal with increased complexity of non-SQL data store design, query implementation, and achieving eventual consistency if you choose NoSQL solution. All the best!
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I have a project which is using NodeJS and I have different entities for example, people and places.
I need the ability to find both types of entities by location together so what I was thinking of doing is having an index on a field called, type, for example, which would be either person or place and make use geospatial indexes, does this sound a good way to do this or is there a better way?
I will probably need a lot of joins too, so should I use MySQL alongside MongoDB and use MongoDB just for delivering the location based queries?
Thanks
This question is a poor fit for stackoverflow, but here's some radom bullet points:
PostgreSQL supports both joins and geospatial. I'd pick that first personally lacking other details warranting a different data store.
A totally valid option would be to keep people and places separate and query multiple collections as necessary. However, if you need to sort the results, then yes best to throw them in the same collection.
You could also keep people and places in separate mongodb collections but have a mapreduce job translate them into a locations collection for search purposes.
Generally, there are lots of ways to do this and the best one depends very much on the specific aspects of you application. Reads vs writes, data stability, data size, query load, etc, etc.
My broad word of advice is start with the most logical, easiest-to-follow, straightforward data organization (separate collections), and deviate from that when you understand the specific pain you have and how doing something more complicated or unusual will be an overall win.
Closed. This question needs to be more focused. It is not currently accepting answers.
Want to improve this question? Update the question so it focuses on one problem only by editing this post.
Closed 9 years ago.
Improve this question
I'm creating a mobile app to access journal articles.
They are organized by Volume -> Issue -> Section -> Article. This means that I will have 13 * 4 * 10 * 3 = 1560 articles. What is a good way to implement a database to host these articles (including their images, resources, etc) on a web server? Each article is currently marked up in HTML. I believe this is nice, because in my apps I will display the content in a web view. However, I'll need to query the articles for search functions, saving locally to the device, etc.
I'd prefer it to be open source, and as I'm new to databases (but fairly proficient in app development), I'd appreciate if you could point me toward the best way of learning.
I'm not sure if you are looking for advice concerning the structure but this might help you as an approach for further thinking:
create a table in which you write all the data
You have one column with a unique ID for each article
one column for each field of Volume, issue etc.
Then you have one column that contains a huge string in which you put the html data as a string. (There might be a better way especially concerning a search function)
You can also save it as a BLOB but this makes indexing a lot harder.
I would probably save the resources separated from the database. Then you just name them after the article id. For example resource number 10 in article 5 would be 5.10.pdf or whatever format. This depends on your html format of course. And whether you want to rename all your files (might be A LOT of work for 1500 articles)
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
I am in the middle of attempting to help my company digitize their history. One project is taking maintenance records for equipment and putting them into a mysql database. The idea is to be able to pull up a history at any time without flipping through piles and piles of paper.
My experience is limited to using phpMyAdmin to create tables and fumbling through php to output data how I want it. I've never used a relational setup.
The data fields would always be the same, the database would be populated via copy/paste from Excel (until such time comma delimited importing can be figured out), and this data would not need to be edited by endusers. It is strictly for viewing/printing purposes only.
Example fields:
id, unit number, unit_type, date, maintenance_performed
My question is, would putting all this into one table be an acceptable way to accomplish this task? Or would a relational setup be better due to the different types of units? Why?
I would focus on getting the data into the database and not on its storage. You are going to have enough problems copy-and-pasting the data in. For instance, how will you ensure that the dates are always in a consistent format?
After the data is loaded into tables, then you can worry about how to optimize it for querying purposes. How will new records continue to be uploaded? That will be a very important part of the process (I would recommend having field a creation date in the database, in addition to other information in the record).
After the data is loaded, you can worry about the best structure for organizing it. This is analogous to a real archivist, who tends to start by gathering lots and lots of data, and then figuring out the best way to organize it.