Web browsers and other Web technologies for Internet and Intranet usage are radically changing how we develop database applications now and over the next few years. This "revolution"is no less significant than the shift from a mainframe host-based, chara cter-based, and fairly predictable world to today's client/server, GUI, increasingly chaotic world. But don't let all the apparent changes fool you: Not everything is changing, and much of what you now know - or don't know well enough - will be no less i mportant in the near future. Of course, you'll need to acquire many new skills too. Browsers may be the most visible change, but Web technologies are affecting many aspects of systems development, from architectural issues to nuts and bolts parts such as operating systems, DBMS servers, and front-end development tools.
Let's start with the concept of a system architecture. Without some kind of overall plan defining your goals, the basic elements of your systems environment - what each element is supposed to do, how they all fit together, and who is responsible for what - then all you have is fancy furniture and a house to put it in, but no rooms to organize things coherently. Adopting new Web technologies without a clear sense of architecture will not automatically solve your problems, even if these new technologies a re better than what they replace.
Operating systems are evolving to incorporate Web server and client features as built-in rather than add-on functionality. Yes, you must now understand Web servers and how they integrate with your operating system, but the fundamentals of operating syste ms have not been eliminated. When choosing an operating system, you should consider how well it integrates with Web servers and other APIs and technologies that live on the server. But configuring, monitoring, and maintaining your operating system still depends on skills and knowledge you have gained over the past few years.
The impact of the Web on DBMS servers is more pronounced, but again, the basics of selecting and managing a DBMS have not changed dramatically. Generating HTML from a stored procedure is merely another use of existing features. More important, the Web is fueling the explosion of text, documents, multimedia, and other complex objects stored in DBMSs. It's likely that you will manage more kinds of data than you have so far. Again, prepare to learn new skills, but even if your design techniques change to m eet the needs of non-tabular data, the basic idea - that you design a database before you build it - remains the same. You still must administer the DBMS, tune performance, implement security, and so on.
On the other hand, application development tools and techniques are clearly undergoing major changes. An application built two years from now will probably be very different internally from one built two years ago. The value of skills you have gained wil l not completely evaporate, but you can't stand still. A good example is user interface design. Crafting an effective, even pleasing user interface is more difficult than many developers realize. It's more of a subtle art than a hard science, even though there are well-defined principles you can follow. Forms that live within browsers still need to be well designed, or users will end up confused and will avoid using your application. However, Web browsers are still page-oriented, and designing a page th at incorporates significant amounts of text is a challenge many developers have not faced yet, even if they have mastered GUI forms design.
I recommend both guides to anyone developing database applications. If you need to brush up on some basics, these books will serve you well. Even if you think you know your stuff, you will probably find areas covered that are outside your specialty. The DBMS Web site at http://www.dbmsmag.com has an excerpt of The Essential Client/Server Survival Guide. Take a look - it's well worth your time.