To no one’s surprise, the news came out today at the PASS Summit in Seattle that Microsoft has released a preview of the next major release of SQL code named Denali. Once released, this new version of SQL Server will replace SQL Server 2008 as Microsoft’s premier relational database server product. This is an important announcement if for no other reason than the fact that Microsoft SQL is the most common SQL database and ranks third after Oracle and IBM in sales revenue. One senses that the actual release date is rather distant as Microsoft has been mum on that question.
The new features that Microsoft is touting for Denali include the “Apollo” column store technology to speed database queries; the “Crescent” database visualization and presentation solution; the “Juneau” single development portal for data and application developers; and the SQL Server “AlwaysOn” feature which is an analysis, troubleshooting and configuration solution designed to reduced database downtime, increase performance and solve other problems.
All of this seems likely to remain transparent to the uniPaaS developer and application users will undoubtedly notice performance and reliability improvements but not much else. It should be noted that uniPaaS has high speed native gateways for MS-SQL, Oracle, DB2, etc.
The uniPaaS application platform allows developers to quickly develop SQL applications for business data processing. uniPaaS allows for both deferred and physical transactions to the SQL database. With batch tasks physical transactions are the default whereas with online transactions deferred transactions are the norm. But the developer has the power of choice on the preferred method.
With deferred transactions in an online program, the developer can choose to defer the transaction for the entire task or record by record. There are also options for nesting of deferred transaction and for a deferred transaction within an active transaction.
When a uniPaaS developer selects to begin deferred transactions “before task prefix” they are deferring the entire task. If you defer the transaction “on record lock”, then the deferral is on a record-by-record basis. The transaction begins when you lock the record and you have options for when that happens. Record locking strategies can be set as desired. You can choose before record prefix, before record suffix or before update. Each of these lock the record for successively shorter durations but also have increasing levels of record exposure where an earlier lock may have prevented the situation that record locks are designed for in the first place.
On the other hand, there are numerous situations where transactions and locking aren’t needed at all, the most obvious example being when all you need to do is view the data. Also, remember that transactions and locking on a record-by-record basis is going to require more processing time than at the task level. And with batch transactions, you have an intermediate option to define a group, such as every 100 records or every 1000 records.
Of course the options for dealing with transactions in uniPaaS for SQL databases just barely scratches the surface of all the nice data-centric application development capabilities that uniPaaS provides. The data view repository, data models, SQL functions and data discovery features of uniPaaS could be a discussion unto themselves.
As uniPaaS is increasingly viewed as a mainstream .NET development platform with cross-platform capabilities, I suspect many of the Denali users will be drawn to uniPaaS for its rapid development capabilities and reputation for rock-solid reliability.
No comments:
Post a Comment