Voice of the DBA

Tag: misc

  • Typing Alternative Characters

    I tend to work in the US English world. I’m somewhat embarrassed to note that I really only know one language and most of my work has been with US centric industries. I’ve rarely had the need to deal with Unicode and most of my databases have used varchar() everywhere. However, I know a little about nvarchar and am trying to be better about becoming familiar with using these structures.

    Recently I was working on a piece and needed to type a £ character. If I were on one of the Redgate demo systems, that would be no problem. There’s a key for this character. However, I’m a US centric guy on a US system.

    I could have cut and pasted the character, but I was wondering if there was a way to type it. There is.

    You can use ALT codes to type the Unicode character. In this case, it’s 0163, so you can hold down the ALT key and then type  ‘0163’. Doing that gets you £.

    Pretty cool.

  • The Travel Review

    I got a note from United this week that summarized my travel for 2017. I’ve been feeling a bit itchy as I haven’t had any trips scheduled for 2018 so far. Strange for me, but looking over the summary, I’m glad.

    Last year I flew 44 times with United, for 81k miles. I had 25 domestic flights and 19 international ones. That’s kind of crazy. Of course, outside of Denver, London is my most visited location.

    For hotels, I logged 26 stays with Hilton that totaled 62 nights. That was low because I got stuck in a few other hotels at events early in the year. Plus I think I had 8 or 9 Air BnB nights. A lot of time away from home.

    I’m a numbers person, so it’s neat to see the summaries from the services I use.

    The one big number for me that shows me I traveled too much? Total workouts for the year: 265. That’s way too low.

  • It’s the Engineers

    There are all sorts of articles and blogs on the Internet that try and teach you how to use a particular technique or technology to solve a problem. Plenty of this information is well written, and showcases the knowledge of that individual (or team) and how they’ve built a fantastic system. Every vendor building software platforms has reference case studies that show how well their system has worked for some customer. These are all good models that might give you confidence why SQL Server or MongoDB or Entity Framework or GoLang are good choices for your company.

    In reality, it’s not as simple as just choosing a platform or framework or language to make your application perform better. You really need the staff that understands how to use your choice of X and has some skill in building a system in that manner. It’s why I think that the cost of the software is a pittance compared to the cost of your people. If you have to train them, or they need to learn how technology X works, then you’re going to pay more in salary than you’d save in software licenses.

    There’s an article that I think illustrates this well, and might be worth passing along to your developers. It’s called Why Amazon DynamoDB isn’t for everyone and it’s worth a few minutes of your time to read. The gist of the article is that a NoSQL system, like DynamoDB, isn’t as simple and easy as you expect. It also says that for many applications, a relational database is a better choice because it’s often better understood and will solve most problems at small scale. For most of us, we don’t really get past what I’d consider small to medium scale, and so we should stick with relational systems.

    This isn’t to say that DynamoDB will be a problem for you, but there will be a learning curve for your developers if they haven’t used it in production and at your scale. The same thing occurs if a development team decided to switch from MongoDB to SQL Server because they like automatic tuning. They won’t necessarily configure and use SQL Server efficiently, and might not have their application perform well. Switching your development paradigm or technology is hard, and it will take time for your staff to get up to speed.

    Ultimately it really comes down to having good engineers that can write good code and understands the ins and outs of administering that particular platform. The database is extremely important here as it is the central location of your information, but the same arguments apply to frameworks and languages. As much as we want to learn and try new technologies and incorporate them into our work, we need to realize that it takes time to learn to use them well. Make small experiments, try POCs and slowly build up skills before you decide that your mission critical system needs some new technology that you read about and are excited to try working with.

    Steve Jones

    The Voice of the DBA Podcast

    Listen to the MP3 Audio ( 4.1MB) podcast or subscribe to the feed at iTunes and Libsyn.

  • Happy New Year 2018

    It’s the start of a brand new year, and hopefully many of you are not anywhere near your work today. I hope to be running a 5k this morning, so I’m up early, at my usual time for work, getting ready with a jolt of coffee before a nice jog. I haven’t run a lot the last few months, so I’m just going for fun. I’m writing this early, so if the weather is bad, I’ll likely go to yoga instead.

    In any case, this is usually a day off for most people working with data, so I hope you enjoy yourself with a quiet day before we begin the new work year tomorrow. I’m excited, with less travel, to tackle some projects around SSC. We are looking to upgrade hardware and software, moving into the new era of SQL Server, maybe even with graph tables! If there’s something you’d like to see, apart from bug fixes, let us know. I’ll be meeting in the next few weeks to lay out a direction and try to get moving forward.

    Happy New Year!