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 7 years ago.
Improve this question
I'm not asking what a relational database is. I'm asking what relational data is. What makes data relational? What are some examples of relational data and of non-relational data that illustrate the difference?
Edit: I now understand that there isn't anything "relational" about the data itself, and that there are advantages to representing certain data sets relationally.
Even if the question is malformed, I think that a lot of other people might have the same question, want to know the answer, google it etc. So I think it'd be useful if they come across this.
"Relational data" is poor terminology used to indicate that the data is managed by a "relational" DBMS. "relational" is not a characteristic of the data per se and so the term per se is, essentially, a hopeless misnomer. If you hear someone use it, take it as a serious indicator/alarm that the person in question actually doesn't have a clue.
Also note that truly relational DBMS's actually do not exist (not in the industrial scene) and the closest approximation to a "relational" DBMS is SQL DBMS's like DB2, Oracle, SQL Server, PostgreSQL, ... but that "approximation" is a quite distant one.
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
Is there any disadvantages using graphical query building tools, such as MS Access or Toadfor Mysql for creating queries for databases?
Graphical query tools can make complicated databases seem simpler, and can make working with a joins a little easier.
However...
If you don't really understand what you're trying to achieve, or how the schema works, they will often give you incorrect results without you noticing. For instance, a common problem is the "cartesian join", where you haven't limited the conditions for the join sufficiently. In "raw" SQL, you'll notice very quickly that you get far more results than you expect; in a nice GUI, with limited screen space for query results, that might not be so obvious.
If the schema isn't "clean", with explicit primary and foreign keys, the visual tools often have to guess at how the schema is supposed to work, and which tables join to which others. This may make it easy to create queries that look sensible, but are really just nonsense.
Personally, I found that once I got more than a couple of joins into a query, it was just easier to work in raw SQL than using the visual tools. I'd also suggest that if SQL is a significant part of your job, you'll benefit from learning the language directly.
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 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
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.