Voice of the DBA

Tag: software development

  • Polyglot Persistence

    I’ve seen the term polyglot persistence floating around Redgate a bit recently in the marketing department. I haven’t really seen this term anywhere, and I wonder if you have. If you have, drop a comment.

    The definition is based on the polyglot programming, where you write an app using multiple programming languages. I don’t know a lot of people who do that, and if you do, let me know. I guess some do, since I’ll see things like HTML+C#, or maybe something like Blazor + C#.

    In any case, the idea seems to be that you use multiple databases to satisfy your requirements. A few examples might be:

    • SQL Server for most data, Redis to cache shopping carts
    • Oracle for most data, ElasticSearch for full-text searching
    • PostgreSQL for profiles and leaderboards, MongoDB for real-time game actions

    I’ve tended to showcase NoSQL + Relational here, but I have seen a few people using two relational stores or two NoSQL stores because it suits their needs. The really common additions (for me) are some type of NoSQL store for performance with more stable, long term data in relational.

    I don’t think this covers the relational for OLTP and something else for OLAP/warehousing, as that seems to be an ETL/ELT/transfer of data over time for a different purpose rather than for the same application, but I guess it could cover that.

    I think Polyglot Persistence is a good idea, especially when you have complex requirements that aren’t easily solved with one database, even when you have in-memory or search/graph features in your database. Often those don’t perform as well as specialized systems, though there is a level of complexity and the challenge of ELT/ETL’ing the data to/from the second system.

    Evaluate carefully, PoC, and test at scale before you decide this is worth the trade.

  • T-SQL Tuesday #170–Abandoned Projects

    It’s the first T-SQL Tuesday of the new year. As we move forward, this month’s invitation is neat in that it’s looking back to learn how to move forward. I think while many people do look back, they don’t always use that information to move forward. This month’s host, Reitse Eskens, asks us about abandoned projects.

    As always, if you’re interested in hosting, blog, and then send me a note about hosting. I still have space in 2024.

    Abandoning a Project

    I’m sure that many of my employers started something and then abandoned it, and there are no shortage of projects I’ve abandoned myself, but nothing big springs to mind. Mostly I find my employers muddle through very poorly written, poorly performing projects and are very hesitant to abandon them.

    However, I will say that I have a couple things on my mind personally. This past December I completed the Advent of Cyber, which I wrote a bit about.  I actually got a certificate (of sorts).

    2023-12-28 16_08_10-Window

    That wasn’t abandoned, and I was glad I went through this, learning about a few tools.

    However.

    In the past, I’ve worked on the Advent of Code, and I’ve never finished it. I even built a repo, where I separated out puzzles by year. I invariably get a week in and then don’t have the time, and I struggle with coding out the puzzles. They get hard, and since this is a spare time thing, I run out of energy and interest.

    I do think, however, I learn some things. A few years I’ve tried to solve puzzles in PowerShell, Python, and SQL, which makes me translate logic, and think about the issues. SQL is hard, as a number of the puzzles are really iterative, and SQL isn’t great at iteration.

    I do learn.

    Even when I abandon projects, I get better at writing code and solving problems. It requires me to think, and it also teaches me things about how to look at a requirement and then write code. I also love the skill of building in tests to verify my code from the samples, which is a good skill.

    It’s an abandoned projects, and even as I write this, I feel like I should work on the 2023 puzzles a bit. I probably won’t because of time, but I do think starting and abandoning this project teaches you something.

  • Does Management Care About the Database?

    Many of the services that businesses use are taken for granted. In an office, management expects electricity, water, and heat just work. If they don’t, then often a crisis is declared and funds are spent to rectify the situation. I’ve been in businesses where any of those systems fail and usually, it’s very disruptive. I think these days a computer network is often seen as the same type of utility service where we take it for granted, but if it doesn’t work, it’s a crisis.

    Is the database seen as a service or is it more important than that? I think many software applications are different, and often seen as critical to business success, but I sometimes see both developers and management treating the database as a utility service. They just expect it to work, view it as a filing cabinet, and want to ignore it whenever possible.

    I think this is one reason that developers are often searching out new platforms, either cloud or NoSQL, because they want to keep the storage aspect of data simple and not spend time or effort managing data. Or they want to experiment with something they think is easier to use. Many developers like the idea of a schema-on-read, and sometimes use that to argue against another relational database and instead choose another platform.

    I think this is short-sighted, however, as the app now has the technical debt of supporting multiple schemas, and many of the databases using this format then suffer from one of two constraints. Either they store duplicate data for performance reasons, essentially de-normalizing their data storage, or they require some sort of ETL to ensure the data can be queried for analytics. Often schema-on-read isn’t efficient when querying across documents/keys/nodes/etc.

    There might be good news for many of us database professionals as an article talks about the boardroom starting to think about the database. To be fair, this is a sponsored article from Redgate, but it is based on a lot of research and feedback from customers that show how management is starting to treat the database as a strategic asset and not a common utility. Many executives are starting to realize that their data is full of value if it can be analyzed, and that the performance of these systems is important. We both need well-designed databases and well-written code, and we need to ensure that database development keeps up with today’s application changes.

    More and more of the customers I work with are finding their executives see more value in ensuring the database gets the resources to ensure it performs well, including better training for developers and better processes. It’s good to see more and more companies embracing modern DevOps development in both application software and database software.

    Steve Jones

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

  • The Code Review Checklist

    Early in my career as a developer, I was required to follow a formal process to get the code I’d written deployed to production environments. Each time I’d written code, I had to document what I’d tested and then print out the relevant sections of the codebase. I needed to find two other developers to spend 10-15 minutes with me in a meeting, going over my code, each of us with our own paper copy. Almost like a dissertation, I had to answer questions and defend my work, with problems being marked on paper for me to go fix.

    Over time, I learned that different developers reviewed code in different ways. Some spent more time on standards and formatting. Naming and the visual structure were more important to them, so if I wasn’t confident in my work, I’d pick them and spend time ensuring the formatting was correct. Or sometimes, I’d mis-format it, so they would tell me to go fix that and not look at what the code actually did. Others were better at examining algorithms, and I often used them to help me learn, with them digging into my logic and helping me understand whether I’d included enough error handling, considered edge cases, or written code that performed well.

    Often the mood I was in, and the pressure to meet a deadline might have me leaning one way or the other. Of course, there were plenty of times I just had to go with whichever two developers had time to review the code.

    There was an inconsistency in code reviews, and I breathed a sigh of relief in future jobs where we didn’t formally review code. In fact, in quite a few positions where I wrote C++, VB, or FoxPro/Clipper, my code was never reviewed, nor was there formal testing. Other developers and I often had to rework sections of code regularly, which led me to implement better testing of my own code. I didn’t adopt formal frameworks for some time, but I did save off test scripts for code in our Visual SourceSafe repository to ensure I could test code.

    These days pull requests and code reviews are commonplace, at least among many software developers. Not so much in the database world, but I do find customers that believe in testing and I regularly preach this to others. I’m also glad that Redgate has built-in static code analysis and linting into its products, though I wish we had better (and easier) unit testing support for database code.

    For those of you out there writing code, do you go through any sort of code review process? Is it consistent? Is there a checklist of sorts? I have found that different people have their own internal checklists, but I rarely see anyone with a more formal checklist, or even a set of lists for what to check in different types of code. Even in unit testing, I don’t often see people approaching their tests in a methodical manner.

    Checklists have been shown to be beneficial in the healthcare field where staffers are overworked and handoffs are frequent. Using a set of checklists can improve patient outcomes. I suspect that a good set of checks for code might do the same thing. However, I find that a lot of database developers are reluctant to adopt any formal testing practices.

    A view that reminds me of .NET and Java developers in the early 2000s.

    Do you have a checklist (actual or mental) that you go through for your own code? For anyone else’s code? Or do you think formal testing of SQL code is even worth the effort. Let me know today.

    Steve Jones

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