Tech Tips: Why Linux/Unix is perferable to Windows for Multivalue DBMS servers
In any business, we must often solve complex problems with creative solutions. To do this effectively and efficiently, we need flexibility in our systems and a wide variety of tools. We also prefer a low cost of operation, low cost of ownership, and a track record of exceptional performance. It is my opinion that Linux possesses these qualities in greater number and quality when compared to Windows in the context of a DBMS server. I’ll include a few example problems that I’ve encountered and explain how we solved them in a Linux or Unix environment. To solve these same problems in Windows, the typical answer is one of the following: Purchase and install a proprietary software package that does, more or less, what you need, or pay a developer to write new software that does exactly what you need.
Example 1: Initiate a DBMS process that exports a file, and transmit that file to a third party. This must be automated and performed periodically.
This, in my opinion, is the most common problem we encounter. Examples of this include sending statements to customers via email, transferring phone numbers to a dialing service via sftp, and notifying system administrators of backup results.
In cases like these, we set up a scheduled task in cron that executes a shell script (or Perl or PHP). The shell script can initiate a DBMS session, execute a command in the DBMS that runs the data export program. After this process returns control to Linux, the script can execute the mail command to send the file via email. Alternatively, the file could be transmitted using an scp command.
This works in reverse, as well. Files can be retrieved from other machines, locally or across the internet, via a variety of protocols, and then processed by a combination of Linux tools and DBMS software (UniBasic). Tools like grep, sort and cut can be used effectively to reduce the volume of string operations in the DBMS.
Example 2: Trigger periodic DBMS operations from outside the DBMS
In this service-based economy, I find customers are asking for service-oriented software. This usually involves writing two processes: one to process requests, and another to deliver results. The software processing requests is typically invoked by the end user. Processing these requests and delivering results should be automated by the system.
Historically, the DBMS has had a lackluster job management scheme. Cron, on the other hand, has rarely failed me. This is another case where we use cron to initiate a process in the DBMS that looks for unprocessed requests, processes them (or initiates the process that does the work), and then scans for completed jobs, and delivers the results (via email, scp, web interface, etc).
Example 3: Interface the DBMS with popular web services
This is a little different. Allow the DBMS server to populate a Twitter feed, or use another web service to communicate with the outside world.
In this case, we can initiate Linux commands from within the DBMS environment. A DBMS process, whether initiated by a user or by a job manager, can build a script, or execute directly, an HTTP tool such as wget to interface with web servers across the internet. Using this mechanism, your DBMS server could log successful backups or critical errors on a Twitter feed, or utilize other web services.
Finally, I will add that, because Linux is an open system with freely available development tools, there are nerds around the world creating innovative products for it every day. Want to create PDFs using your DBMS software? There’s a library for that. Do you want to do that new thing that’s taking your marketplace by storm? You can wait for Microsoft, or you can put the pieces together yourself in Linux. I’m not saying that you can’t do all of these things in Windows. I’m saying that the glue for assembling solutions in a Linux/Unix environment is at once more flexible and stable, and it costs a lot less.
Dave Bucklin is a Technical Account Manager at The Nerdery. You can learn more about him in the Periodic Table of Nerdery.
