5 ms·

Not this again. ORMs are some of the most impenetrable code you'll ever see. Understanding the performance characteristics of a CRUD application using SQL is va

by l0b0 8y ago

Not this again. ORMs are some of the most impenetrable code you'll ever see. Understanding the performance characteristics of a CRUD application using SQL is vastly simpler than trying to puzzle out the arcane ways in which ORMs decide to throw up garbage once you add one more thing to the mix.

EGreg 8y ago
Not that again. ORMs achieve one main thing: being able to map your app’s objects to a relational database and back. But there are tons of other benefits: 1) Avoid all injection attacks by default by binding variables rather than interpolating their vakues 2) Write SQL code for you to automatically, so you always have balanced parentheses and no typos or errors mixing statements 3) Autogenerate classes and methods from the SQL model automatically so there is a place where you can add custom methods on objects 4) Model fields and relationships in a way the app can understand, so you can make meaningful error checks and manipulations in the app instead of relying on the database engine to give you a nice error message or manually copying the data type logic. 5) Play nice with version control, making sure to encapsulate the code in ONE PLACE instead of a million places when the schema or model changes. 6) Pissing people off on HN so we can better discuss and explain principles of architecting good softeare while talking anout the benefits of ORM 7) Let you write an adapter to move to eg a graph database which is far faster. 8) In fact, just making you avoid doing joins in the database by default is already a feature as you can make your app far more scalable w sharding and possibly think about making it byzantine fault tolerant and distributed! See for example this: https://qbix.com/platform/guide/database https://qbix.com/platform/guide/database https://qbix.com/platform/guide/models https://qbix.com/platform/guide/models
- olavk 8y ago
  I was with you some of the way but "making you avoid doing joins in the database" made me drop my monocle. You want joins in the database, they are designed for joins. Moving joins to the client will kill performance and scalability. And any sane ORM will perform the joins in the database by default.
  - EGreg 8y ago
    No, that's not true if you're building a huge site. Google has been avoiding joins as early as 2005. Joins were good for the smaller websites, but they don't scale. By avoiding joins, you have shared-nothing models that can be partitioned horizontally aka sharding. Now true, the latest and greatest databases such as CockroachDB go out of their way to try to do joins for you across partitions, even in an ACID manner, but then you have to use those. Better to avoid joins in the DB and do it in the app. You can then use a graph database instead of a relational database, going from O(log N) lookups to O(1) lookups for related data. Oh and finally, the newest (and pretty cool) craze of BFT, Byzantine Fault Tolerance. You can't achieve that if you're doing joins across different publishers, because they're not supposed to be able to access each other's stuff "just like that". Our ORM supports joins, even with multiple indexes, it even lets you define relationships and figures out the joins FOR YOU, but it is discouraged if you're building scalable sites. By the way thank you for proving point #6 hehe
    - olavk 8y ago
      So you have to use sharding because your databases have limited capacity. But you can just join in the app, because the app have unlimited memory?
      - EGreg 8y ago
        The app doesn’t hold the entire database at a time. The app simply does the following: 1) Get the root record(s) from id(s) 2) See what related records it needs, combine them into a list of ids, partition list by shard 3) Ask each shard for the corresponding records 4) Repeat from 2 if necessary 5) Return this whole tree / graph to the user Graph databases can do this in O(1) instead of O(log N) lookups. Relational joins are just one way to achieve this, which can be made atomic in the ACID sense. However, as you scale up your website, eg with 100,000,000 users, it would be silly to do massive joins. Google even says this in their docs now, for BigQuery. Instead, design your systems from the beginnig to be as parallel as possible, if you think they will scale. Look at the problems with Ethereum for example. Or Twitter fail whales of the past.
manigandham 8y ago
It's just code, compiled into a library that you can use, and queries are either logged by the library or in your database. What exactly is so impenetrable? That's just strange. Also CRUD is the ideal scenario for ORMs which handle all the mapping, security, parameterization, and even conversions between data types and models seamlessly while letting you just work with your objects. It seems you either didn't use ORMs correctly or used a very poor one.
- coldtea 8y ago
  >It's just code, compiled into a library that you can use. That's also true for code that one shouldn't use.
GrumpyNl 8y ago
Dont get me started over the abuse of active record.

by l0b0 8y ago

EGreg 8y ago

Not that again. ORMs achieve one main thing: being able to map your app’s objects to a relational database and back. But there are tons of other benefits: 1) Avoid all injection attacks by default by binding variables rather than interpolating their vakues 2) Write SQL code for you to automatically, so you always have balanced parentheses and no typos or errors mixing statements 3) Autogenerate classes and methods from the SQL model automatically so there is a place where you can add custom methods on objects 4) Model fields and relationships in a way the app can understand, so you can make meaningful error checks and manipulations in the app instead of relying on the database engine to give you a nice error message or manually copying the data type logic. 5) Play nice with version control, making sure to encapsulate the code in ONE PLACE instead of a million places when the schema or model changes. 6) Pissing people off on HN so we can better discuss and explain principles of architecting good softeare while talking anout the benefits of ORM 7) Let you write an adapter to move to eg a graph database which is far faster. 8) In fact, just making you avoid doing joins in the database by default is already a feature as you can make your app far more scalable w sharding and possibly think about making it byzantine fault tolerant and distributed! See for example this: https://qbix.com/platform/guide/database https://qbix.com/platform/guide/database https://qbix.com/platform/guide/models https://qbix.com/platform/guide/models

olavk 8y ago
I was with you some of the way but "making you avoid doing joins in the database" made me drop my monocle. You want joins in the database, they are designed for joins. Moving joins to the client will kill performance and scalability. And any sane ORM will perform the joins in the database by default.
- EGreg 8y ago
  No, that's not true if you're building a huge site. Google has been avoiding joins as early as 2005. Joins were good for the smaller websites, but they don't scale. By avoiding joins, you have shared-nothing models that can be partitioned horizontally aka sharding. Now true, the latest and greatest databases such as CockroachDB go out of their way to try to do joins for you across partitions, even in an ACID manner, but then you have to use those. Better to avoid joins in the DB and do it in the app. You can then use a graph database instead of a relational database, going from O(log N) lookups to O(1) lookups for related data. Oh and finally, the newest (and pretty cool) craze of BFT, Byzantine Fault Tolerance. You can't achieve that if you're doing joins across different publishers, because they're not supposed to be able to access each other's stuff "just like that". Our ORM supports joins, even with multiple indexes, it even lets you define relationships and figures out the joins FOR YOU, but it is discouraged if you're building scalable sites. By the way thank you for proving point #6 hehe
  - olavk 8y ago
    So you have to use sharding because your databases have limited capacity. But you can just join in the app, because the app have unlimited memory?
    - EGreg 8y ago
      The app doesn’t hold the entire database at a time. The app simply does the following: 1) Get the root record(s) from id(s) 2) See what related records it needs, combine them into a list of ids, partition list by shard 3) Ask each shard for the corresponding records 4) Repeat from 2 if necessary 5) Return this whole tree / graph to the user Graph databases can do this in O(1) instead of O(log N) lookups. Relational joins are just one way to achieve this, which can be made atomic in the ACID sense. However, as you scale up your website, eg with 100,000,000 users, it would be silly to do massive joins. Google even says this in their docs now, for BigQuery. Instead, design your systems from the beginnig to be as parallel as possible, if you think they will scale. Look at the problems with Ethereum for example. Or Twitter fail whales of the past.

manigandham 8y ago

It's just code, compiled into a library that you can use, and queries are either logged by the library or in your database. What exactly is so impenetrable? That's just strange. Also CRUD is the ideal scenario for ORMs which handle all the mapping, security, parameterization, and even conversions between data types and models seamlessly while letting you just work with your objects. It seems you either didn't use ORMs correctly or used a very poor one.

coldtea 8y ago
>It's just code, compiled into a library that you can use. That's also true for code that one shouldn't use.

GrumpyNl 8y ago

Dont get me started over the abuse of active record.