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

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

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

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.

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.

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.

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.

As far as I can tell, we are agreeing.

You should also consider that that was a loose, humorous description of what happened, and not something really worth analysing to the last letter.

Fair. I have multiple times run into that attitude seriously, otoh.