Inside IBM DB2 Viper
A technological marvel, IBM's new XML-powered server aims to change the face of database storage
Statistical views are another scalability feature in DB2 9.1. Ordinarily, the query optimizer uses statistics to estimate cardinality of the data stored in tables, and this is one of the major factors used to determine an execution plan for a given query. Statistical views extend this capability to views as well, which means that now views are not only considered to be derived tables, but they’re actually treated more like tables. IBM isn’t the only one to consider blurring the line between views and tables, but it is the first to implement it.
Label-based access control
Oracle has had advanced, row-level access control since Version 8.1. DB2 9.1 is catching up, albeit with a slightly different method. (Unfortunately, SQL Server doesn’t have similar functionality at all, and I hear that it’s not even being considered for the Katmai release next year.) Although the traditional methods of controlling access to row-level data (views and stored procedures) are still in play, DB2’s LBAC (label-based access control) gives you much greater reassurance by preventing users from circumventing your security measures.
For instance, using traditional access control, you could create a view that specifies that a certain user can only see customers in a certain region, or only a certain column in the customers table. A user who knows the name of the base table, however, can just query the table instead of using the view. With LBAC, on the other hand, you can specify a security policy to control access to specific columns or even specific ranges of rows.
Other databases can achieve something like this level of security using the traditional methods. The difference is in the level of administration involved. With traditional methods, for example, you can create a stored procedure to give a group of users access to data. If another group comes along you can write another stored procedure to give them the access they need as well, and so on. You have to keep up with all of the procedures you’ve written and track which groups get access to each one, but the advantage is that one stored procedure doesn’t affect the other ones -- it doesn’t take much planning.
With LBAC, you really have to plan how you want the security policy to play out. If a group comes along that needs different access, you might need to redesign your whole policy to make it run well. But for the long haul, the LBAC approach requires much less ongoing administration, because all the work is done up front. You don’t have to worry about keeping up with stored procedure versions and the like. Each approach has its place, and it’s my guess that shops employing LBAC will find themselves using a combination of both methods.
Reduce your data
DB2’s new row-level compression is one of my favorite features. It’s actually table-level compression and it can result in a direct storage savings of 45 to 75 percent.
I performed an initial benchmark just to get an idea of the performance difference between two identical tables, one that was compressed and the other that was not. I found that the performance between the two was close, but the compressed table often actually performed better than the uncompressed table (presumably because more of its data fit in memory).