5 ms·

Unless you have some clever storage mechanism (such as a column-oriented database or a separate table with a join), 200 extra bytes directly in each row of a fr

Unless you have some clever storage mechanism (such as a column-oriented database or a separate table with a join), 200 extra bytes directly in each row of a frequently used table makes that table less efficiently use disk and memory caches. Consider if the entire rest of that row takes up 100 bytes, and now it takes up 300. You now can fit a third as many rows in each disk block or memory page.

socceroos 7y ago
This is so true. Fitting rows in the page was a big win for query times in my case.
ska 7y ago
Hence columnar stores. But parent is right that the choice of what shouldn't be coming from your DBA; they should be more interested in how.
- JoshTriplett 7y ago
  It is the DBA's job to advise, and that includes advice like "this isn't a good idea", or "could you do something else instead", or "this will require XYZ rearchitecting, which will affect these other factors/queries/etc". The DBA isn't the final decision-maker, but they're a critical advisor.
  - ska 7y ago
    Yes of course, but it's the business need that should drive that discussion, not the DB architecture. "I'm not putting X in my database" is very different than "Well, if we need to do Y, I think we'll have to change A, B & C". Up to others to decided if it is worth it or not.
    - DagAgren 7y ago
      You should also consider that that was a loose, humorous description of what happened, and not something really worth analysing to the last letter.
      - ska 7y ago
        Fair. I have multiple times run into that attitude seriously, otoh.
    - JoshTriplett 7y ago
      It's also completely reasonable to say "We shouldn't do Y". The response to everything shouldn't be to go immediately into solution space and list off trade-offs on the assumption that Y is happening. With people you trust for both their integrity and their expertise, "we shouldn't do Y" is a reasonable shorthand for "there are a pile of valid reasons we shouldn't do Y, and you and I both know I can list them for you off the top of my head, and it might well be possible anyway but it would take a lot more work and trade-offs than you might expect". That isn't the end of the conversation; if the response to "we shouldn't do Y" is "it'll be a pain if we can't do Y", then you can explore solution space together, where that solution space includes both trade-offs to support doing Y and alternatives to doing Y. Use experts for their expertise, rather than the equivalent of "I don't care, make it happen". Or, in short: yes, of course the DBA doesn't unilaterally dictate the architecture, but maybe listen to their expertise anyway.
      - ska 7y ago
        As far as I can tell, we are agreeing.
magicalhippo 7y ago
This discussion reminds me of when I read in our database server's documentation something along the lines of "for very wide tables (more than 10 columns)" and I literally had to laugh out loud, as the main table at work is over 500 columns wide... Gotta love organic db schemas with long history...
- hinkley 7y ago
  > the main table at work is over 500 columns wide... This is horrifying, but at least not as horrifying as the public sector database I once had to work with that predated proper support for foreign keys, so there was a relationship table that was about 4 columns wide and must have had more rows than the rest of the database combined. Even the database they had moved this schema to struggled with that many join operations.
- PavlovsCat 7y ago
  That's like snickering when someone mentions that sugar is unhealthy in large quantities because you smoke 5 packs a day or something. That doesn't make it less valuable to those who aren't yet stuck with crap. > Gotta love organic db schemas with long history... I much more love the fact that I always have the option to start with a blank file and an empty db schema. I love the fact that decades of ignoring "social" advice about doing it this or that way because "everybody" does that, and just looking at the docs I could find/understand and making a decision, programming gets more fun and effective every year for me. I love that there is still development to be had outside of corporations and more or less unfettered by their regression. "How do I learn Javascript?" "Use a framework, they do the hard work for you. Don't learn Javascript, learn this wrapper around Javascript." "How do I learn CSS?" "Use Bootstrap or install this theme generator with a compilation pipeline. Don't learn CSS, learn this wrapper around CSS." "How do I set up a DB that doesn't suck balls?" "Use an ORM, just describe things to it, and it will do all the boring stuff for you. Don't fuzz about with a DB though, or SQL or anything, that has so many pitfalls... you might lose data or have a slow query one day, and then you obviously die."

socceroos 7y ago

This is so true. Fitting rows in the page was a big win for query times in my case.

ska 7y ago

Hence columnar stores. But parent is right that the choice of what shouldn't be coming from your DBA; they should be more interested in how.

JoshTriplett 7y ago
It is the DBA's job to advise, and that includes advice like "this isn't a good idea", or "could you do something else instead", or "this will require XYZ rearchitecting, which will affect these other factors/queries/etc". The DBA isn't the final decision-maker, but they're a critical advisor.
- ska 7y ago
  Yes of course, but it's the business need that should drive that discussion, not the DB architecture. "I'm not putting X in my database" is very different than "Well, if we need to do Y, I think we'll have to change A, B & C". Up to others to decided if it is worth it or not.
  - DagAgren 7y ago
    You should also consider that that was a loose, humorous description of what happened, and not something really worth analysing to the last letter.
    - ska 7y ago
      Fair. I have multiple times run into that attitude seriously, otoh.
  - JoshTriplett 7y ago
    It's also completely reasonable to say "We shouldn't do Y". The response to everything shouldn't be to go immediately into solution space and list off trade-offs on the assumption that Y is happening. With people you trust for both their integrity and their expertise, "we shouldn't do Y" is a reasonable shorthand for "there are a pile of valid reasons we shouldn't do Y, and you and I both know I can list them for you off the top of my head, and it might well be possible anyway but it would take a lot more work and trade-offs than you might expect". That isn't the end of the conversation; if the response to "we shouldn't do Y" is "it'll be a pain if we can't do Y", then you can explore solution space together, where that solution space includes both trade-offs to support doing Y and alternatives to doing Y. Use experts for their expertise, rather than the equivalent of "I don't care, make it happen". Or, in short: yes, of course the DBA doesn't unilaterally dictate the architecture, but maybe listen to their expertise anyway.
    - ska 7y ago
      As far as I can tell, we are agreeing.

magicalhippo 7y ago

This discussion reminds me of when I read in our database server's documentation something along the lines of "for very wide tables (more than 10 columns)" and I literally had to laugh out loud, as the main table at work is over 500 columns wide... Gotta love organic db schemas with long history...

hinkley 7y ago
> the main table at work is over 500 columns wide... This is horrifying, but at least not as horrifying as the public sector database I once had to work with that predated proper support for foreign keys, so there was a relationship table that was about 4 columns wide and must have had more rows than the rest of the database combined. Even the database they had moved this schema to struggled with that many join operations.
PavlovsCat 7y ago
That's like snickering when someone mentions that sugar is unhealthy in large quantities because you smoke 5 packs a day or something. That doesn't make it less valuable to those who aren't yet stuck with crap. > Gotta love organic db schemas with long history... I much more love the fact that I always have the option to start with a blank file and an empty db schema. I love the fact that decades of ignoring "social" advice about doing it this or that way because "everybody" does that, and just looking at the docs I could find/understand and making a decision, programming gets more fun and effective every year for me. I love that there is still development to be had outside of corporations and more or less unfettered by their regression. "How do I learn Javascript?" "Use a framework, they do the hard work for you. Don't learn Javascript, learn this wrapper around Javascript." "How do I learn CSS?" "Use Bootstrap or install this theme generator with a compilation pipeline. Don't learn CSS, learn this wrapper around CSS." "How do I set up a DB that doesn't suck balls?" "Use an ORM, just describe things to it, and it will do all the boring stuff for you. Don't fuzz about with a DB though, or SQL or anything, that has so many pitfalls... you might lose data or have a slow query one day, and then you obviously die."