If you think the Year 2000 is not your problem, think again. The basic requirement to sweep through virtually all systems checking for and fixing the same data problem over and over again will not go away after the Year 2000 problem is just a memory. The Year 2000 experience has implications for developers building new applications.
Telephone numbers for the United States and Canada are another good example of how seemingly perpetual assumptions can crumble one by one. A few years ago the business rule that dictated area codes always have a "0" or "1" in the middle digit went by the wayside. (The telecommunications switching systems used to check this digit to detect long distance calls.) This probably impacted few systems outside the telecommunications infrastructure. In contrast, the recent introduction of the 888 area code for toll-free numbers impacts any system that has a hard-coded validation for separate toll-free number fields.
Closer to home, Iım in the middle of yet another failing fundamental assumption. Historically, area codes covered distinct geographic areas. The Atlanta metropolitan area where I live is now getting its first taste of overlapping area codes. A new area code is coming online, but without carving out a new geographic territory. The next time I order additional phone lines, Iıll probably get a new area code for a phone line in the same building. The number of three-digit area codes for U.S. and Canadian lines is finite, as is the supply of seven-digit numbers within each area code. Unless the scorching demand for new phone lines to connect cell phones, modems, and faxes and voice lines suddenly dries up (not likely), the day will come when the basic three-plus-seven-digit data structure for U.S. and Canadian phone numbers becomes a maintenance nightmare in the same league as the Year 2000 fix. Database schemas will need to be changed. User interfaces (such as forms) will need to be changed. Reports will need to be changed. Validation logic will need to be changed. Maybe some bright mind will find a way to support additional phone numbers without messing up our systems, but I doubt it.
Contact information has proven to be a ripe arena for frequent changes in data structures. How many of you included fields for URLs five years ago? What about email addresses? Do you have separate fields for cell phone numbers? I canıt guess exactly what new contact information weıll be tracking five years from now, but Iım reasonably certain we have not seen the end of the list. These changes might not be constrained by a nonnegotiable deadline like January 1, 2000, but the basic idea that data changes affect massive amounts of systems wonıt go away. If you are involved in a Year 2000 project, look at it as an opportunity to build a repeatable process for future maintenance. Or better still, rethink some fundamental assumptions about your data structures, and build flexibility in before you need it.
A few years ago I worked in a small startup company. The original developer built some great applications with ubiquitous four-digit invoice number fields. The success of the company made invoice number 10,000 an impending reality. It only took the maintenance team one weekend to expand every database field, screen, and report we had. On Monday morning I found a five-digit invoice number field. I hope they made notes for the time when invoice number 100,000 rolls around. And how many of you expanded your two-digit dates to four-digit dates? The year 10000 is coming. Think ahead.
Iım pleased to announce a new column: Net Developer by Nelson King. Nelson brings many years of experience as a developer plus a sharp insight and an engaging style. He will analyze issues and tools for building database applications for the Net ı especially, but not exclusively, about Java. Nelsonıs column will alternate with Tom Spitzerıs Component Assembler column (formerly named Object.Client). Tomıs increased workload at the EC Company doesnıt allow him time to write a column every month, but Component Assembler will resume in February.
This issue also inaugurates our year-long series on transaction processing. Ken Rudin and his colleagues at the Emergent Corp., a San Mateo, Calif.-based consultancy specializing in the development of highly scalable database systems, will assess a broad range of technologies needed to build modern OLTP applications. Long the heart and soul of enterprise development, mastering successful OLTP strategies and techniques is even more crucial today as electronic commerce pumps more transactions into core business systems.