Dr. Mario's 2nd 🧠

What Goes Around Comes Around... And Around...

3 min read

rw-book-cover

Metadata

Highlights

that the relational model (RM) and SQL are the prevailing choice for database management systems (DBMSs), despite efforts to replace either them. Instead, SQL absorbed the best ideas from these alternative approaches. (View Highlight)

we expect more of the same in the future, (View Highlight)

Despite strong protestations that SQL was terrible, by the end of the 2010s, almost every NoSQLDBMS added a SQL interface (View Highlight)

All the leading RDBMSs support full-text search indexe (View Highlight)

vector DBMSs are essentially document-oriented DBMSs with specialized ANN indexes. Such indexes are a feature, not the foundation of a new system architecture. After LLMs became “mainstream” with ChatGPT in late 2022, it took less than one year for several RDBMSs to add their own vector search extensions. (View Highlight)

The question is whether graph DBMS vendors can make their specialized systems fast enough to overcome the above disadvantages. There have been several performance studies showing that graph simulation on RDBMSs outperform graph DBMSs [130, 143]. More recent work showed how SQL/PGQ in DuckDB outperforms a leading graph DBMS by up to 10⇥ [196]. This trend will continue with further improvements in worstcase optimal joins [132, 168] and factorized execution algorithms [100] for graph queries in RDBMSs. (View Highlight)

averse with changing OLTP DBMSs than with OLAP. If an OLTP DBMS fails, companies cannot execute the transactions they need to generate revenue. In contrast, an OLAP DBMS failure could be limited to temporarily inconveniencing an analyst or data scientist. (View Highlight)

The key of the article

Every developer has struggled with databases before, so they are especially amenable to such marketing. Inferior DBMS products have succeeded via strong marketing despite the existence of better options available at the time: Oracle did this in the 1980s, MySQL did this in the 2000s, and MongoDB did this in the 2010s. These systems got enough traction early on to buy them time to fix the engineering debt they accumulated earlier. (View Highlight)

For OLAP databases, NL could prove helpful in constructing the initial queries for exploratory analysis. However, these queries should be exposed to a dashboard-like refinement tool since English and other NLs are rife with ambiguities and impreciseness. (View Highlight)

We predict that what goes around with databases will continue to come around in upcoming decades. Another wave of developers will claim that SQL and the RM are insufficient for emerging application domains. (View Highlight)

NL interfaces are an old research topic that dates back to the 1970s [139], but which historically has poor outcomes and thus little widespread use [88]. (View Highlight)

✍️ refusing to stand on the shoulders of giants

We caution developers to learn from history. In other words, stand on the shoulders of those who came before and not on their toes. One of us will likely still be alive and out on bail in two decades, and thus fully expects to write a follow-up to this paper in 2044. (View Highlight)

We acknowledge LLMs have impressive results for this task but caution those who think NL will replace SQL. (View Highlight)

ORM

Nobody will write OLTP applications using an NL, as most generate queries using (View Highlight)

Graph View