수많은 데이터베이스 추상화 계층에 노출 된 후 데이터에 액세스하기위한 자체 패러다임을 개발하는 모든 라이브러리의 요점이 무엇인지 궁금해졌습니다. 새로운 DAL을 선택하면 새로운 언어를 다시 배우는 것처럼 느껴집니다. 일반적으로 내가 원하는 것은 레이어가 이미 내 머리에 쓴 SQL 쿼리를 출력하도록 설득하는 것입니다.
그리고 그것은 사실 후에 가독성에 영향을 미치지 않습니다.
# Exhibit A: A typical DAL
rows = db(db.ips_x_users.ip_addr == '127.0.0.1')
.inner_join(db.ips_x_users.user_id == db.users.id)
.select(order=(db.ips_x_users.last_seen, 'desc'), limit=10)
# Exhibit B: Another typical DAL
rows = db.ips_x_users
.join(db.users, on=db.ips_x_users.user_id == db.users.id)
.filter(db.ips_x_users.ip_addr == '127.0.0.1')
.select(sort=~db.ips_x_users, limit=10)
# Exhibit C: A hypothetical DAL based on standard SQL syntax
rows = db('''SELECT * FROM ips_x_users
INNER JOIN users ON
(ips_x_users.user_id = users.id)
WHERE ips_x_users.ip_addr = ip
ORDER BY last_seen DESC LIMIT 10''', ip='127.0.0.1')
표준 SQL 구문의 문제점은 무엇입니까? 그것은 특정 목적을 위해 만들어졌으며 그 목적에 아름답게 맞습니다. 어쩌면 그것은 나지만, 스 니펫 C는 처음 두 개보다 훨씬 쉽게 이해할 수 있습니다. 이름이 바뀐 키워드와 구문 트릭은 귀엽지 만, IMO는 바로 그것으로 인해 코더가 행을 더 쉽게 검색하지 못합니다.
이것은 아마 긴 호언 장담처럼 보였다, 그러나이 있다 여기 진짜 문제는. 모든 DAL은 시도되고 진정한 SQL을 파싱하는 대신 쿼리를위한 새로운 DSL을 발명하는 것처럼 보이므로 다른 구문을 사용하면 얻을 수있는 이점이 있거나 표준 SQL 구문의 결함이 있다는 것을 알아야합니다. 아무도 내가 여기서 내려다보고있는 것을 지적 할 수 있습니까?
2
표준 SQL의 가장 큰 문제는 데이터베이스에 특정한 많은 쿼리가 있다는 것입니다. "조인 된"쿼리를 가져 오는 프로세스와 마찬가지로 외부 조인 구문은 크게 다릅니다. 이것이 바로 DAL의 필요성입니다. 이제 DAL에서 사용하는 표준 SQL 변형이 여러 SQL 공급 업체의 바보 동기화를 처리하는 방법을 알고 있다면이를 환영 할 것입니다.
—
Berin Loritsch