The answer to every problem is to rebuild statistics. (And never use stored procedures. It's just a shitty API layer in the worst language imaginable, sitting outside of source control. If you need an API layer, write it in a real language, ideally the one you're already using.)
Rebuilding statistics will not help if the cause of the bad plan is something that the cost based optimizer is not even trying to model.
Stored procedures in this context are just a clumsy workaround to control the planner so your comment about API layer is irrelevant. But if you like, you can write stored procedures in a ton of different languages. And if you do not have source control for your database artifacts, you are doing it wrong. A common reason for stored procedures is to not have a bunch network roundtrips in the middle of your transaction logic while you are holding onto locks / have an open conflict window.
SQL Server stored procedures don’t provide a separate tier of T-SQL functionality. Anything they do to the data can generally be expressed and executed as a T-SQL batch. If you think you need stored procedures to avoid network roundtrips in the middle of your transaction logic, you’d be wrong.
Stored procedures are essentially a crude, database-bound API layer. For serious application development, a proper service layer provides stronger contracts, authentication, testing, versioning, observability and source control in a sane general-purpose language, ideally the same one you’re already manipulating the data with elsewhere.
Meh, a T-SQL batch is just an anonymous transient stored procedure.
I guess we agree on them being an API that gets deployed on the database, but I disagree that it needs to be crude. It's exactly as crude as you make it. If you don't have authentication, testing, versioning, observability and source control for your database you are doing it wrong.
I haven’t finished reading this but I am commenting because of the form. Lead with the conclusions, table of contents, and then sources? This is someone who is confident in what they write. I wish more writing trusted the audience to decide if the writing were important instead of stringing the audience allow. Keep up the good work.
Your example about this hinge is nurturing behaviour. This is exactly what people should be doing- identifying issues and also at least suggesting they be fixed before proceeding if not offering a fix themselves.
There is more to your reputation than what sounds like a genuine growth mindset.
Maybe. I tend to focus on "blockers," and things that can go wrong, first. I suspect a lot of people want to be buttered up, before the problems are discussed (i.e. "That's a really great idea! Have you thought about how often the hinge is stressed?")
I'm a bit "spectrumish," so I sometimes miss the niceties.
The Japanese were not reticent about discussing problems. It was fairly brutal, but we made great stuff.
Agreed, but it’s been my experience that anything that isn’t enthusiastic agreement, is considered “negativity.”
When I encounter someone that is so fragile, that they literally fall apart, if we aren’t cheerleading, then I can’t work with them. I’m a creative, myself[0]. I’m familiar with the process.
It’s my experience, that we often can’t see things that will kill the project, until we start drilling into the details; sometimes, not too far. Finding these things is not a death sentence. It’s the first step to success. They exist; whether or not we choose to see them.
If your feet are wet, and you see pyramids, you’re in de Nile (or a fountain in Vegas).
I have learned that this kind of introspection needs to happen, as soon as possible. It’s the way that I have been trained to work, and I’ve been shipping stuff, for my entire adult life. Shipping is not for the faint of heart. If your idea is meant to be displayed on a refrigerator, then you have the luxury of chasing off disagreement. If it's supposed to be something that people stake their careers on, and pay for, then we need to have a thicker skin.
[EDITED TO ADD] A practical reason for finding the issues early, is who will be solving the problem. The earlier you find the problem, the more likely the person addressing it, will be creative. They will have more room to work, and they will be more invested in the vision, as opposed to the implementation. Late fixes are ugly.
This is infuriating. However, for those in this situation, know this: it works if the document or spreadsheet is in OneDrive. I just wish Copilot told you this instead of asking you to upload the doc.
The book that changed the game for me is “Leadership and Self-Deception”. The thesis being that the root of resentment is self-betrayal, where self-betrayal is denying your impulse to do right by others.
Ever since I read it, I’ve been more aware of when I am fixated on I and me.
It’s amazing. You can be completely “right” about a situation, yet still be fixated about the self. Escaping the box - terminology from the book - doesn’t change what’s real, but absolutely changes how you feel, and how your situation progresses.
Whether it is self help or blame or resentment, they are all in the box activities. There is another world- a better world.
The post you’re r replying to gets this right- lead time is everything. The fast you can iterate, the more likely that what you are doing is correct.
I’ve had a similar experience to what you’re describing. We are slower with AI… for now. Lean into it. Exploit the fact that you can now iterate much faster. Solve smaller problems. Solve them completely. Move on.
This is my focus protocol. Whenever I find myself having trouble trying started on a task, I create a new desktop and open windows related to the task only. DnD on. Pick a next step. Execute.
reply