Still trying to get good.

The requirements are forever shifting, and so do the applied paradigms.

I think the first layer is learning about each paradigm.

You learn 5-10 languages/technologies, get a feeling for procedural/functional/OOP programming. You mess around with some electronics engineering, write a bit of assembly. You write an ugly GTK program, an Android todo app, check how OpenGL works. You learn about relational models, about graph databases, time series storage and key value caches. You learn about networking and protocols. You void the warranty of all the devices in your house at some point. You develop preferences for languages and systems. For certain periods of time, you even become an insufferable fanboy who claims that all databases should be replaced by MongoDB, or all applications should be written in C# -- no exceptions in your mind are possible, because you found the Perfect Thing. Temporarily.

Eventually, you get to the second layer: Instead of being a champion for a single cause, you start to see patterns of applicability.

You might have grown to prefer serverless microservice architectures driven by pub/sub event busses, but realize that some MVC framework is probably more suitable for a 5-employee company. You realize that development is not just about picking the best language and best architecture -- It's about pros and cons for every situation. You start to value consistency over hard rules. You realize that even respected books about computer science can sometimes contain lies -- or represent solutions which are only applicable to "spherical cows in a vacuum".

Then you get to the third layer: Which is about orchestrating migrations between paradigms without creating a bigger mess.

Your company started with a tiny MVC webshop written in PHP. There are now 300 employees and a few million lines of code, the framework more often gets in the way than it helps, the database is terribly strained. Big rewrite? Gradual refactor? Introduce new languages within the company or stick with what people know? Educate people about paradigms which might be more suitable, but which will feel unfamiliar? What leads to a better product, someone who is experienced with PHP, or someone just learning to use Typescript?

All that theoretical knowledge about superior paradigms won't help you now -- No clean slates! You have to build a skyscraper city to replace a swamp village while keeping the economy running, together with builders who have no clue what concrete even looks like. You might think "I'll throw my superior engineering against this, no harm done if it doesn't stick", but 9 out of 10 times that will just end in a mix of concrete rubble, corpses and mud.

I think I'm somewhere between 2 and 3.

I think I have most of the important knowledge about a wide array of languages, technologies and architectures.

I think I know how to come to a conclusion about what to use in which scenario -- most of the time.

But dealing with a giant legacy mess, transforming things into something better, without creating an ugly amalgamation of old and new systems blended together into an even bigger abomination? Nah, I don't think I'm fully there yet.

a dude just DROPPED the whole Fu**ing mongodb cluster. like Right Now.

multiple databases, expanding multiple projects.

fortunately in dev. but dunno how much data is recoverable.

MongoDB: Snapchat for databases.

Client reads about MomgoDB ransomware attacks online.

Him: I heard that the MongoDB is not secure, we should use something else in our system.
Me: Those databases got attacked because security features were turned off. If you want you can have an external security team to test the system when it's done.
Him: I don't wana take any risk, so I we should use something else.

We have been working on this system for almost a year and the final stage was supposed to be delivered in a month.

He wants me to replace it with MySQL

TLDR - you shouldn't expect common sense from idiots who have access to databases.

I joined a startup recently. I know startups are not known for their stable architecture, but this was next level stuff.
There is one prod mongodb server.
The db has 300 collections.
200 of those 300 collections are backups/test collections.
25 collections are used to store LOGS!! They decided to store millions of logs in a nosql db because setting up a mysql server requires effort, why do that when you've already set up mongodb. Lol 😂
Each field is indexed separately in the log.
1 collection is of 2 tb and has more than 1 billion records.
Out of the 1 billion records, 1 million records are required, the rest are obsolete. Each field has an index. Apparently the asshole DBA never knew there's something called capped collection or partial indexes.

Trying to get approval to clean up the db since 3 months, but fucking bureaucracy. Extremely high server costs plus every week the db goes down since some idiot runs a query on this mammoth collection. There's one single set of credentials for everything. Everyone from applications to interns use the same creds.
And the asshole DBA left, making me in charge of handling this shit now. I am trying to fix this but am stuck to get approval from business management. Devs like these make me feel sad that they have zero respect for their work and inability to listen to people trying to improve the system.

Going to leave this place really soon. No point in working somewhere where you are expected to show up for 8 hours, irrespective of whether you even switch on your laptop.
Wish me luck folks.

Has anyone here used MongoDB for relational databases? I am trying to use MySQL with Node but I feel like the whole thing is a mess. There are some ORMs like Knex or Sequelize for MySQL but they are pretty crap. I am thinking if I should just move onto MongoDB instead of MySQL, at the same time I feel a little dirty to store relational data in a document store :(

so if i get this correctly :

1. mongodb( community server) is going to create some files in my system which will be called "databases/collections/document bullshit via its own special process called mongod (similar to mysql , but ok)

2. my python flask app is going to connect to it via its official driver pymongo (which could be used directly)
3. mongoengine is a library (more of a wrapper on pymongo) providing "easy ways for connecting mongodb via pymongo" (which again could be used directly)

4. flask-mongoengine is library (more of a wrapper on mongoengine providing "easy ways for connecting mongodb via mongoengine via pymongo" (which again could be used directly)

5. flask-pymongo is some another bullshit library/wrapper that took away 6hours of mine which again is "A FUCKING WRAPPER PROVIDING EASY WAYS FOR CONNECTING TO MONGODB VIA PYMONGO"

seriously, fuck web development. Why can't the original driver (i.e pymongo from mongodb devs) could have simpler wrappers? and why does my fucking tutorial instructor had to use the most fucking rarely used flask-mongoengine (which i accidently read as flask-pymongo and got f**ked) to teach newbies? fucking day wasted trying to understand this crap.

I don't like monnopolies, but its somewhat good that the mobile environment is still in the hands of nononsense players like google and oracle(java) . atleast we don't have people releasing wrapper over wrapper over wrapper and then fighting about which wrapper is better to use.
Like , even when devs started cmplaining that android dbs are too difficult to understand, google themselves created an actively supported wrapper that shutted down the fight over which wrapper to use(sqldelight, realm,sql bright etc)

I remember back then when we were building an E-commerce website. To maintain good performance the boss insisted using flat table. This was also applied to other projects like GPS. That was already 2013 when NoSQL databases like MongoDB was around already. His concern is he didn't like to risk on new technologies and it would cost money for training instead of using the existing "MySQL" and Microsoft SQL Server.
Everything I learned from that guy was just poop.

What is the purpose of using MongoDB and then adding mongoose?
If you want schemas, relations and all the jazz mongoose offers, have you considered using a RDBMS instead of a datapile system? Most (probably all) SQL databases support schemas, relations and all the jazz you seem to need.

So, ask yourself: Do you really need the functionality of a NoSQL database or do you just want it because it's shiny and new and "everybody uses it (tm)"?

The value proposition of MongoDB Is making people's life miserable.

Just spent all morning adding my own user account to my local MongoDB because some network security guy found I was running an unprotected server on my PC....

I tried all the admin roles to get full access across all databases I have but none worked....

Until I see one at the bottom of the official documentation:

root

!Rant

Which database program do you use? MySQL, MongoDB etc.
I'm using MySQL at the moment, but a lot of jobs requires MongoDB. Does anyone know why?

Though I can't get it to work on my dedicated server, giving up for now...

Working with nested arrays in MongoDb!! Who would have thought it would be such a pain to update data in nested arrays in a database! So frustrated!!!!

Another haveibeenpowned news story, why can't people set a password on their mongodb instance? Is it that hard or different from other databases?

Using DB triggers is something bad? I have started using NoSLQ databases (CouchDB and MongoDB) and I can't find anything intuitive or native to the BD.

The worse is that I have googled it and I rarely find people asking for triggers in NoSQL databases.

What am I missing? My concepts about RDBMS blind me about NoSQL?

How do you update deeply nested subdocument in mongoose?
Banging my head for a couple of days now!

I don't know what's up with MongoDB. It looks like a huge mess to me...

Me: Assigned to do some NoSQL injections test cases in December on Jira by product owner.

After asking him about it, he said it can be vague and it’s only for developers to get an idea. I also have this restriction where I can’t really keep actually data or databases in our test sample application, so I could only mock mongodb. Product owner says just mongo is fine.

I do it. Now it’s January, product owner away for a month we so director is managing it. She then schedules me to talk to database team. I show them the very simple test cases which essentially just inject payloads I found online into different parameters specified in test case. They say if that’s it. I say yes. They say what’s the point of this. I said that it’s probably to test your database clients and ensure they’re rejecting bad Malicious input? They then keep asking but I’m just the dev and tell them the product owner is away. Then the guy calls my test case essentially useless and the others agree. Then they tell me to do it for other databases which I can’t mock like couchbase even tho my PO said it’s fine for mongo only.

Am I just being silly here? I am pretty new to working in a dev environment so please feel free to be blunt.

BOYS, NEED HALP

Writing a web application, though NoSQL question.
One collection, or more?

People love to talk crap about MongoDB but it's not horrible for getting in to NoSql databases. Is it good for extremely important production apps? No, but nobody is saying it is.

Trying to make a nodejs backend is pure hell. It doesn't contain much builtin functionality in the first place and so you are forced to get a sea of smaller packages to make something that should be already baked in to happen. Momentjs and dayjs has thought nodejs devs nothing about the fact node runtime must not be as restrained as a browser js runtime. Now we are getting temporal api in browser js runtime and hopefully we can finally handle timezone hell without going insane. But this highlights the issue with node. Why wait for it to be included in js standard to finally be a thing. develop it beforehand. why are you beholden to Ecma standard. They write standards for web browser not node backend for god sake.

Also, authentication shouldn't be that complicated. I shouldn't be forced to create my own auth. In laravel scaffolding is already there and is asking you to get it going. In nodejs you have to get jwt working. I understand that you can get such scaffolding online with git clone but why? why express doesn't provide buildtin functions for authentication? Why for gods sake, you "npm install bcrypt"? I have to hash my own password before hand. I mean, realistically speaking nodejs is builtin with cryptography libraries. Hashmap literally uses hashing. Why can't it be builtin. I supposed any API needed auth. Instead I have to sign and verfiy my token and create middlewares for the job of making sure routes are protected.

I like the concept of bidirectional communication of node and the ugly thing, it's not impressive. any goddamn programming language used for web dev should realistically sustain two-way communication. It just a question of scaling, but if you have a backend that leverages usockets you can never go wrong. Because it's written in c. Just keep server running and sending data packets and responding to them, and don't finalize request and clean up after you serve it just keep waiting for new event.

Anyway, I hope out of this confused mess we call nodejs backend comes clean solutions just like Laravel came to clean the mess that was PHP backend back then.

Express is overrated by the way, and mongodb feels like a really ludicrous idea. we now need graphql in goddamn backend because of mongodb and it's cousins of nosql databases.