A brief history of relational databases helps us appreciate the importance of this technology and helps us understand Oracle Corporation’s decisions. The Oracle database is a huge product and contains mistakes. Some of those mistakes are unimportant historical curiosities, but others are huge pitfalls we need to avoid.
Relational databases are built on the relational model and relational algebra, first publically described by E.F. Codd in 1970. The relational model is built on set theory, a mathematical way of dealing with collections of objects. The relational model is discussed in more detail in the next section.
IBM started working on relational technology and products in 1968. Here’s the first history lesson: best is the enemy of good enough. Larry Ellison heard about IBM’s project, implemented it, and released the first commercially available SQL database in 1979. He has a huge presence in the database world and is still involved with many database decisions to this day.
Oracle Corporation has certainly used its first-mover advantage. The Oracle database has been the most popular database product for a long time. There are current trends away from Oracle and SQL, but we shouldn’t overlook how incredibly popular they are. The database scores high on almost any database popularity metric.
Oracle’s age explains many of its unexpected behaviors. The following list contains the features that are most likely to confuse database developers who are new to Oracle.
- (+): Oracle originally used syntax like (
+) instead of keywords likeLEFT JOIN. - Date: An Oracle date contains a time and should be called a
DATETIME. Date formatting was awkward before the introduction of ANSI date literals. - Empty string: Oracle treats an empty string as null, instead of a distinct value as most programmers expect. (Although I would argue that Oracle is not necessarily wrong here. We don’t have zero-length dates, or zero-length numbers; why should we have zero-length strings?)
- 30-byte name limit: The SQL and PL/SQL languages have an English-like syntax, but we’ll quickly hit the 30-byte limit if we use regular words for names. Good variable names are important to make our programs more readable. Luckily this problem is fixed in version 12.2, which allows 128 bytes.
- SQL*Plus quirks: SQL*Plus is a great tool for some tasks, but it’s really showing its age in many ways.
In Oracle’s defense, those mistakes were made before any standards existed. On the other hand, Oracle doesn’t always make a good effort to comply with standards. For example, Oracle used to claim “partial” compliance for allowing long names. While 30 bytes is “part” of a bigger number, that doesn’t really meet the spirit of the standard.
More important than excusing Oracle’s mistakes, it helps to see how Oracle Corporation responds to industry trends. Sometimes it feels like they have a “fire and motion” strategy for their technologies. They add so many features that nobody can possibly keep up with them. However, adding a huge number of features may be backfiring now. The Unix philosophy of building small tools for each task seems to be taking over.
The following list shows the largest architectural and conceptual changes made to Oracle, along with the version it was introduced. These are not necessarily the most important features, but the features that tried to redefine what a database is.
- Multiversion concurrency control (MVCC): 4
- PL/SQL: 6
- Object-relational: 8
- Java: 8
- OLAP: 9
- XML, JSON, documents: 9, 12, 18
- RAC, sharding: 9, 12
- In-Memory: 12
- Containers (multitenant): 12
- Property graph: 18
- Autonomous database: 18
Adding new features rarely hurts sales. But some of those features move Oracle in a wrong direction. For example, object-relational, Java in the database, and multitenant containers all have problems.
Oracle will always add a new feature to catch up with competitors, even if that feature doesn’t make sense. Not everything Oracle Corporation does is the “future.” Oracle is a huge product that sometimes moves in multiple, contradictory directions at the same time. We need to remember to not drink the Kool-Aid and not throw out proven technology for shiny new things.
On the other hand, it’s good that Oracle supports almost everything. It’s a Swiss-army knife for database solutions. We don’t need a new database for each new technology trend.
The pace of technological change is accelerating, and nobody can predict the future. Given the past, it’s safe to say that Oracle will add or invent new and important features. We don’t always want to start using new features immediately. But we should at least take the time to read about them in the “New Features” chapter of the manual.
