Also that urgency is rooted in job insecurity, not even customer impact. They just don't want to look bad.

E: which I mean fair enough, me too, but still.

Welcome to the professional world where everything is iterative and and 95% of your clients (internal or external) are data illiterate and don't want to learn whatever self service tools you build.

Sorry to break this to you.....but this won't be the last time that happens. In fact, it'll probably happen on more projects than not.

Mr. Manager calling from a group

Hi everyone, I know we're all busy, but I just wanted to align on this 2 hr estimate. Can we put our heads together and do this faster somehow?

Newspaper: Hackers are announcing a trove of personal data leaked from [company] after a forwarded spreadsheet inadvertently contained more data than the sender realised.

Lolz got that one too

I like that idea, and it actually did work for our Marketing guy (Salesforce has a kind of SQL). Near the end there, I just had to debug a few of his harder errors, or double check a script that was going to be running on production.

Never thought of it for Postres or Mysql, etc, but I suppose there's got to be an easy enough way to get someone access

Relatable. 🤣

well, there's confusion, paranoia, agitation and so many others...

Yeah. Luckily the work I am doing is to fix some really bad work that the entire company has been complaining about. So once it's fixed it will hopefully be a little bit more recognition than that. Plus my boss is pretty level headed.

But who fucking knows? There is always the likelihood that people will say things along those lines. And it ain't my job to fight them on that.

No, we have worse. Dates sometimes stored as strings, sometimes as datetimes, and sometimes as integers. There is no consistency, logic, or forethought to the schema.

It's rough.

Basically scripts you can run on the fly to pull calculated data. You can (mostly) treat them like tables themselves if you create them on the server.

So if you have repeat requests, you can save the view with maybe some broader parameters and then just SELECT * FROM [View_Schema].[My_View] WHERE [Year] = 2023 or whatever.

It can really slow things down if your views start calling other views in since they're not actually tables. If you've got a view that you find you want to be calling in a lot of other views, you can try to extract as much of it as you can that isn't updated live into a calculated table that's updated by a stored procedure. Then set the stored procedure to run at a frequency that best captures the changes (usually daily). It can make a huge difference in runtime at the cost of storage space.

A view is a saved query that pretends it's a table. It doesn't actually store any data. So if you need to query 10 different tables, joining them together and filtering the results specific ways, a view would just be that saved query, so instead of "SELECT * FROM (a big mess of tables)" you can do "SELECT * FROM HandyView"

Predefined queries that you can interact with like another table more or less

our biggest client prefers data as Jason so we swapped half of our database to that

the app I work with currently stores json as the only column in a sql table and it hurts me so very much. like watching someone pick up a screwdriver and try to bash a nail in with the handle.