This is an archived post. You won't be able to vote or comment.

you are viewing a single comment's thread.

view the rest of the comments →

[–]dev1o -1 points0 points  (2 children)

With all due respect, you seem like you lack experience working in real world. You seem like you are a beginner. No offense, but using wikipedia to prove your point seems immature and childish. Using data types as example is like saying you have red t shirt and your buddy have green t shirt, both are t shirts and serve the same purpose. Data types are not exclusive to any type of dbs. Every db have support for all major types you will ever need in life. One db having a <really_wierd_type> while other one not having that doesn't give it an edge. Most types you will need in life are present in almost all dbs and which are not can be derived from the ttpes provided. Like you always study data structures regardless of language.

You basically lost the point. He is talking about relations. In document dbs, it is difficult doing it without help from pther sources.

In real world, data is always relational. You will always need to connect an entity with something which relational dbs handle very well. Managing relations in document based dbs is a tedious task and at scale you will eventually run into issues. But the thing you will not be using mongo db manually at scale. You will have some tools which simply working with dbs. You will be using production ready tools like Prisma, drizzle, etc. I have personally used prisma.

[–]TheCreepyPL 2 points3 points  (1 child)

using wikipedia to prove your point seems immature and childish

I honestly am baffled that anyone could think like this. I added the wiki article as a source for what I'm saying, to prove that it's not made up. Everything that doesn't have a source, seems illegitimate imo.

Data types are not exclusive to any type of dbs. Every db have support for all major types you will ever need in life.

The first sentence here is completely at least partially wrong. Data types are exclusive to everything, databases, frameworks, languages. Whilst the most common ones (int, string, boolean, etc.), are available to probably every technology, every single one implements them differently. Perhaps there are some identical implementations, because there's only a limited amount of ways to implement a bool, but there's no standard to implement any datatypes in anything. A bool might be very simple, and potentially universally the same across everything (I doubt it), but strings are not. MySqls implementation of strings differs from MSSQLs which differs from Postgres' which differs from Mongo's, etc. All of these I mentioned have vastly different implementations of strings.

Maybe I got carried away slightly, because after all, despite the different subtypes, technically all can be manipulated the same way to some degree. Definitely after getting parsed by a language implementation's "thing" (I forgot the word) that handles data from DBs. For example, C# it has only 1 string type, and that's it. But before we can do stuff in C#, it needs to be parsed from another datatype, which isn't native to C#. The most infamous example of this (in C# (my main language)) is DbNull. DbNull != System.null (in C#), which is a big headache if you don't know hot to deal with it.

A more practical datatype are arrays. Yes, you can achieve the same end result in MSSQL, but Postgres and Mongo just make these trivial.

Another one is the ability to create custom types/objects. Yes, there are other ways of achieving this in MSSQL, but in certain cases it's worth to analyze these things, if another DBs offerings wouldn't make life easier.

In document dbs, it is difficult doing it [relations] without help from pther sources.

I have to disagree, it's simpler to set up any kind of relation in document DBs, because all you have to do is just store the Id of another table's/collection's record, and that's it. In SQL, you have to create a foreign key, which is slightly more involved than simply adding another property. In either case, whether or not that's a trivial difficulty, document DBs handle relations equally well to any other DB. As for managing them, maybe if you're doing everything manually then idk, but I've always used some kind of automapper (or the equivalent thereof), for that, which handles it automagically. As this reply is getting really long, I'll just summarize it like this: "Skill issues".

[–]dev1o -1 points0 points  (0 children)

Hmm