Voice of the DBA

Category: Editorial

  • Republish: It’s Not Yours

    I’m still at Techorama.

    Check out It’s Not Yours from the past. For some reason I didn’t get it on this blog, so here it is:

    It’s Not Yours

    For most of my career, I’ve felt a tie to the systems I’ve managed or the code I’ve written. I’ve often said that a part of the code was mine, because it was something I’d written. Having some ownership of your work has often meant more pride in ensuring things are well implemented. The same thing goes for administering databases. When an employee feels personally responsible and accountable for  the database and its contents, usually they do a better job.

    Most of us know that the systems we manage and the data they contain aren’t really “ours”, no matter how we might refer to them in conversation. We know that ultimately the data, applications, and hardware belong to our employers. Or, we should know that.

    Apparently not everyone does. A contractor just pleaded guilty to stealing classified information from the US National Security Agency, about 50GB worth of data. This isn’t a case of spying or malicious intent. Instead, the report is that the employee was a hoarder, just keeping copies of data for some unknown reason. Hopefully that’s true.

    Many of us will have copies of data that we use for different purposes. We might be building software, or testing queries, or some other task that requires data. We might want to conduct more in depth analysis in our spare time. Those are all positive goals, but none of them mean that we should have copies of data without authorization. We don’t own the data, and we should always be sure if we are moving data to other systems, that those systems are secure and someone else has approved the action.

    This becomes more important all the time. We have enough issues with data security and keeping our information away from hackers. We make plenty of mistakes with configuration in authorized development and test systems. There’s no reason to add to the issues by treating data as our own personal asset, no matter how good your intentions.

    Steve Jones

  • Republish: It’s the Engineers

    I’m in Belgium today for the start of Techorama.

    You get It’s the Engineers to read while I’m learning something new.

  • Republish: Job Interviews: What is Normalization?

    Traveling today, going from the UK to Belgium. Fingers crossed that the trip is smooth.

    I’m republishing Job Interviews: What is Normalization? today for you to read.

  • The General Database Platform

    It’s been a decade-plus of the Not-Only-SQL (NoSQL) movement where a large variety of specialized database platforms have been developed and sold. It seems that there are so many different platforms for data stores that you can find one for whatever specialized type of data you are working with. However, is that what people are doing to store data in their applications?

    I saw this piece on the return to the general-purpose database, postulating that a lot of the NoSQL database platforms have added additional capabilities that make them less specialized and more generalized. I’ve seen some of this, just as many relational platforms have added features that compete with one of the NoSQL classes of databases. The NoSQL datastores might be adding SQL-like features because some of these platforms are too specialized, and the vendors have decided they need to cover a slightly wider set of use cases.

    It also could be that some of the features of the relational database, which are certainly a general-purpose data store, are demanded by customers. I personally think that many problems are solved well by the RDBMSes out there,  and if you need something specific, then add on a NoSQL document, graph, time-series, or other type of database for some part of your application.

    A lot of organizations have moved to using multiple data stores in applications. I see it more and more from customers I deal with, often because there is a specialized need, like Redis for caching, that just outperforms the main database for a certain function. As long as it’s easy to integrate, why not use a second database platform in your application?

    I don’t know that you want to keep adding specialized systems, however. As the article notes: “the overhead today of having to learn and interact with multiple databases has become more burden than boon.” That can certainly be the case when there are a lot of platforms and your staff changes on a regular basis. We’ve seen this become a burden when there are too many versions of a database platform. Supporting these is hard and learning about all the features is a challenge for developers. Building expertise in many areas is sometimes very difficult for an organization.

    My guess is that the future will continue to be applications that use one data store, but the trend is away from this. Especially as more organizations start to use the cloud, I suspect a lot of companies will use a specialized data store for some part of their data. They’ll also be more likely to use a second platform for a data warehouse or analysis platform. With cloud vendors building easier data transfer capabilities, like Synapse Link, I do expect more customers to take advantage of these and use a second, specialized platform where it makes sense.

    I like the idea of specialized platforms and systems. I do think that there are some problems that are not well suited to being solved by relational structures. However, I also think that for a lot of critical transactional systems, it’s hard to get away from a relational store.

    Steve Jones

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