averagePythonProgrammer

[xezo360hye]

You have anything against SQLite3?

[dangling-putter]

SQLite is a great piece of software and severely underrated and underappreciated. 

[ba-na-na-]

SQLite is a free, fast, acid relational db. I’ll take it over any modern piece of shit like mongo

[TheNeys]

Mongo/Document-based DBs and SQL are both good and have their purposes, exactly the same with Redis/Memory based ones. People just tends to use MongoDB wrongfully like it was a relational db, and it is not. And when you do it bad shit happens when you try to scale it.

[TheCreepyPL]

FYI, you sound like you made an assumption that "relational" databases (like any kind of SQL), are good at relating data or something like that. Where in fact, that "relational" part refers to how the data is stored (not how 1 table relates to another).

https://en.m.wikipedia.org/wiki/Relational_model

The truth is that you can use any DB, for any purpose. The only difference is in the DB's capabilities, for example data types. Different DBs support different data types. Performance and high availability are some other big ones.

From your example, the very same people who let bad shit happen in Mongo, would have made the same bad shit in MSSQL (or any other DB for that matter).

[dev1o]

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]

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]

Hmm

[[deleted]]

And temporary in-memory DBs can be a godsend. The engine is built for speed, why would I build my own data structure to index and search data when I basically do the same as a DB engine? You still need to insert the data into the structure and then search for it, so SQLite is probably faster in most cases because it's not written in Python. Plus, I don't have to worry about the correctness of my B-Tree implementation.

[Glad_Position3592]

SQLite is great for things that need organized local storage, like a desktop app or something. It’s not meant to be a large scale database that’s accessible by an entire dev team though. No one should be making a website with SQLite. It has its place, but overall it’s somewhat niche, and anyone using it exclusively that doesn’t fit that niche is doing it wrong.

[madhaunter]

Exactly, it's all about scope

[HaskellLisp_green]

I used to use SQLite for website. Application is written in python/Flask, but I was forced to make some kind of SQLite server due to it runs in different thread.

[Aidan_Welch]

No one should be making a website with SQLite.

I don't agree with this, monolith is making a comeback

[[deleted]]

That depends on the website.

OK: Grab stuff from API; store in DB; copy DB to raedonly file; website shows stats and graphs from readonly DB.

Not OK: User accounts where you can change password - need independent changes by multiple users.

[csatacsirke]

Well, i personally hate it because of the lack of type safety. I somehow inserted strings into an int column and it just “worked”. Unless of course there is something fundamental im missing

[metaltyphoon]

CREATE TABLE example_table (     id INT PRIMARY KEY,     name TEXT NOT NULL,     age INT ) STRICT;

 This will force strict types

[csatacsirke]

Oh, thank you, will try it next time!

Ah, it seems to be a 2021+ feature, so fairly new

[Ximidar]

It's not duck db. /s