Press "Enter" to skip to content

Category: Learning

Tips for Navigating the Support Ticket Process

Published 2024-09-24 by Kevin Feasel

Kendra Little shares several tips:

Asking Microsoft for support for SQL Server or Azure SQL is a lousy experience these days. This is true whether you are using a cheaper service tier or the more expensive support tier formerly known as “Premiere Support.” Either way, I’ve found the same issues: as the person requesting support, I must know a whole lot about the root cause of my problem and how to solve it, or my request will be dismissed with misinformation. I need to have data and metrics that back up my claims in order to get the ticket escalated to someone who can help, and I will need to provide those receipts three or four times. Once something is escalated to the Product Group, I may get a helpful response, but it will generally take a while. If I’m not engaged directly with the Product Group and the answer is being relayed through a lower support tier, it often won’t make much sense.

These issues don’t happen due to bad work ethics or personal failings of support workers. These are good humans, who are trying their best! The problem is worse, because it’s systemic.

Kendra’s specific advice is around Microsoft and the Azure SQL family of products (SQL Server, Azure SQL DB, Azure SQL Managed Instance) but the advice is sound for much more than that. This advice will help you out when dealing with the support organization for pretty much any large company.

Leave a Comment

Core Concepts of Vector Databases

Published 2024-09-04 by Kevin Feasel

Brendan Tierney continues a series on vector databases:

In this post on Vector Databases, I’ll look at the main components:

  • Vector Embedding Models. What they do and what they create.
  • Vectors. What they represent, and why they have different sizes.
  • Vector Search. An overview of what a Vector Search will do. A more detailed version of this is in a separate post.
  • Vector Search Process. It’s a multi-step process and some care is needed.

Read on for more about these terms and ideas.

Comments closed

A Primer on Vector Databases

Published 2024-08-27 by Kevin Feasel

Brendan Tierney gives us an overview of vector databases:

A Vector Database is a specialized database designed to efficiently store, search, and retrieve high-dimensional vectors, which are often used to represent complex data like images, text, or audio. Vector Databases handle the growing need for managing unstructured and semi-structured data generated by AI models, particularly in applications such as recommendation systems, similarity search, and natural language processing. By enabling fast and scalable operations on vector embeddings, vector databases play a crucial role in unlocking the power of modern AI and machine learning applications.

It’s interesting to see this pop up as a standalone database type (e.g., chromadb), though we’re also seeing some existing players like Postgres support vector database functionality via extension.

Comments closed

Request: State of the Database Landscape Survey 2024

Published 2024-08-15 by Kevin Feasel

Grant Fritchey needs you:

Hello all! This post is nothing but a simple request. Please, if you have a few spare minutes, meander on over to this link and fill out the State of the Database Landscape Survey for 2024. Yeah, it’s for Redgate Software, my employer. But, really, it’s for everyone. Why is it for everyone? Because, every time we do one of these surveys, we don’t sit on the data, we share it. Here are the results from the 2023 survey, published earlier this year.

Yeah, but, I hear you opining, what does this really do for me? Well, let’s talk about it.

Check out the benefits and also fill out the survey.

Comments closed

SQL as a Language

Published 2024-06-26 by Kevin Feasel

Brent Ozar shares some thoughts:

I’m not talking just about Microsoft SQL Server specifically here, nor T-SQL. Let’s zoom out a little and think bigger picture for a second: is the SQL language itself a problem?

Sometimes when I talk to client developers, they gripe about the antiquated language.

Brent goes on to list some common complaints with SQL in general and explains why there isn’t a better solution.

I should note that he also summarizes Feasel’s Law near the end of the post:

Remember when NoSQL came out, and everybody was all “databases r doomd”? And remember what business users said when they wanted to run their reports? NoSQL persistence layers pretty quickly changed their tune, saying, “Oh, well, uh, we meant Not Only SQL, that’s what we meant,” as they struggled to quickly slap in SQL compatibility. Even MongoDB, king of NoSQL, implemented SQL support.

Comments closed

A SQL Saturday Survey

Published 2024-06-25 by Kevin Feasel

Steve Jones works with Steve Rezhener:

Steve Rezhener put together a survey for what topics you’d like to learn about. A few others, including myself, gave him feedback and he’s published this for people to use. It was intended for SQL Saturday organizers and speakers, but it can work well for anyone producing information. I’ve created some shortlinks at SQL Saturday that you can use to take the survey and see the results.

I’m promoting this because when I initially got the e-mail for it, I thought it was spam. With enough responses, this may help organizers focus in on specific topics for events, at least to some extent.

Comments closed

T-SQL Tuesday 174 Round-Up

Published 2024-05-23 by Kevin Feasel

I do a thing:

I thought about doing this in the normal Curated SQL style, where I grab a graf from each post. But instead, you get the second-best Curated SQL format: the hodge-podge bulleted list, but still in present tense and with a touch of commentary and the occasional rant.

Really, it should be “I did a thing” but I can’t go having that past tense nonsense here, now can I?

Thank you again to everyone who contributed. It was a lot of fun reading through all of these.

Comments closed

The Challenge of Developing PostgreSQL Features

Published 2024-05-02 by Kevin Feasel

Robert Haas talks about a development challenge:

Hacking on PostgreSQL is really hard. I think a lot of people would agree with this statement, not all for the same reasons. Some might point to the character of discourse on the mailing list, others to the shortage of patch reviewers, and others still to the difficulty of getting the attention of a committer, or of feeling like a hostage to some committer’s whimsy. All of these are problems, but today I want to focus on the purely technical aspect of the problem: the extreme difficulty of writing reasonably correct patches.

Read on for Robert’s experience developing incremental backups in Postgres. In fairness, I think this is true of any complex system which becomes mission-critical. It’s really easy to develop in low-risk, limited-code, greenfield environments. As you change each of those properties, development gets considerably more challenging, even if people are doing the right things the right way and checking ego at the door.

Comments closed