Recently a friend started taking a postgraduate course in software engineering, and part of that course was the topic of databases. My friend had learned a little about them in his undergraduate degree in computer engineering, but not that much. Perhaps he would have learned more if he had studied "Computer Science."

When I started at my first full-time job after university, databases as we know them were just getting started. System R at IBM and Ingres at the University of California, Berkeley, were research projects, trying to determine the best way to store and access data. Often funded by research grants from the government, tapes of the code were available at a nominal charge.

If you did not use a database to store your data, you had to deal with various issues such as backing up your data to get a consistent view of your total data, different byte and word size, different endianness types (little endian vs. big endian), loss of data due to power failures and system crashes due to lack of journaling, pulling large amounts of data over the very slow networking of the day, doing transaction processing (which is often used in business), and a variety of other issues. Eventually databases could also store and run complicated functions inside the engine itself, locating the processing right next to the data.

[...]