4 ms·

This article only tested two pages, each with millions of data. In corporate developments (and probably the original meaning of "joins don't scale" in the era o

by htfy96 6y ago

This article only tested two pages, each with millions of data. In corporate developments (and probably the original meaning of "joins don't scale" in the era of Oracle/MSSQL), it's usually the opposite - usually joining half dozen of tables, each with a few data, but their mappings and underlying relationship are usually not explicitly-defined, making joins across multiple tables super slow (RDBMS can only plan the query based on fundamental stats). In other words, joins now scale with table size, but still a challenge in terms of #tables

chadcmulligan 6y ago
> but their mappings and underlying relationship are usually not explicitly-defined wouldn't this be an issue no matter what you're using? I'm not sure what you mean by joins scale with table size? There are few times you'd join more than say 5 or 6 tables.
- htfy96 6y ago
  > There are few times you'd join more than say 5 or 6 tables. This is only true in new tech where data relationship isn't complicated. Any stored procedure in bank would contain joins with no fewer than that number of tables.
  - chadcmulligan 6y ago
    Really? Twenty years as a database consultant and 5 or 6 tables would be a typical upper limit, you could perhaps get up to 10 or so if you include a lot of lookup tables for codes. I've never worked in banks though, so what would you be looking at there typically?
    - Akronymus 6y ago
      I work at a leasing company, and we somewhat frequently have around 5-7 joins when getting data such as where to send how much money for work done at another company. The most I saw was "only" 10 though.
no-s 6y ago
>> usually joining half dozen of tables, each with a few data, but their mappings and underlying relationship are usually not explicitly-defined, making joins across multiple tables super slow Rather than "joins don't scale" it's more like "bad data design don't scale" Every few years I get the urge to create a RDBMS API that only allows data design using functional dependencies and defined types and possibly rules, i.e. only lets devs do "logical design". Usually happens when I discover some project dependent on EAVIL or giant master table syndrome. I've got a legion of cynical jokes about "emergent data design" and "Plato's Cave Shadows ERD", HHOS.

by htfy96 6y ago

chadcmulligan 6y ago

> but their mappings and underlying relationship are usually not explicitly-defined wouldn't this be an issue no matter what you're using? I'm not sure what you mean by joins scale with table size? There are few times you'd join more than say 5 or 6 tables.

htfy96 6y ago
> There are few times you'd join more than say 5 or 6 tables. This is only true in new tech where data relationship isn't complicated. Any stored procedure in bank would contain joins with no fewer than that number of tables.
- chadcmulligan 6y ago
  Really? Twenty years as a database consultant and 5 or 6 tables would be a typical upper limit, you could perhaps get up to 10 or so if you include a lot of lookup tables for codes. I've never worked in banks though, so what would you be looking at there typically?
  - Akronymus 6y ago
    I work at a leasing company, and we somewhat frequently have around 5-7 joins when getting data such as where to send how much money for work done at another company. The most I saw was "only" 10 though.

no-s 6y ago

>> usually joining half dozen of tables, each with a few data, but their mappings and underlying relationship are usually not explicitly-defined, making joins across multiple tables super slow Rather than "joins don't scale" it's more like "bad data design don't scale" Every few years I get the urge to create a RDBMS API that only allows data design using functional dependencies and defined types and possibly rules, i.e. only lets devs do "logical design". Usually happens when I discover some project dependent on EAVIL or giant master table syndrome. I've got a legion of cynical jokes about "emergent data design" and "Plato's Cave Shadows ERD", HHOS.