DB가 모든 어플리케이션의 필수요소가 된 때에, SQL과 Programming Language의 gap이 아직도 크다는 점을 지적하고 Programming Language가 적극적으로 이를 메꾸기 위한 방향으로 나가야한다는 내용. 아래에 원문과 대충 번역한 내용이 있다.
March 25, 2004
Thanks to everyone who came to the open house last night. If you have
pictures, send me a link!
We had an interesting conversation about how the impedance
mismatch between contemporary high-level programming languages (Java, C#,
Python, VB) and relational databases. Since a huge percentage of code requires
access to databases, the glue (a.k.a. the connecticazoint) between the RDBMS
layer and the application code is very important, yet virtually every modern
programming language assumes that RDBMS access is something that can be left to
libraries. In other words, language designers never bother to put database
integration features into their languages. As a tiny example of this, the syntax
for “where” clauses is never identical to the syntax for “if” statements. And
don’t get me started about data type mismatches: just the fact that columns of
any type might be “null” leads to an incompatibility between almost every native
data type and the database data types.
하이레벨 프로그래밍 언어에서
RDB 지원이 안되는 것에 대해 얘기를 나누었다. 많은 코드들이 DB를 사용하기 때문에 RDB와 App 코드의 접목은 중요하지만, 요즘
언어들은 전부 라이브러리에게 그 역할을 맡기고 언어상의 DB integration을 꺼리고 있다. 예를 들면 SQL의
where절 문법과 if syntax는 너무나 차이가 많이난다. data type도 마찬가지다.
The trouble with this is that the libraries (think ADO, DAO, ODBC, JDBC,
embedded SQL, and a thousand others) need to be general purpose to be reusable,
and yet what you really want is a mapping between a native data structure and a
table row or query result row. Inevitably, you have to hand roll this mapping
and wire it up manually, which is error prone and frustrating
RDB에 접근하기
위한 라이브러리들이 재사용 가능하려면 범용적이어야 하지만, 우리가 진짜 원하는건 native data type 과 table
row, query result row와의 mapping이란
거다. 결국 전부 손으로 해야하고, 이런건 구리다.
I think this is a fatal flaw in language design, akin to the bad decision by
the designers of C++ that it was not necessary to support a native string type.
“Let a thousand CString/TString/String/string<char> types flourish,” they
said, and then spent more than a decade adding new features to the language
until it was marginally, but not completely, possible to implement a non-awful
string class. And now we have a thousand string types (most large C++ bodies of
code I’ve seen use three or four) and a bunch of really good books by Scott
Meyers about why your personal hand-rolled string class is inadequate. It’s
about time that a language designer admitted that RDBMS access is intrinsic to
modern application implementation and supported it in a first-class way
syntactically.
난 이게 언어 디자인 상의
치명적인 결함이라고 생각한다. C++에서 string type을 native로 지원하지 않은 문제와
마찬가지다. CString/TString/String/string<char> 타입들을 맘대로 만들도록 두자고 얘기하고는
새로운 기능을 추가하는데만 신경써왔다. 이제 수많은 string type들이 생겼고, 스콧 마이어 아저씨는 따로 자기가 만든 string class는 부적합하다고 말한다. 이제 언어 디자인하는 인간들이 RDB 지원은 app에 기본적인 요소이고 맨먼저 문법적으로 지원되어야 함을 인정할 때다.
Now for all the disclaimers to prevent “but what about” emails. (1) in
functional languages like lisp the syntax layer is so light that you could
probably implement very good RDBMS shims in ways that feel almost native.
Especially if you have lazy evaluation of function parameters, it’s easy to see
how you could build a “where” clause generator that used the same syntax as your
“if” predicates. (2) Access Basic, later Access VBA, had a couple of features to
make database access slicker, specifically the [exp] syntax and the rs!field
syntax, but it’s really only 10%. There are probably other niche-languages or
languages by RDBMS vendors that do a nice job. (3) Attempts to solve this
problem in the past have fallen in two broad groups: the people who want to make
the embedded SQL programming languages better (PL/SQL, TSQL, et al), and the
people who want to persist objects magically using RDBMS backends (OODBMSes and
object persistence libraries). Neither one fully bridges the gap: I don’t know
of anyone who builds user interfaces in SQL or its derivatives, and the object
persistence implementations I’ve seen never have a particularly good
implementation of SELECT.
1) functional language에선 syntax layer가 가벼워서 좋은 RDBMS
shim을 만들어 거의 native하게 느낄 수 있을 거다. 특히 lazy evaluation이 있다면 if 절과 같은 문법으로 where 절
생성기를 만들기도 쉬울 것이다..
2) Access
Basic/VBA는 DB access를 위한 여러가지 기능이 있지만 10%정도일 뿐이다. 아마 다른 더 좋은 언어들이 있을
것이다.
3) 이 문제를 해결하기 위한
시도에는 두가지가 있었다.
embedded SQL 프로그래밍
언어를 만들자는 쪽과 RDBMS backend를 이용해 object persistence를 만들자는 쪽.
어느쪽도 gap을 완전히 메꾸지는
못했다. SQL로 user interface를 만드는 사람을 한명도 모를뿐만 아니라 내가 본 object persistent 구현 중 SELECT를 제대로 구현한 것은 없었다.
