By: Betty Plummer, Software Developer
Pharmacy software generates a lot of data. It needs to be saved (or persisted) for reference or reporting. The gold standard for the past few decades has been to use a relational database, where data is pulled apart and stored in tables as related bits that can be put back together in different ways, depending on the questions (queries) being asked.
The heavy hitters in the relational database world are Oracle (Oracle Corp) and SQL Server (Microsoft). They are robust and solid – SQL Server has caught up to Oracle in its past few releases, and can now match it in performance and reliability. They have different editions, from express to standard to enterprise, depending on how much power and scalability are needed, the features you want, and how much you can spend. With the popularity of these two database systems, I would venture to say that in the course of your day you probably access software programs that depend on SQL and/or Oracle for data control.
Oracle has been around since the 70’s and is the most popular and recognized relational database. It’s also the most complicated to set up and maintain, and is the most expensive to license and develop against. I have 16 years of experience with Oracle and (by now) find it fun to work with – ordering it around via command line, crafting queries using SQL script or PL/SQL (Oracle’s compiled language for writing code and SQL inside its memory space), and tweaking query performance. In software development, it’s an architectural choice of where to place business logic – in the application or in the database. With Oracle it’s convenient to write functions and procedures in the database that run complicated queries incorporating business logic. There are vendor-specific features that make PL/SQL very efficient, such as cursors, where a query returns a set of data and then operations can be performed on each individual row. Slick and productive.
SQL Server is a close second to Oracle. It is easier to get a SQL Server database up and running, and licensing is less expensive (although the enterprise edition can get up there). Development proceeds more quickly, partly because of the less-complicated architecture, and partly due to help from its development community, which is vibrant, and not only online. I’ve been to SQL Server events that are run by volunteers, with talks and demos given by people anxious to share their experience with some aspect of this database.
My first experience with SQL Server was driven by my Oracle background. I looked for similarities and found many – data in both is accessed using SQL, although both vendors have their own custom features. Case in point, a great favorite of Oracle developers is the DECODE statement – sort of a one-line IF-THEN-ELSE that is performed in a query. SQL Server makes you write out a CASE statement, and while that usually gets things done, c’mon – I want my DECODE.
It’s also common in SQL Server to run multiple databases on a server. In most Oracle installations I’ve worked on, the limit is one (production) database per server. SQL Server also doesn’t have a compiled language comparable to PL/SQL, but what they do have might be better, depending on your point of view. Microsoft’s C# and VB.NET languages have deep tie-ins to the SQL Server database; they are, after all, from the same vendor. So in a C#/SQL Server shop, for instance, the business logic usually ends up in the software application instead of the database, because from there data can be retrieved and worked through more efficiently (some would say) than if managed solely in the database.
SQL Server also has procedures and functions. It even has cursors; however, they are slow and not recommended (there is a snarky acronym describing cursor performance – RBAR – pronounced ReeBAR – stands for Row By Agonizing Row).
So does it matter which database is used to hold your data? After considering licensing, platform (UNIX vs Windows), usage (standard storage vs strength for a warehouse), and developer talent, probably not so much. The religious wars of Oracle vs SQL Server are becoming irrelevant. But you really only get a choice for new development. Existing applications are built around their existing databases, and the return on investment for changing that database is low.
And… it’s not necessary. What’s more important is how data from these different databases is used together to provide more insight into pharmacy operations, and to manage inventory more efficiently. Business Intelligence tools are taking the next step from static reports. They provide a window into the database, allowing customers to ask their own questions, and design their own reports and dashboards.
So instead of knowing where the data is, the question should be – how has it been made available to you? You know your business best, and you know the right questions to ask. The answers are out there.