|
| Featured Contents |
| Question of the Day |
|
| The Voice of the DBA |
Daily Coping Tip Revisit a coping tip from the past and see if it helped you. I also have a thread at SQLServerCentral dealing with coping mechanisms and resources. Feel free to participate. For many of you out there working in a new way, I'm including a thought of the day on how to cope in this challenging time from The Action for Happiness Coping Calendar. My items will be on my blog, feel free to share yours. |
The Challenge of New Platforms I saw a customer asking about Exasol recently, which is an in-memory, columnar database. I know nothing about it, and it might work great, but we don't support it. I didn't think much of it, as I'm sure the customer has a reason for choosing this platform. Later, however, I wondered if this was a good idea. Another customer had inquired about Knack, which I had never heard of either. Not only that, it's an online database that appears to assemble its "tables" from data stored in other systems. Strange, but I'm sure it works well for some companies, especially those without many software developers. I often find there are developers, or even analysts, that find a new platform that appears to work better for their particular problem. Sometimes they're excited, sometimes they have some experience in the past, but there seems to be a regular push to add new types of technology to many organizations. Often technology that isn't substantially different in function from something that already is in place. Whenever you add a new technology to your organization, you are adding more than the capabilities. You are also adding the support of this system, which means not only training end users, but also training the staff that has to support the software. If you do this too often, you risk having staff that don't know how to keep things running efficiently. This is why we rarely see companies changing their core database platform. The change is a big disruption. What's more, our staff is not consistent across time. People come and go, and finding new people can be hard. Especially those that know all of our technology stacks. I appreciate and would like to see more customers working with new platforms, but I also think this has to be something an org considers carefully. After all, many software companies limit the number of products and versions they support for this very reason. There's also the problem of technology becoming end-of-life'd. While we might think database platforms are around forever, some of them have disappeared over time, and even if they exist, support goes away. We might find ourselves with the need to upgrade multiple platforms, each of which requires different knowledge. Our staff might spend a lot of time learning and practicing upgrades for disparate platforms, knowledge that doesn't transfer to the next upgrade. I am not advocating for everyone to run SQL Server (or PostgreSQL or MySQL or DB2 or Snowflake, etc.) I do think there are reasons why we might choose to use Synapse or Teradata instead of an Oracle database. However, I think the list of platforms ought to be limited in some way. Just like our list of programming languages should be limited. Having a handle on our domain of skills makes it easier to find, train, grow, and build knowledgeable staff. Adding to the list ought to be done slow and carefully, after some debate, discussion, and voting. I am glad that there are so many RDBMS platforms, and NOSQL platforms. It's great to see people building new and improved databases. This work is how we get amazing datastores like Neo4J, Redis, and ElasticSearch. At the same time, I do think caution about adding new platforms is warranted inside of organizations. Reusing the knowledge we have should be the first thought, with the decision to grow based on a true need, not just someone's desire to play with something new. Steve Jones - SSC Editor Join the debate, and respond to today's editorial on the forums |
|
| Featured Contents |
