It happened to me that you actually construct a relational schema with MongoDB. It is not good. You do not use the modeling benefits of MongoDB, and you do not have the benefits of SQL. So I recommend taking it into MySQL. Since you think in a relational way, it is best you move to MySQL

Specifically, do you need non-normalized data? If not, MySQL is best. Otherwise, MongoDB is best. If you think non-relational, you do not need joins, and the problems with cascade disappear.

What is the best way to think? If you work in terms of whole tree of related object, then you think non-relational and non-normalized.

It makes no sense if you use MongoDB primarily as a relational database. As you scale MongoDB will be more expensive than SQL and as you said without having the advantages of "join" etc.

We use MongoDB in our company. It is useful for us, as we work with different types of devices and we love the functionality of being able to add fields whenever we have a new device type etc. Mongo also allows enables easy scaling and fault tolerance. However, you will have to learn how to manage it.

If you are already comfortable with SQL and don't need NoSQL, stick to SQL. At scale, it is cheaper than Mongo.

Look if you are comfortable with firebase you can go with it, after all, It's all about development and running your program bug-free and fast, but firebase is costly fo long run and if you are comfortable with that cost then I suggest you go with it.

Hi!

I’m not an expert, but I can tell you some things:

• Firebase is a great option for a very simple to implement, fast and reliable authentication method. Nonetheless, the free authentications are limited, so if you will potentially have millions of monthly authentications, it’s probably best to take the time to build it into your app directly.
• MySQL is great for simple tables where the data structures are not too complex, but it lacks some speed when you are trying to retrieve time data series. Also, I believe it’s a bit more difficult to distribute.
• MongoDB is great when your information is a bit more complex and you need very peculiar data structures, nested data, dynamic structures, etc. For me at least, it’s a bit more complex to master than MySQL, but the freedom it gives you is incredible. It also performs super fast, especially with time data series, and if I’m not wrong, it’s more scalable.

In general, almost all technologies have their good things, it’s just a matter of what you want to do and then choosing the right ones.

Doing User authentication (oauth) and session management by ourself is kind a challenging, so if possible use firebase itself since it provides these features out of the box.

MySQL is still more popular than MongoDB if you look at Google Trends. I've also added MariaDB, which is pretty much a copy from MySQL and its features, and PostgreSQL, which is also a popular relational database.

This is a very good article for comparing MySQL to MongoDB and which one you should use: MongoDB vs MySQL: A Comparative Study on Databases.

If you just want to learn and you have the time, I would opt for using both MySQL and MongoDB. For example using MySQL for most of the site content and MongoDB for saving log messages. As you get more and more logs you start to see the benefits from MongoDB's faster document fetching.

There's really not an awful lot of difference between the two, they have wildly different storage mechanisms but they each have their fairly similar benefits. If you want to learn something that might be a requisite skill for a job, I would also look at alternatives such as time based and column based systems like InfluxDB and the unbelievably fast and flexible ClickHouse. While they may seem like an unlikely fit for a personal bug tracker app, there's no reason not to use them. Since I got into InfluxDB people have been requesting it a lot and I'll be using ClickHouse for all large databases, probably forever. Expand your horizons beyond your competition's.

What I have learned through several years of experience, is that by default you should consider SQL database (like PostgreSQL, MySQL, ...) and if does not suit you then you should explore other noSQL options.

SQL is very solid and it can do almost anything and can support almost any kind of systems.

So, for your case I would recommend that you go with SQL. You should start by listing your use cases and infer from them your entities and relations, and work on them in a Top-to-bottom manner, meaning that you should have some entities that are the core dependencies for the other entities. Or, in other words, they can exist without other entities existing, but the opposite is not true, these are your core entities that you should work on first, then gradually build the other entities.

One way to figure out the core entities is to follow how the users will behave in your system, what will the user create first, and what is dependant on other entities.

For example, in your case, on way to do it is to start with the "vault", as everything else cannot exist without it (and it's the first thing a user would create), then do passwords as they depend on the vaults (I would say passwords are "under" the vault), then once you do them, you can start working on tags then categories, and so on...

I agree with the advice you have been given to stick with SQL Server. If you are on the latest SQL Server version you can query inside the JSON field. You should set up a test database with a JSON field and try some queries. Once you understand it and can demonstrate it, show it to the other developers that are suggesting MongoDB. Once they see it working with their own eyes they may drop their position of Mongo over SQL. I would only seriously consider MongoDB if there was no other SQL requirements. I wouldn't do both. I'd be all SQL or all Mongo.

I think the key thing to look for is what kind of queries you're expecting to do on that JSON and how stable that data is going to be. (And if you actually need to store the data as JSON; it's generally pretty inexpensive to generate a JSON object)

MongoDB gets rid of the relational aspect of data in favor of data being very fluid in structure.

So if your JSON is going to vary a lot/is unpredictable/will change over time and you need to run queries efficiently like 'records where the field x exists and its value is higher than 3', that's a great use case for MongoDB.

It's hard to solve this in a standard relational model: Indexing on a single column that has wildly different values is pretty much impossible to do efficiently; and pulling out the data in its own columns is hard because it's hard to predict how many columns you'd have or what their datatypes would be. If this sounds like your predicament, 100% go for MongoDB.

If this is always going to be more or less the same JSON and the fields are going to be predictably the same, then the fact that it's JSON doesn't particularly matter much. Your indexes are going to approach it similar to a long string.

If the queried fields are very predictable, you should probably consider storing the fields as separate columns to have better querying capabilities. Ie if you have {"x":1, "y":2}, {"x":5, "y":6}, {"x":9, "y":0} - just make a table with an x and y column and generate the JSON. The CPU hit is worth it compared to the querying capabilities.

Just definitely don't use firebase. All of MongoDB, MySQL, MariaDB and PostGreSQL have a lot of community support and history.

Snowflake is a NoSQL database in the cloud, which also accepts SQL calls. Users can obtain an ODBC driver for SnowFlake, which would allow your Excel apps to write/read from the backend, locally.

As i see it, you can use Snowflake as your data warehouse and marklogic as a data lake. You can add all your raw data to ML and curate it to a company data model to then supply this to Snowflake. You could try to implement the dw functionality on marklogic but it will just cost you alot of time. If you are using Aws version of Snowflake you can use ML spark connector to access the data. As an extra you can use the ML also as an Operational report system if you join it with a Reporting tool lie PowerBi. With extra apis you can also provide data to other systems with ML as source.

I am biased (work for Scylla) but it sounds like a KV/wide column would be better in this use case. Document/schema free/lite DBs data stores are easier to get up and running on but are not as scalable (generally) as NoSQL flavors that require a more rigid data model like ScyllaDB. If your data volumes are going to be 10s of TB and transactions per sec 10s of 1000s (or more), look at Scylla. We have something called lightweight transactions (LWT) that can get you consistency.

I have found MongoDB highly consistent and highly available. It suits your needs. We usually trade off partion tolerance fot this. Having said that, I am little biased in recommendation as I haven't had much experience with couchbase on production.

Postgres and MySQL are very similar, but Mongo has differences in terms of storage type and the CAP theorem. For your requirement, I prefer Postgres (or MySQL) over MongoDB. Mongo gives you no schema which is not always good. on the other hand, it is more common in NodeJS community, so you may find more articles about Node-Mongo stuff. I suggest to stay with RDBMS if possible.

This is a little about experience. Postgresql is fine. You can use either the related table structure or the json table structure.

We have a ready-made engine for the online exchange and marketplace. To customize it, you only need to know sql. Connecting any database is not a problem. https://falconspace.site/list/solutions