Опинившись на численних шарах абстрагування баз даних, я починаю цікавитись, у чому сенс кожної бібліотеки винайти свою власну різну парадигму для доступу до даних. Збираючи новий 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? Він був створений з певною метою, і він цілком відповідає цій меті. Можливо, це лише я, але я розумію фрагмент С набагато легше, ніж перші два. Перейменовані ключові слова та синтаксичні трюки милі, але IMO, коли справа доходить до цього, вони не полегшують отримання рядків для кодера.
Це, мабуть, здавалося тривалим скандалом, але тут є справжнє питання. Оскільки, схоже, кожен DAL придумує новий DSL для запитів, а не просто для розбору перевірених істинних SQL, повинні бути або переваги використання різних синтаксисів, або недоліки в стандартному синтаксисі SQL, які я не усвідомлюю. Може хто-небудь, будь ласка, зазначити, що я тут не помічаю?