После ознакомления с многочисленными уровнями абстракции базы данных я начинаю задаваться вопросом, в чем смысл каждой библиотеки, изобретающей свою собственную парадигму для доступа к данным. Получение нового 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, которые я не осознаю. Может ли кто-нибудь указать, что я здесь пропускаю?
источник
Ответы:
Наиболее фундаментальная проблема обычного использования SQL состоит в том, что запросы SQL являются строками, которые каким-то образом составлены из другого языка. Вот откуда происходят SQL-инъекции и другие уязвимости и WTF (ваш пример выбран очень плохо, потому что ваш запрос фактически не имеет никаких параметров).
Следующая проблема на самом деле является следствием: если у вас просто написан SQL-код, компилятор ничего не может с этим поделать. Ошибки, такие как опечатки в именах столбцов, будут появляться только во время выполнения. Это в основном то, почему вы не хотите просто строковое представление вашего запроса в исходном коде, а то, что компилятор может статически анализировать, чтобы предотвратить 95% всех ошибок facepalm-ошибок.
И последняя проблема возникает, когда вы пытаетесь сопоставить реляционную базу данных с вашей семантикой языка и моделью программирования: СУБД плохо сочетаются с ООП (или навигационным поиском данных). На самом деле, это довольно ужасная идея, объединяющая эти два, но это то, о чем говорят все объектно-ориентированные DAL для баз данных SQL (т.е. ORM). Но все эти уровни абстракции обречены на утечку. Я думаю, что именно поэтому их так много: поскольку вы работаете с ними, вы видите, что они несовершенны, вы решили написать DAL, который делает это правильно и в конечном итоге терпит неудачу.
Таким образом, в то время как проблемы 1 и 2 предполагают наличие DAL, которые избавляют от SQL, проблема 3 подразумевает, что не существует прямого решения иметь один (по крайней мере, для ООП), и поэтому всегда будет множество DAL с различными преимуществами и ограничениями. В конце концов, все, что вы можете сделать, это тщательно выбрать несколько и придерживаться их.
источник
Вы упускаете из виду очевидный факт, что не все платформы баз данных принимают один и тот же синтаксис SQL, поэтому встраивание операторов SQL в ваше приложение просто не будет работать для каждой платформы баз данных. Если вам когда-нибудь потребуется поддержка нескольких платформ баз данных, вам придется переосмыслить большинство (если не все) этих операторов SQL.
источник
Я чувствую, что SQL испытывает те же серьезные изменения, что и указатели 10 лет назад. В настоящее время предпринимаются попытки устранить ручную работу с SQL и вывести ее на более высокий уровень абстракции. То же самое произошло с указателями и ручным управлением памятью много лет назад.
Поскольку работа в настоящее время продолжается, вам нравится видеть много разных подходов, предложенных, опробованных, отказавшихся и интегрированных. Я уверен, что мы увидим это еще до того, как проявится какой-то общий подход или отраслевой стандарт.
Это, безусловно, дает вам преимущество, когда вы можете манипулировать кодом доступа к данным на том же уровне и с той же парадигмой, которую вы применяете при работе с кодом приложения.
В нескольких словах - упрощение, ловкость, быстрота, это цели.
источник
Джоэл написал хорошую статью 10 лет назад: не позволяйте астронавтам архитектуры пугать вас
Я думаю, что это именно так. Я использовал слой абстракции в своих собственных приложениях, так как я нашел шаблоны, и мне было легко это сделать. Но это был мой DAL, я знал каждую строку в исходном коде => полный контроль. Но я бы не советовал использовать эту среду кому-либо за пределами моей команды / проектов.
Когда вы используете что-то подобное, важно знать, как это реализовано, это означает, что вы должны тратить много времени на изучение библиотеки / инструмента. Если у вас нет времени на его изучение - не используйте. Даже если это выглядит очень легко с самого начала.
источник