A database interface has been part of the original IRAF design since 1984, but was never implemented. Originally, the idea was that the DBIO interface would be used to maintain all datafiles, keywords in image headers, data tables and so on. In the original design this was practically an implementation of an entire RDBMS system within IRAF, something not needed today where we have database systems that can be accessed via a daemon (e.g. mysql, postgres) or can be self-contained in text file (e.g. SQLite and accessed via an API.
See below for more comments ....
The original scope of managing all IRAF data and files in a database is probably no longer relevant, however data are becoming increasingly complex to manage (e.g. lists of many extensions in each image, reductions requiring lists of calibration and object data producing even more lists of coordinate files and output images), and databases can be useful in managing this complexity. It would be hard to justify the development required for something comparable to the generic JDBC interface for Java, however a third-party software like SQLite offers a self-contained database solution requiring a minimal interface. Incorporating this into a core IRAF release would be a departure from past distributions and is probably best done first as part of external package development with a demonstrated need for database capabilities.
More generally, catalog data and techniques (e.g. cross-matching) will be playing an even greater role in data analysis in the future. The TABLES package is adequate for managing small files, but is no substitute for database functionality. While not a high-priority item now, discussions of next-generation systems should include the ability to access, query and manage large databases as part of the analysis environment. Likewise, tighter integration with archive centers would also be highly desirable, however we hope that Virtual Observatory data access protocols will be able to provide a general interface to archive data.