6 ms·

I will play devil advocate Relational databases add too much time overhead due to building schema or configuring orm for schema Migrations management Buildin

I will play devil advocate Relational databases add too much time overhead due to building schema or configuring orm for schema Migrations management Building an db model to domain model mapper and maintaining it You waste time thinking about building an db model and focusing on that technical layer which probably eventually affecta the way you model your system Nosql gives you modeling freedom which is handy for architects

CodesInChaos 4y ago
You might want to take a look at EdgeDB. You still have to define a schema, but both its data model and query language have much smaller mismatch with popular programming languages and APIs, so you don't need a complex ORM. For example it has first class support for following links (instead of awkwardly joining on foreign keys), outputting nested data and polymorphism.
onion2k 4y ago
Relational databases add too much time overhead due to building schema or configuring orm for schema That sounds like the same sort of argument as "I'm not going to write tests because they slow me down!"
- hardware2win 4y ago
  Even if it sounds, then what? Are you trying to say that NoSQL based systems are less reliable?
  - onion2k 4y ago
    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.
    - hardware2win 4y ago
      >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?
      - onion2k 4y ago
        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.
        hardware2win 4y ago
        >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
  - pjerem 4y ago
    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.
    - hardware2win 4y ago
      Database integrity checks are only small part of integrity checks You still must have those in code to operate on valid business object I'd say that world has partly moved from programming in database and does it in code which can be easily covered with tests
- wruza 4y ago
  But that statement is true for some development and business models. No automated testing is like mastrubation - no one wants to admit, but many do it. https://insights.stackoverflow.com/survey/2019 https://insights.stackoverflow.com/survey/2019 (search for Unit Tests, #-linking doesn’t work correctly on this site, perhaps because they don’t test it) Also tap on a Job Satisfaction button to see how it correlates.
forgotmypw17 4y ago
The effort to make a key-value store on top of a relational database is negligible. The effort to make a relational database on top of a key-value store which is not already a relational database is great.
dkdbejwi383 4y ago
Using a relational DB doesn't necessitate the use of an ORM. This is another case of YAGNI. I rarely reach for an ORM until there's significant enough complexity to warrant it, and even then it's not a decision made lightly. Designing and maintaining a schema is not too arduous. There are tools which can produce a diff between the current and desired schema for your database, for instance Migra for Postgres (https://github.com/djrobstep/migra https://github.com/djrobstep/migra).
- hardware2win 4y ago
  I didnt say it is I said building schema or configuring an orm which will create schema.
- techdragon 4y ago
  Yet more counterpoints, I find that more often than not, as a project matures the more it ends up implementing its own half baked ORM internally and much time will often be saved just using an ORM from the start. It’s harder to restructure all your data to fit the ORM you eventually need to manage X developers working on the application than it is to just pick and use an ORM from the start.
boxed 4y ago
Djangos migration system is so good that migrations are basically a non-issue. Having worked with it a while it's really weird that more frameworks are still so radically behind.

CodesInChaos 4y ago

You might want to take a look at EdgeDB. You still have to define a schema, but both its data model and query language have much smaller mismatch with popular programming languages and APIs, so you don't need a complex ORM. For example it has first class support for following links (instead of awkwardly joining on foreign keys), outputting nested data and polymorphism.

onion2k 4y ago

Relational databases add too much time overhead due to building schema or configuring orm for schema That sounds like the same sort of argument as "I'm not going to write tests because they slow me down!"

hardware2win 4y ago
Even if it sounds, then what? Are you trying to say that NoSQL based systems are less reliable?
- onion2k 4y ago
  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.
  - hardware2win 4y ago
    >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?
    - onion2k 4y ago
      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.
      - hardware2win 4y ago
        >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
- pjerem 4y ago
  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.
  - hardware2win 4y ago
    Database integrity checks are only small part of integrity checks You still must have those in code to operate on valid business object I'd say that world has partly moved from programming in database and does it in code which can be easily covered with tests
wruza 4y ago
But that statement is true for some development and business models. No automated testing is like mastrubation - no one wants to admit, but many do it. https://insights.stackoverflow.com/survey/2019 https://insights.stackoverflow.com/survey/2019 (search for Unit Tests, #-linking doesn’t work correctly on this site, perhaps because they don’t test it) Also tap on a Job Satisfaction button to see how it correlates.

forgotmypw17 4y ago

The effort to make a key-value store on top of a relational database is negligible. The effort to make a relational database on top of a key-value store which is not already a relational database is great.

dkdbejwi383 4y ago

Using a relational DB doesn't necessitate the use of an ORM. This is another case of YAGNI. I rarely reach for an ORM until there's significant enough complexity to warrant it, and even then it's not a decision made lightly. Designing and maintaining a schema is not too arduous. There are tools which can produce a diff between the current and desired schema for your database, for instance Migra for Postgres (https://github.com/djrobstep/migra https://github.com/djrobstep/migra).

hardware2win 4y ago
I didnt say it is I said building schema or configuring an orm which will create schema.
techdragon 4y ago
Yet more counterpoints, I find that more often than not, as a project matures the more it ends up implementing its own half baked ORM internally and much time will often be saved just using an ORM from the start. It’s harder to restructure all your data to fit the ORM you eventually need to manage X developers working on the application than it is to just pick and use an ORM from the start.

boxed 4y ago

Djangos migration system is so good that migrations are basically a non-issue. Having worked with it a while it's really weird that more frameworks are still so radically behind.