Moran: I'd like to get your perspective on Oracle and IBM. The shared-nothing model isn't Oracle's strong point, and Oracle would have trouble migrating to that model. Regarding IBM's technology in the shared-nothing model, it seems that there's a resurgence of popularity of DB2 on NT and that DB2 has some better management credentials in place because IBM has been doing this longer than SQL Server has.
Flessner: First, Oracle doesn't have shared-nothing technology. They have this hybrid thing they're caught in the middle with called shared-disk.
Moran: And that doesn't scale in a particularly graceful way.
Flessner: Oracle has to decide whether it's going to move the shared-disk model forward or justify it.
Moran: Oracle has the buzz in the database market. Oracle is perceived as the leader, especially in the e-business space. But as I look at the technology, I think that some technologies that Microsoft is coming out with and some that IBM has had all along are superior to Oracle's architecture. Has there been a shift in mind share to Microsoft and IBM from Oracle? As true scalability becomes more important, will the shared-nothing issue drive that shift in mind share?
Flessner: I'm certainly pointing the ship in that direction here. Although IBM has had shared-nothing technology, the company has been focused on decision support, not OLTP, and that's restricted them. Believe me, if they had OLTP working for scale-out...
Moran: ...they'd have their TPC numbers published already.
Flessner: A long time ago. So, IBM doesn't have it figured out yet, although it's making progress. Quite honestly, I think IBM will do a good job. Informix [Software] is the same way. They had it figured out for decision support but not for OLTP, so Informix hasn't published yet, either. But I believe it's pretty clear both from a pure scalability perspective and from a pure economic perspective that scale-out is going to win. Think of the poor operations person who has just been to the board of directors and gotten a capital appropriation approved for a $4 million Sun box and said he wouldn't be back for 24 months. Four months later, he's back for another one. That's not what customers want to do.
Moran: From an interoperability and integration perspective, I'd like to talk about the blending of different data-tier technologies. As data mining evolves, SQL Server will have some tight integration with Commerce Server. There's Host Integration Server. DTS [Data Transformation Services] is a transformation tool, among other things. There are portions of BizTalk Server that do schema mapping, transformation, and workflow management. And XML starts to blend in with everything. Are there plans to take SQL Server components that are considered to be core, such as DTS, out of the SQL Server team and lock them down as part of the operating system?
Flessner: You can look at integration in a couple of ways. You can look at it from the perspective of Enterprise Application Integration behind the firewall. And clearly Host Integration Server plays a big role for us there. Heterogeneous queries play a big role for us. DTS certainly plays a role. Then that starts to cross the line outside the firewall, where you've got XML playing a huge role. BizTalk Server plays an important role for us with XML messaging and workflow scheduling. So at some point, those technologies cry out for some integration points. Some people get excited about a central point of integration, such as a catalog or repository. Some people want the flexibility of a self-describing protocol, which is what XML provides. We're a company that provides a robust, rich, and diverse platform, so you're going to see us with entry points in each of those technologies.
Moran: It seems as if you're reinventing the wheel a couple of times. From my understanding, BizTalk Server doesn't use any of the core COM components available for DTS, although you could argue that if DTS had a really clean XML provider, BizTalk Server could have used that provider. Are different product teams working at different paces on new products going to create competing standards within Microsoft—never mind the rest of the industry?
Flessner: I think there's some overlap, but not quite as much as you might fear. For example, BizTalk centers on the ability to take different transaction formats and convert them into an XML format. The DTS design point is data transformation rather than message transformation, and there will always be a need for that. Neither DTS nor BizTalk do a good job of going after ADO and OLE DB data sources and text files, which are important to the data warehousing market. Is there opportunity for some convergence in the future? Probably. At some point, if I have XML everywhere, I don't need any of those technologies. SQL Server can do all of the transformation, right? But that's a long time coming, and I doubt that any one protocol is ever going to take the entire market. One unified XML world with blended data-tier storage is a nice vision, but it's a long time coming.
Moran: Do you have any thoughts on what DBAs in corporate America should do to revamp their skill sets if they're intent on being at the upper end of the SQL Server professional market 6 or 12 months from now?
Flessner: XML is certainly an important technology that you're going to see increasing emphasis on. You can program XML in SQL Server 2000 in multiple ways. You can do it from a SQL-centric perspective or from an XML developer and DOM [Document Object Model] perspective. The most common ways customers get into trouble are by fundamentally not understanding the product, doing poor database design, not thinking about backup and recovery, not looking at application-level locking and potential application-design deadlocking, writing poorly designed ISAPIs [Internet Server APIs] that bring down their IIS servers, and not understanding the interplay between IIS and SQL Server. Specifically in Windows 2000, we've implemented some great advantages in robustness of IIS 5.0 and in the role that COM+ can play in multithreading your application and making it much, much faster. Good, old-fashioned data modeling is always a good thing. Understand SQL Server, how stored procedures work, and how connections work. I know it's simpler said than done.
End of Article
Prev. page
1
[2]
next page -->
