Author: way0utwest

  • Being Mindful of Design Time

    Over the last few years, I’ve worked a lot with various customers on finding better ways to build database software, often using the principles of DevOps to drive the change. A lot of managers and leads want to see a smoother process to help their teams become more efficient. DBAs often want less overhead and friction in the process, while developers just want to deliver code.

    In many cases, however, what lots of management wants is speed, and they’re looking for ways to increase their current speed and deliver more software. Their current rate of development might be quick enough if you can reduce your bottlenecks. Making communication easier, limiting the slowdowns from handoffs, and reducing the risk of mistakes are everyone’s goals.

    However.

    What I see too often is that both their current process and the new one are often lacking fundamental database design and modeling. Developers aren’t well-trained and make design decisions based on an (often) incomplete spec. They alter schemas to fit the immediate challenge, without thinking about the future. Good database modeling considers the often unasked questions and unspoken rules of the problem space.

    Moving to a smoother process that allows code to be merged, tested, and released in a quicker fashion is great if you are writing good code. It’s less great if you aren’t. Most of us have a lot of poorly architected schemas and don’t need more challenges from more bad designs or bad code.

    I wonder how much time most of you spend on database modeling? Do you try to out more than one design? In this podcast, John Ousterhout talks about designing a system twice. He tries to get his students to come up with a second idea for a problem, which often brings out a better design. I wonder if this might not be a good idea for database modeling as well.

    I’m sure most people do their best to build a good data model, but experience often teaches us that the way we decide on a table structure, data types, keys, indexes, and more changes as we learn more. Our experience can help us make choices that perform well over time and don’t limit flexibility.

    Is design an important part of your development process? Do you have guidelines for your organization? Do you consult more experienced database people? Or to inexperienced people ask you to review their choices? Building a more efficient software development process should help you to move code to production more smoothly, and therefore quicker, but it shouldn’t be used to deploy more poorly written solutions. Take the time needed to implement well-designed and tested code, including your database code.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • Advice I Like: Failure

    If it fails where you thought it would fail that is not a failure. – from Excellent Advice for Living

    This is a great quote, especially for those of us working in computer systems. We often design things like HA (which I wrote about this past week), circuit breakers, and other techniques to handle problems we know about.

    When those things occur, we’ve planned for them, so I get that these are not a failure. In fact, they are a known case we’ve designed for.

    The same thing for me, if I am building something on the ranch. If I put in a post and don’t cement it, and then need to add a wheel to a gate (ask me how I know this), then if the gate leans over, it’s expected.

    On the other hand, if the piece of metal holding the wheel on fails, that’s a failure. I expected it would keep the wheel on, but apparently, it isn’t engineered well enough to handle a load from a slight slope. Sad smile

    I’ve been posting New Words on Fridays from a book I was reading, however, a friend thought they were a little depressing. They should be as they are obscure sorrows. I like them because they make me think.

    To counter-balance those, I’m adding in thoughts on advice, mostly from Kevin Kelley’s book. You can read all these posts under the advice tag.

  • Internal Staff Growth

    Imagine that you are about to tackle a new project that will take more than a year. This might be a new system, perhaps a cloud migration, or maybe it’s rewriting something that doesn’t work well. You don’t have enough employees to undertake the project without overloading everyone. Your team needs to grow.

    Would you rather hire a more senior person from outside the organization or pick a junior person that’s already inside your company and teach them what they need to know? Think about this as if you were the one making the decision about the future direction of your software team. Philosophically, do you want to buy experienced people or train/build new ones from your internal staff.

    It’s an interesting idea and for a lot of companies, I see them looking outside the company first, rather than investing in, and training, their internal staffers to grow. It takes time to train and grow people, for sure, and it’s a constant investment that never goes away. At the same time, bringing people in from the outside also requires some level of training on how the current systems and org work, even if the new hire has a lot of experience.

    I think there are good reasons to look at both of these, but my view is that I want to have people on a team that know how to work together. The tech skills (or design, modeling, etc.) can be taught, and I would rather have a good cultural fit, already knowing how a person fits with others. That assumes I’ve got good employees who fit together and believe in our culture. That’s hard enough to do, which is why I want to hire people who can work as a team and keep them. Part of the “keeping” them is investing in them.

    This also means that if people don’t fit in, I want to help them move on to a better fit.

    This doesn’t mean I want everyone to think the same. It is important to have a variety of views on how to design and build applications. A variety of people is important, but we have to be a team.

    I prefer to train and invest in the people I have over bringing in more experienced staffers. A big part of why I feel this way is that hiring is always a gamble, and it seems we make no shortage of mistakes. If I do get it right, then I want to grow and keep those people around for the long term.

    Steve Jones

    Listen to the podcast at Libsyn, Spotify, or iTunes.

    Note, podcasts are only available for a limited time online.

  • SQL Server 2025 RegEx and AI

    One of the language changes in SQL Server 2025 that I’ve seen a lot of people mention is the addition of RegEx functions to T-SQL. I decided to take a few minutes and try to examine how this feature works, and how I might use it. And more importantly, can AI help?

    This is part of a series of experiments with AI systems.

    Data with a Bit of a Pattern

    One of the common things people use Regex for is validating email addresses.

    I created a basic table in a database that looks like this:

    CREATE TABLE customer
    (
         customerid INT NOT NULL
             CONSTRAINT CustomerPK PRIMARY KEY,
         customeremail VARCHAR(200),
         validated TINYINT
    )
    GO

    I then asked PromptAI to get me some test data like this:

    2025-11_line0142

    I wasn’t connected to a database, but I still got code generated with insert statements. The AI also noted I had a “validated” column, and it populated that appropriately: 1 for good email, 0 for bad ones.

    2025-11_line0143 

    Once I run the inserts, I have data.

    2025-11_line0145

    Now, can I check that the AI did this correctly?

    REGEXP_LIKE

    In SQL Server 2025, there are a number of regular expression functions, and REGEXP_LIKE is one of these. This function is designed to return a boolean if the string_expression matches the pattern_expression, where the latter is the regular expression.

    2025-11_line0146

    Prompt sees this as a valid function for SQL Server 2025, which is great. I want to use the customeremail from the table as my string to check. For the regex, I need to create a regular expression, something I am not good at doing. I learned to do this at a very rudimentary level when writing Perl, but I’ve lost whatever little skill I used to have.

    I saw an expression on StackOverflow for validating email. Let’s check if an AI can help.

    2025-11_line0149

    In a few seconds, even on airport wi-fi (SFO as I write this), I get a response.

    2025-11_line0150

    This looks like the expression from the SO answer, though much shorter. If you read SO, you know that the format isn’t as set and stable as we’d like. In any case, let’s see what this shows.

    This is interesting. I get an error.

    2025-11_line0152

    If I look at the docs, this says it returns a true/false, which I’d assume would convert to a 1/0, but let’s try an explicit case. When I do this, it works.

    2025-11_line0153

    I can also do this in the WHERE clause, where the true/false thing just works. Let me move the function to the WHERE clause. If I do that, I have this code:

    SELECT customerid,
            customeremail,
            validated
    FROM dbo.customer
    WHERE REGEXP_LIKE(customeremail, '^[A-Za-z0-9._%-]+@[A-Za-z0-9.-]+\.[A-Za-z]{2,}$')

    When I run this, I see what I expect:

    2025-11_0136

    Not a bad enhancement to the T-SQL language.

    Summary

    There’s a lot written on RegEx, so this post isn’t intended to delve deeply into what RegEx expressions you choose. Rather, I wanted to show the basics of this REGEXP_LIKE() function, and showcase one of the weird things I found when including this in the column list. I also haven’t looked at performance yet, though that certainly is something to be concerned about with larger datasets

    There are other changes in SQL Server 2025, and I’ll try to examine some in the coming weeks.