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.
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 4 years ago.
Improve this question
We're about to start developing a scheduling system and we're motivated to migrate from PHP to Node for the Backend, so it makes sense to also migrate from MySQL to MongoDB (or something similar), I'm not a very tech person, but I'm trying to help my team to make the choices here. All features of this system seem ok to be with either database, but one particular situation raised me concerns regarding performance:
Let's assume I have several doctors on my base, each one with their specialties and clinic locations and also with their time span to work on this system. They also already have some appointments scheduled for spread hours during the weeks.
One user fills the search form with:
Their geolocalization (x,y);
The search radius (ex.: 10miles);
Specialization needed (ex.: dermatologist);
Desired hour (ex.: 11am);
This search, for my old-school mindset, seems OK for a relational database, but a lot of work for non-relational, since their availability will be inside each doctor 'JSON', and not in a specific external 'table' for scheduling.
Do my concerns make any sense?
You can achieve the desired result with both SQL and NoSQL database. But the project you are talking about is more relational design. Example:- Doctor can visit multiple clinics. A patient has also related to the Clinic as well as the doctor. The best solution, in this case, is the hybrid approach where your primary database should be relational and for the reading operation, you can plug NoSQL database like MongoDB if required.
#Rafael Souza
You should go with Relational schema design.
If you use NoSQL then in our case below are the points I want to convey
NoSQL will not be utilized fully at its best.
Developers will have to learn NoSQL and its frameworks.
There is a vast forum for SQL problems compare to NOSQL.
Database storage size would not big so SQL should do good.
Here you need to manage the relationship between Doctor and Clinics which is best suitable in SQL.
I should say that don't go with the Hybrid approach as it will be overhead for your design, any database type is alone capable of handling all the features.
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 6 years ago.
Improve this question
So, imagine the situation, when we have such data: one part of it is better to store in RDBMS, and another one in some of NoSQL (Mongo, f.e.). Is it correct to use 2 separate DB? Or should I find a some compromise for data structure to use only one?
I guess, when we use 2 DB we need much more resources (and carry more about fault tolerance), but we can have better stucture. Or my way of thinking is totally wrong? Never heard about this kind of practice, so want to ask more experienced people.
Btw, sorry if my english is bad.
Using different dbms for different kind of data and purposes in the same application is definitely legit. It does come to some cost as you mentioned, but if the benefits outweigh the costs I would go for it.
A not so uncommon usecase would be to have a rdbms as persistent datastorage and add Lucene as fulltext search engine. So you can use the rdbms for your acid compliant operations, to enforce constraints.
In the next moment you can use lucene to search for some words, get the corresponding identifier and then ask the rdbms for more information belonging to the identifier.
If you check the 'more exotic' NoSQL databases (graph databases, column based databases) you propably will find more such usecases in which 2 dbms are great to supplement each other.
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 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.
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.