>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
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?