0

I've been spending a considerable amount of time learning MongoDB as part of the MEAN stack (I'm new to the MEAN stack), and I feel like I'm just barely starting to get the hang of it. Recently, however, my supervisor at work (who's an experienced programmer) suggested I learn relational databases (it could be that it's used by more companies), and I have taken his suggestion to heart since I'm only a junior developer, and would like to move up soon. My personal goal/project is to build a social networking site where one group of users have the ability to search for another group of users (and most likely charge a membership fee). Would the database matter for a project like this? I would love to kill two birds with one stone by learning something (and learning it really well) that could be used in my personal project, and in a professional job.

I'm certainly open to learning more than one language, but I need a starting point, so I need something that will help me accomplish my personal goal. Since I've spent a considerable amount of time with JavaScript (as oppose to, say, Python), having to learn relational databases concerns me. Are there any downsides to just sticking to MongoDB?

Thanks in advance!

Community
  • 1
  • 1
Farid
  • 1,557
  • 2
  • 21
  • 35
  • Rule of thumb: writing to NoSQL is fast and cheap, while querying is expensive; writing to SQL is expensive, but reading can be cheap. – Tim Biegeleisen Nov 06 '16 at 06:44
  • @Tim_Biegeleisen I'm more on the SQL side, but it is the first time I hear about "expensive querying" for NoSQL. Is this a "general statement" or you had in mind some specific use case (e.g. "when your query is complex/needs info from different entities to be answered") – Insac Nov 06 '16 at 06:54
  • If you are interested in the SQL vs NoSQL, this question has some good answers and pointers (http://stackoverflow.com/q/2559411/5077154). Note also that the question has been closed as mainly opinion based (as, I am afraid, this question is) – Insac Nov 06 '16 at 10:31
  • Thank you all for your feedback! It's greatly appreciated. It sounds like one approach is what @FDavidov said below: do I want structure data, or non-structured? The example I used with the tutoring site is what I'm shooting for. – Farid Nov 07 '16 at 04:55

3 Answers3

2

The first thing you need is to assess what type of data you are going to deal with (will it be structured, easily represented by tables, or it will be more of the non-structured type).

If structured, RDBMS is the way to go.

Incidentally, as far as I know, the first versions of Facebook were implemented using MySQL (the type of DBMS your boss was referring to).

FDavidov
  • 3,505
  • 6
  • 23
  • 59
  • Thanks for the feedback! Admittedly, I don't know what type of data I'm going to deal with, which probably doesn't help my case. I'm new to all this, so I'm still trying to find my bearings. I know what I'm trying to accomplish, but I don't know what tools I need. Maybe this will help: think of tutoring sites where you have two groups of users: the tutors, and the students. Each group has a membership profile on your site, and they should have the ability to search for each other, and send messages. I don't know if that's considered structured data, or non-structured. – Farid Nov 07 '16 at 04:47
  • What I'd suggest you to do is to sit down with a piece of paper and a pencil. Then imagine you have a working system that receives EVENTS (from users, like sending messages as you mention), what the structure of these events may be (for instance, the list of fields you would like to keep each time a message is exchanged). Once you have this for all the events you need, check if you recognize a **COMMON and REPETITIVE PATTERN**. If you do, MySQL is the direction. Hope this helps. Good luck!! – FDavidov Nov 09 '16 at 06:12
1

Farid, as you're a junior programmer, I'd suggest you to learn as much as possible of both approach.

The knowledge acquired on one of them will also help you getting the most from the other (as they both concern data, how to structure it and how to query it).

Also, in the day by day job (unless you specialize only in large sites where scalability is the first concern) you might encounter RDBMS more frequently than NoSQL choices.

Both technologies have pro and cons and, unless you know both sides (at least documenting yourself, if not by direct experience) you might go for one solution when the other could have been preferable.

Insac
  • 800
  • 5
  • 18
  • The main question here is base on what are you searching for a group of users. This will determine the technical solution. – David דודו Markovitz Nov 06 '16 at 08:33
  • You're right in that knowledge of one will help with understanding the other. I have only begun my dive into databases, but I'm already beginning to see the similarities. I suppose that my biggest worry is wasting time. Then again, I'm a total newbie to all this, so maybe I shouldn't worry so much about "wasting time". – Farid Nov 07 '16 at 04:44
1

Well, anyone have concern about learn SQL (and use JOIN), but:
One day, you don't know how, you will use it (or understand it), so perhaps is better take a moment for SQL (it's the most widespread)

MongoDB is good if you development a REST service, but if you want make a social network like project, perhaps is better look at Graph database.


Perhaps that video can help, is an overview of SQL vs NoSQL.

Paolo bi
  • 141
  • 2
  • 10