Nope. I'm saying that if your argument is "I'm choosing this tech because I'm slow at this other tech" then it's very likely you're making a poor choice. There's nothing inherently slow about designing a relational database. The work required takes time, but the same is true if you're designing something for a schemaless database. You still have a schema, it's just defined in your application code instead of the database layer. That needs thought, and therefore time.
Working with a schemaless 'nosql' database is only faster if you're skipping the part where you think about how you store and access your data. That makes your system less reliable.
>I'm saying that if your argument is "I'm choosing this tech because I'm slow at this other tech" then it's very likely you're making a poor choice.
We do it all the time as the industry.
We do web dev in langs like c# java instead of c cpp
Even despite the fact that cpp is capable of returning html text just fine.
>Working with a schemaless 'nosql' database is only faster if you're skipping the part where you think about how you store and access your data. That makes your system less reliable.
How so?
At worst performance may be not optimal
The question whether youll get to this point is hard to answer
How about the using nosql by default to enable rapid development and sql when theres a need for it?
How about the using nosql by default to enable rapid development and sql when theres a need for it?
My point is that the development speed for nosql should be roughly the same as for relational databases, because you should be spending the same amount of time thinking about your data. The database you use is almost incidental. Whether you choose to create a users table in Postgres and make sure the data is valid there or whether you choose to create a JSON object in MongoDB and make sure the data is valid in the application logic doesn't matter - the hard, and the bit you should be spending time thinking about what does 'correct' mean for this set of data.
If you're creating a MongoDB table with a user JSON object, and then you just let different services manipulate that JSON however they want then your data will screw up in the future. There needs to be a robust contract between the app code and the data store that defines what the data is allowed to look like. That's where the time gets spent, whether it's in the database admin or in the application layer.
I would argue it's a bit easier to do that in a relational database but that's mostly down to experience.
>If you're creating a MongoDB table with a user JSON object, and then you just let different services manipulate that JSON however they want then your data will screw up in the future. There needs to be a robust contract between the app code and the data store that defines what the data is allowed to look like. That's where the time gets spent, whether it's in the database admin or in the application layer.
If other app touches my database in write mode and modifies the structure by mistake, then it is relatively good scenerio because the problem is easy to notice
In compare to messing with data e.g account balance += 200
And relational db without some hardcore constrains / triggers do not check it
I'd still rather have that code in app
>My point is that the development speed for nosql should be roughly the same as for relational databases, because you should be spending the same amount of time thinking about your data. The database you use is almost incidental. Whether you choose to create a users table in Postgres and make sure the data is valid there or whether you choose to create a JSON object in MongoDB and make sure the data is valid in the application logic doesn't matter - the hard, and the bit you should be spending time thinking about what does 'correct' mean for this set of data.
Thats in theory
In practice it always took me more time to setup postgre mssql and initial system model
Than when using mongo
Ive always used relational dbs but Ive started wondering whether I should start using nosqls in real world scenerios
Nobody says they are not reliable. We just say that by not using RDBMS, your application is now responsible of your data cohesiveness.
Good luck when you discover that your production database is full of incoherent data because a bug in your application generated unusable data objects (missing fields, wrong structure …) that your NoSQL was happy to store without a problem.
In a relational database, you are 100% guaranteed that your data fits the schema. It’s not just tables and columns names. It’s uniqueness checks, it’s constraints, it’s what to do with your data when a related data is modified or deleted.
Are you trying to say that NoSQL based systems are less reliable?