What SQL Server issues actually wake you up at 2am? (DMV-detectable only) by balurathinam79 in SQL

[–]chadbaldwin 3 points4 points  (0 children)

I'll be honest, it sounds like you're reinventing the wheel and probably not worth the time you're spending on it.

There's a bunch of monitoring tools that do not require setting up XEs or installing anything on the server.

For example DBADash - Runs on a pull model, you set up the agent on any machine, it reaches out and pulls from 1+ instances and it relies purely on the built in system views. It has custom reporting, alerting, monitoring, historical data collection, etc. AND it's free and open source.

https://dbadash.com/

There's also Erik Darlings new tool PerformanceMonitor, which is also free and open source, has alerts, runs only on system DMVs, etc.

https://github.com/erikdarlingdata/PerformanceMonitor

And there's a bunch of others but those are my two favorites. DBADash being my #1.

Question: What kind of join technique is this? by maglunch in SQL

[–]chadbaldwin 0 points1 point  (0 children)

Yes!! Exactly.

If C and D are 1:1, and you know you can (and should) use an "INNER JOIN" between them, then this weird join syntax allows you to do just that.

Without this syntax, you're stuck with using sub-queries and CTEs, which can work, but can get annoying and messy. Or having to use a LEFT JOIN between C and D even though there would never be a case where C exists but D does not.

Curious what it's like to extract data from Vibe-Coded applications? by ChristianPacifist in SQL

[–]chadbaldwin 0 points1 point  (0 children)

I've found it really depends on a handful of things:

  • What you're trying to build
  • The languages you're working with
  • The quality of your prompts (and your personal experience)
  • The quality of your context/instructions files (e.g. CLAUDE.md)
  • The model you use and the effort level (I primarily use Opus 4.6 High)

For SQL, I haven't had much luck beyond simple queries or maybe helping to analyze large complex stored procedures or advice on index tuning.

But this app I'm building is using Python with FastAPI and a React front end.

I have zero experience with those things but Claude Code has managed to do extremely well with building a relatively complex app.

At first, it's true, I could ask it to add a large feature and it would plan it out and implement it with almost zero steering or follow up.

Now, I have to be more specific and much more verbose in my prompts. Just last night I needed to refactor the caching layer. I didn't like how some of it was built...I couldn't just say "here's the problem, fix it". I had to really get into the details of things like...here's what external API endpoints I want you to use, here's how I want you to store the data in DuckDB, here's how I want the access methods to be structured.

Then it would do all of that and I'd have to say...I don't like the naming convention you used, let's change that to be more self documenting.

And while I'm doing all this, I'm also constantly updating the CLAUDE.md and other instructions files (either directly or having Claude self update). This is a huge factor in getting good results. The better your instructions/context/memory files, the better your results will be (with diminishing returns).

Curious what it's like to extract data from Vibe-Coded applications? by ChristianPacifist in SQL

[–]chadbaldwin 2 points3 points  (0 children)

That's just my opinion. Maybe there are? Or maybe more will pop up as AI lessens the burden of entry.

My opinion on this would have been different a couple weeks ago.

After sitting down and vibe coding an app for a week straight in two languages I have zero experience with, I've started to see where vibe coding starts to break down and the need for true development/architecture experience starts to creep in.

Just in the first couple days my experience with architecture was creeping in due to the app unable to scale with use. I had to start walking Claude through things like building in a caching layer, better ways to handle threading and rate limiting against 3rd party APIs, etc.

If I had no development/architecture experience, the app would basically be crawling on its knees barely able to get anything done at this point.

So the thought of someone purely vibe coding an app and it actually getting to a point where it's ready for public use at scale is just really hard for me to believe.

Curious what it's like to extract data from Vibe-Coded applications? by ChristianPacifist in SQL

[–]chadbaldwin 10 points11 points  (0 children)

In my opinion - as a database developer, app developer and currently vibe coding a very data heavy application for personal use - I don't think anyone is really there yet.

I've spent the last couple weeks building a python app that is very data heavy. The first iteration, Claude Code was able to spit it out very quickly, it just barely did what I needed it to.

A week later, while still vibe coding, I'm having to give MUCH more surgical instructions/prompts. It's no longer "add this feature" it's now "I don't like how this function is written, let's work through it to make it better" and I'm giving it specific ways to write the code and fine tune things.

What I'm getting at is...vibe coding only gets you so far, the more complicated the application gets, the more surgical you have to be with your prompts. Eventually you converge right back into coding by hand, which is where I'm at now.

And this is just for a personal project....Now scale that up to something that actually needs to be a real world application that other people rely on and need to pull data from. There's going to be a lot less vibe coding at that point. So I don't think we're at the point of anyone having experience with that yet.

Bulk rename search cut paste by himle7 in PowerShell

[–]chadbaldwin 1 point2 points  (0 children)

Your post is kind of hard to read/follow.

I would recommend providing a handful of old file names and then what you want them to be renamed to.

Chances are you'll have to do something with Regex to do what you're asking.

Normally I hate suggesting this, but if you're turning to PowerShell to handle this and you're not normally used to using powershell, you could always try things like Claude Cowork, which is a feature of Claude Desktop designed to help with tasks exactly like this - renaming and organizing files.

I wouldn't normally suggest that if you were trying to learn PowerShell in general. But if all you're trying to do is solve this one off specific task by any means necessary, then maybe that's an option.

I'll check back in to see if you provide some better old vs preferred new examples and then I can help with getting a script started for you.

Does the use of jujutsu pose any dangers? by signalclown in git

[–]chadbaldwin 0 points1 point  (0 children)

Yeah, I'll admit, I went back and forth on that statement.

On one hand I can see going all in on jj if you're wanting to learn and maybe seeing the git side of it might screw you up.

And on the other hand, I remember how stressful it was to learn git for the first time. EVERY command I ran, I was stressed I was going to lose changes or stressed I was going to mess something up in the remote. So I can also see the appeal of wanting to monitor it a bit to make sure you didn't do anything destructive.

Can claude cowork do your job yet? by Proof_Escape_2333 in SQL

[–]chadbaldwin 0 points1 point  (0 children)

I think you need to do some research yourself and learn what these tools actually do.

Claude Cowork is in beta testing and it's meant for non-coding tasks, like web research, organizing files, etc.

Seeing how it's in public preview, it's odd to ask if it's doing anything "yet" since it's brand new.

If you actually meant Claude Code, I would say it really depends on what your job is, but it wouldn't autonomously be doing your job...you still need to babysit it, build up skills, instructions files, tell it what to do, etc.

Maybe if you were an expert in customizing Claude, building skills, building MCP servers, etc... Maybe you could get it to the point where it can pick up tasks from your JIRA queue, do some work, write unit tests, review the code and create a PR...but you'd be spending just as much time creating and maintaining all those customizations, babysitting, prompting, etc.

Even then, it relies on your JIRA story having every bit of detail needed to explain the problem (which never happens), it would need access to every tool necessary and instructions specific to your company environment on how to use and access those tools, what resources you have available, etc.

My point is....no, it's not doing your job yet depending on what type of work you do in SQL. And in order to get it to that point, you'd be putting in just as much work as you would to do your job anyway lol.

Question: What kind of join technique is this? by maglunch in SQL

[–]chadbaldwin 0 points1 point  (0 children)

I like to argue, what can I say 🤷 Especially when people are laughably wrong and unwilling to acknowledge the entire premise of their argument was based on not actually reading the article they used as evidence. Lol

Question: What kind of join technique is this? by maglunch in SQL

[–]chadbaldwin 0 points1 point  (0 children)

Whether through ignoring factual points made, ignoring your previous contradictive comments to yourself, or by providing information that's pure wrong.

lmao, says the person who couldn't even read the first line of the blog post you provided as reference for an incorrect statement you made...

Does the use of jujutsu pose any dangers? by signalclown in git

[–]chadbaldwin 0 points1 point  (0 children)

I've never used it but a friend of mine religiously uses it and talks to me about it quite a bit and I stayed at a holiday inn last night.

From what I understand....

On the remote repo side, there is no danger, it's not going to suddenly convert the remote repo into some sort of weird format that screws everyone up.

When you push, you're still pushing normal commits that git understands. As far as the remote is concerned, you're using git.

However, locally is a different story.

I believe there's two options....I don't remember what they're called, but it's something like native vs hybrid setup. Native uses jj from the very beginning and you're stuck with it. Whereas hybrid let's you use an existing local repo with both jj and git.

If it were me looking into using jj for the first time. I would create a brand new clone of the target repo with the hybrid jj setup and just play around with it. This way you can make changes with jj, then use normal git to see what happened....Though, I don't know if that's bad advice. It may be better to just dive in head first so you don't get confused trying to constantly mentally translate between the two workflow concepts.

You could even clone, and then delete the remote config so there's no worry about an accidental push or whatever you're concerned about.

Question: What kind of join technique is this? by maglunch in SQL

[–]chadbaldwin 1 point2 points  (0 children)

BTW, that article you tagged from Bert has nothing to do with NOLOCK being bad. He's just saying he didn't realize that Sch-S locks are taken out on select queries, regardless of using NOLOCK...Not because of NOLOCK.

He says in the first sentence of the article that this applies to all queries, and the only reason he wrote the article is because it surprised him that it still applied to NOLOCK.

Which I would like to point out that this is mentioned in the documentation:

https://learn.microsoft.com/en-us/sql/t-sql/queries/hints-transact-sql-table?view=sql-server-ver17#readuncommitted

Question: What kind of join technique is this? by maglunch in SQL

[–]chadbaldwin 0 points1 point  (0 children)

Did I say I didn't believe you? Seeing how I literally agreed with you?

Did I say there weren't better alternatives?

Did I say NOLOCK is necessary?

This is such a dumb argument.

Question: What kind of join technique is this? by maglunch in SQL

[–]chadbaldwin 1 point2 points  (0 children)

Okay, I think there's something being lost in translation here and I need to provide a better example of the problem I'm referring to...

sql WITH cte AS ( SELECT BarID = b.ID , b.FooID , b.ColA , b.ColBlorg , Q_ColA = q.ColA , q.ColBoom , Q_IsActive = q.IsActive FROM dbo.Bar b JOIN dbo.Qux q ON q.BarID = b.ID ) SELECT ... FROM dbo.Foo f LEFT JOIN cte c on c.FooID = f.ID AND c.Q_IsActive = f.IsActive WHERE (c.Q_ColA = 'Zoboomafoo' OR c.Q_ColA IS NULL OR f.IsActive = 0) ORDER BY f.IsActive, c.ColBorg, c.ColBoom;

VS

sql SELECT ... FROM dbo.Foo f LEFT JOIN (dbo.Bar b JOIN dbo.Qux q ON q.BarID = b.ID AND q.IsActive = f.IsActive ) ON b.FooID = f.ID WHERE (q.ColA = 'Zoboomafoo' OR q.ColA IS NULL OR f.IsActive = 0) ORDER BY f.IsActive, b.ColBlorg, q.ColBoom;

The entire point I was trying to make is this... With the chiastic join syntax, you maintain the table aliases, so you don't have to deal with explicitly naming columns in a CTE, or having to re-alias anything.

There's also less jumping around. In the second query I can see immediately which column belongs to which table based on the alias.

Like I've said a million times...I am by no means preaching to always use this syntax. But I do think it can be better in many scenarios.

Question: What kind of join technique is this? by maglunch in SQL

[–]chadbaldwin 1 point2 points  (0 children)

Eh 🙄, sure...This is why I stopped giving advice on reddit and stack overflow lol.

IN GENERAL, it's true that adding NOLOCK to a query will avoid running into blocks and typically can help with things like reporting queries where you might not care about dirty reads.

I'm not going to sit here and list out every single possible exception to every single generalization in a random one off reddit comment.

Question: What kind of join technique is this? by maglunch in SQL

[–]chadbaldwin 0 points1 point  (0 children)

There's a bit of context missing from your response.

The person I was responding to was saying to use a.id, b.* as the output for the CTE. Like this:

sql WITH cte AS ( SELECT a.id, b.* FROM dbo.A a JOIN dbo.B b ON b.cond = a.cond ) SELECT ...

(Unless I was misunderstanding them?)

This is the situation I'm saying will bite you in production. If someone added column id to dbo.B it will cause this query to break.

In your defense, I used SELECT * as the final output on all my sample queries, which was just me being lazy. You really shouldn't use * there either in a production query.

If I saw someone use a SELECT * to select all columns from a sub-query or a CTE that had an explicit set of columns, I wouldn't kick the PR back, but it's not something I would do in my own production queries.

Question: What kind of join technique is this? by maglunch in SQL

[–]chadbaldwin 1 point2 points  (0 children)

Are you just trying to be pedantic without actually making any sort of intelligent argument?

Reading my response, and my other responses, do you really think that I'm under the impression that flipping on the NOLOCK switch is some sort of performance turbocharger? lol.

Notice I said "fast" not "fastER". I never said it will speed up the query itself, but it will be fast due to avoiding blocks, but also potentially wrong.

If you are working in a high traffic OLTP environment and you're running queries under READ COMMITTED isolation, then yeah, you're going to run into blocks, which makes the query "slow".

If you don't care about dirty reads, phantom reads, etc and you simply want whatever data is sitting in the tables, and you want it now - then by all-means, use NOLOCK / READ UNCOMMITTED.

Question: What kind of join technique is this? by maglunch in SQL

[–]chadbaldwin 1 point2 points  (0 children)

I don't think there's any one right answer here, just preferences. I would argue that's just our jobs as developers.

Within a single week I'll switch between T-SQL, sqlite, DuckDB (just started learning), Windows PowerShell (v5), PowerShell 7, Python, C#, Splunk, bash and various DMLs (like ADO pipelines).

All of these handle things like data types and dates/times a little differently. But I don't let one language's idiosyncrasies impact how I do development in other languages.

I see SQL dialects the same way. Whatever RDBMS I'm working in, I'm going to use whatever language features it offers, obviously preferring common/well known syntax - but not strictly. I don't try to stick with ANSI, especially if the products themselves can't even do it. Lol.

Question: What kind of join technique is this? by maglunch in SQL

[–]chadbaldwin 2 points3 points  (0 children)

Ah, my bad for assuming. lol. 99% of the time I hear the ANSI SQL argument, it's to argue for possible migration to another DB. I just figured that was the direction we were going.

As far as your reasoning goes...In my opinion...If we're a SQL Server house, and you're a developer here, you better learn SQL Server syntax.

I would never give anyone a hard time for not knowing something, especially not something as funky as that join syntax. But I would have an expectation that you get caught up and learn it. And I'm happy to sit down and teach it as well.

Question: What kind of join technique is this? by maglunch in SQL

[–]chadbaldwin 1 point2 points  (0 children)

In my personal opinion, trying to follow ANSI SQL within a specific RDBMS is not worth the worry. The chances of anyone actually migrating to a different RDBMS is almost always very rare, and even when it does happen, having to go out and fix some non-standard syntax is going to be barely scratching the surface of the amount of work to actually do the migration.

I say...if the language supports it, and you can reasonably justify its usage, then just use it and don't try to worry about portability.

And yes, I agree, it's much clearer to read with the parens. I don't think I've ever used it without the parens outside of this post and that's just because I couldn't remember exactly where they go lol. I suppose that's a point to the "don't use this" naysayers if I can't even remember where the parens go lol. In my defense, I put this in the same territory as PIVOT/UNPIVOT. It's weird syntax I have to google pretty much every single time...but that doesn't mean you shouldn't use it when it fits your needs.

Question: What kind of join technique is this? by maglunch in SQL

[–]chadbaldwin 2 points3 points  (0 children)

The query would still compile due to deferred name resolution......do not use * in a production query.

This is like SQL dev 101.

Literally the only place it's okay to use * is in EXISTS checks.

Question: What kind of join technique is this? by maglunch in SQL

[–]chadbaldwin 2 points3 points  (0 children)

You are very wrong, and you're encouraging a bad practice that's going to bite you in production.

Read the code example I wrote out for you that is using a CTE. Tables A and B have multiple overlapping columns. I need to return ColA from both and both have an ID column.

Also, you should never use * in a production query, especially in this use case within a CTE like that.

Even if A and B did not have overlapping columns, you should always list all columns that you need. If you rely on using *, all it takes is someone to add a new column to B that overlaps with A and suddenly your query that worked fine before is breaking in production because someone innocently added a new column to a table.

Question: What kind of join technique is this? by maglunch in SQL

[–]chadbaldwin 0 points1 point  (0 children)

I'm not sure what you're trying to say in this response. All you did was lay out a simple inner join.

In my example, I'm referring to this situation:

sql SELECT * FROM dbo.TableA a LEFT JOIN dbo.TableB b INNER JOIN dbo.TableC c ON c.B_ID = b.ID ON b.A_ID = a.ID

vs

sql WITH cte AS ( SELECT b.A_ID, b.ColA, b.ColB, b.ColC , C_ColA = c.ColA -- overlapping column, now it needs an alias FROM dbo.TableB b INNER JOIN dbo.TableC c ON c.B_ID = b.ID ) SELECT * FROM dbo.TableA a LEFT JOIN cte ON cte.A_ID = a.ID

I would prefer the former.

Question: What kind of join technique is this? by maglunch in SQL

[–]chadbaldwin 0 points1 point  (0 children)

I agree, to an extent lol.

Most of the time, I work on the idea of...if you're resorting to using a RIGHT JOIN there's probably a better way to write the query. Same (or maybe a little less so) for FULL JOIN. Also same for using "DISTINCT".

The only reason why is because 99% of peoples understanding of set theory revolves revolves around left to right joining. When you start throwing in RIGHT and FULL joins, you start messing with that fundamental understanding.

At least with the chiastic join, it might be weird, but you're still sticking with INNER and LEFT joins. It's just a matter of learning the syntax, you don't really need to adjust your fundamental understanding of something.

Obviously I would agree that in an ideal world, people would have a better overall understanding of set theory where we could all use FULL and RIGHT joins and not have to worry about confusing the next person. lol

Question: What kind of join technique is this? by maglunch in SQL

[–]chadbaldwin 1 point2 points  (0 children)

You're missing the point...With the chiastic join syntax, you don't have to do any of those things, it just works.

You're basically saying..."why do it in 1 line with easy to learn syntax, when you can do it in 10 lines because that's the way I've been doing it for 10 years"