 |
Featured Article
The End of SQL?
by Matthew Zito, Chief Scientist
DBAs wear a wide variety of hats today — designer, tuner, systems manager, etc. However, the most fundamental responsibility of the DBA has traditionally been to be the keeper of the data model and the SQL used in the enterprise applications. While developers were often given the ability to write SQL, in the end, it was the DBAs responsibility to make sure that SQL runs fast — either by tuning the database, modifying the data model or rewriting the SQL.
The challenge of this, of course, is that the DBA becomes a highly skilled, difficult to find IT person. Even more challenging is finding a DBA that can help manage the data model for developers while still performing their day-to-day operational activities. The result is a world where many organizations have less than optimal SQL and data models, but are still spending a disproportionate amount of time managing them.
There is a growing shift now to address these problems by removing the DBA from the SQL development process, or at a minimum, streamlining the DBA's involvement. This is also part of the transition towards abstraction computing — technologies such as XML, Web Services and even the buzzword-compliant SOA, where computing services communicate with each other, abstracting the business logic and data model from the interactions with other systems. In the same way, there are a number of technologies that help abstract the application or its code from the database underneath.
Two very common database abstraction software packages for the Java world are Hibernate and Toplink. Both of these tools provide a mechanism for Java objects, which have variables and relationships with other objects, to be mapped onto a relational database while maintaining their relationships and the functional structure of the objects. The idea is Java developers can now focus on their particular data model at an application level (ie. a ShoppingCart object contains many Items, each with a SKU, etc.), without needing to worry about the underlying schema which can be managed using SQL queries. In an ideal world, it would create "perfect" schemas and SQL that would be completely high-performance and optimized for the particular application workload, but that is simply not realistic with today's technology. However, these types of tools can handle the broad swaths of non-performance critical database accesses, leaving the DBA or the developer to focus only on the queries that need to be optimized. The idea of object-relational persistence is important enough that a standard has been developed, the Java Persistence API, which is part of the EJB 3.0 standard. Java Persistence API is a generic, vendor-neutral persistence and mapping layer on top of any underlying data source.
The next level of data abstraction comes with newer web application technologies, such as Ruby on Rails. Rails is a framework atop the Ruby programming language that is designed to allow developers to rapidly create simple data interaction applications. The core idea behind Rails is that many of the applications an enterprise needs can be small, single-function applications, such as an inventory management system, a ticketing system or an HR application. By making these applications very simple to build and deploy, it creates an ecosystem of applications that serve single purposes. The next version of Rails will allow these applications to seamlessly pass data and business logic between them as part of creating a "mesh" of applications. Ruby on Rails fits into the shift from SQL and data modeling to data abstraction through their use of an "ActiveRecord". An ActiveRecord is an object that has dynamically created properties based on the schema it is tied to. For example, a developer can define an object, saying, "A ShoppingCart has many items, and belongs to one user", and the relationship, both at a schema level and within the application, is dynamically created. Again, there will probably be a need to interact directly with the SQL for specific queries or queries with performance demands, but there are many low-throughput applications that can benefit from rapid deployment.
The last, and newest, way of removing the need for a DBA's help with schema and SQL has to do with the emerging Software-as-a-Service industry (SaaS). With Software-as-a-Service, the application is hosted and delivered over the Internet, with administration and functional responsibility managed by the provider. This obviously removes the need for a customer DBA to manage the database, but recently, SaaS providers have started providing tools for developers to build extensions and new applications atop the existing application. Salesforce.com, arguably the leader in this space, has built a completely generic framework for building enterprise applications atop their infrastructure that requires no schema design or SQL. The developer (or business person, in many cases), simply creates new objects and the type of data they contain, and the Salesforce platform insures that it is always available, high-performing and internally consistent. With this world, the only need for a DBA is to help the business understand what data they want to collect.
Of course, it’s probably premature to say that Salesforce.com, Toplink and Ruby on Rails are the end of all SQL tuning, schema design and the role of the DBA themselves. But it is clear that there is an increasing amount of effort to streamline the process of managing data at a number of different levels. From toolkits for Java applications, to an abstraction framework for web applications, to a complete on-demand data platform, more and more ways to minimize the role of a DBA are being built. DBAs need to add value at a business level, by helping organizations get more value, performance and intelligence out of the massive amounts of data being created – when they can do that, there will always be a place for them in any IT shop.
<< back
|
|
