There's a school of thought in business software development that says, "the data is the application." And, while I tend to shy away from absolute statements and the people who make them, particularly in the naturally fractal world of software development, this has tended to prove true in the projects I've worked on. The structure, business layer, and interface of the application are dictated by the underlying data structure, which survives or fails based on the quality of your database.
I've had the opportunity to work as a developer with the holy trinity of databases (Oracle, Sybase, and SQL Server) on a variety of projects. For a while, I preferred Oracle because of its raw power, scalability, and robustness while preferring SQL Server for its intuitive management tools and developer support. Earlier versions of SQL Server somewhat less scalable and reliable and, because they were built for Windows NT 3.51 and earlier, bound to a less stable operating system.
Starting with Version 7, though, Microsoft has really gotten its act together. NT4 and Windows 2000 are also head and shoulders about NT 3.51 in terms of reliability. During that same time, Oracle hasn't changed much. Worse, the ways it has changed have made it harder to develop against and more frustrating to use. I'm convinced that Oracle's chairman, Larry Ellison harbors a pathological hatred for Microsoft and that said pathology has trickled down into the corporate culture. Otherwise, how do you explain a software company that builds its product to be barely compatible with the number one development tool on the number one operating system in the world? It feels like Oracle is trying to punish us for working in Visual Basic sometimes.
Installing SQL Server 2000 is so easy that even a developer like me can do it. For full functionality, you need to select one directory for application files and one for data files. The rest is more or less a matter of accepting the defaults. One caveat, though--if you're planning on doing any kind of web-based linking to the database, leaving the default validation (NT domain only) scheme will cause innumerable headaches later on. The only reason I can think of why dual validation isn't the default is so as not to confuse people who've gotten accustomed to installing SQL Server 7.
I've done several installs of SQL Server 2000 now. Most of them were for a development environment. If all you need is a database to develop against, you're basically done administering SQL Server within 10 minutes of sticking the CD in the drive. One of the things I love about the SQL Server line is that the amount of work you spend administering your database seems more or less directly proportional to the complexity of your database. Simple databases are trivial to administer. More complex databases require more complex configuration. This is quite a refreshing change from Oracle, where every database is hard to set up and administer. If, for example, you have a high-performance system with large chunks of mostly static, rarely accessed data (history tables, for example) coupled with some tables that require much faster read-write, you can use SQL's Enterprise Manager to instruct the server to store the more dynamic tables on a fast, but expensive SCSI or Firewire hard drive and the history tables on a slower, cheaper EIDE drive.
One "improvement" I'm not so crazy about, but understand the logic behind is the way Microsoft changed the layout of Enterprise Manager. With SQL Server 7, setting up disaster recovery, backup, and transfer plans was not only easy, but links to the wizards that allowed you to do these tasks were provided on the opening screen of each database. Those links have been moved to a less obvious location in SQL Server 2000. While I, as a developer, liked being shown these tasks immediately, more experienced administrators will appreciate having one less screen to dig through each time they open Enterprise Manager.
The only really significant interface change I can see between SQL Server 7 and SQL Server 2000 is in SQL Query Analyzer. Up to and including SQL Server 7, Query Analyzer was a barely graphical interface to ISQL, an old command-line tool from the bad old days of DOS and UNIX.
Currently, I have custody of 11 SQL Server 2000 installations in one form or another. They've run a total of about 2,500 days, about 1,400 of those under heavy traffic conditions. Two were installed over previously existing SQL Server 7 installations. Not a one has had to be restarted. The only problem I did have was when I tried to install SQL Server 7 on a box that already have SQL Server 2000. SQL Server 7 tried to convert my pre-existing SQL Server 2000 databases from SQL Server 6.5 format (which, of course, they weren't in) to SQL Server 7 format. In all fairness, that was a very, very silly thing for me to do.
SQL Server 2000 lists a number of new features, but the one that interests me the most is its robust support for XML. T/SQL2K includes a new clause FOR XML AUTO, which returns the entire recordset as an XML document. In addition, you can retrieve recordset as XML from your SQL Server database over any TCP/IP network using a URL and query string that requests the necessary data. This is very cool and can really cut down development time.
The long and the short of it is that SQL Server 2000 is a phenomenal tool for all but the very largest and very smallest databases. It's easy to set up, easy to configure, easy to administer, and easy to develop against. If you're a Microsoft shop, this is almost certainly the database to use.
Epinions.com periodically updates pricing and product information from third-party sources, so some information may be slightly out-of-date. You should confirm all information before relying on it.
- Add to My Yahoo!: 
- Add to Google Homepage: 
© 1999-2009 Shopping.com, Inc.