Абстракция базы данных - это перебор?

18

После ознакомления с многочисленными уровнями абстракции базы данных я начинаю задаваться вопросом, в чем смысл каждой библиотеки, изобретающей свою собственную парадигму для доступа к данным. Получение нового 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, которые я не осознаю. Может ли кто-нибудь указать, что я здесь пропускаю?

Примечание для себя - придумай имя
источник
2
Самая большая проблема со стандартным SQL состоит в том, что существует ряд запросов, специфичных для базы данных. Синтаксис внешнего соединения сильно отличается, как и процесс получения «оконного» запроса. Это необходимость для DAL для начала. Теперь, если бы DAL использовал стандартный вариант SQL, который знает, как бороться с идиотсинкразиями различных поставщиков SQL, я бы приветствовал это.
Берин Лорич

Ответы:

10

Наиболее фундаментальная проблема обычного использования SQL состоит в том, что запросы SQL являются строками, которые каким-то образом составлены из другого языка. Вот откуда происходят SQL-инъекции и другие уязвимости и WTF (ваш пример выбран очень плохо, потому что ваш запрос фактически не имеет никаких параметров).

Следующая проблема на самом деле является следствием: если у вас просто написан SQL-код, компилятор ничего не может с этим поделать. Ошибки, такие как опечатки в именах столбцов, будут появляться только во время выполнения. Это в основном то, почему вы не хотите просто строковое представление вашего запроса в исходном коде, а то, что компилятор может статически анализировать, чтобы предотвратить 95% всех ошибок facepalm-ошибок.

И последняя проблема возникает, когда вы пытаетесь сопоставить реляционную базу данных с вашей семантикой языка и моделью программирования: СУБД плохо сочетаются с ООП (или навигационным поиском данных). На самом деле, это довольно ужасная идея, объединяющая эти два, но это то, о чем говорят все объектно-ориентированные DAL для баз данных SQL (т.е. ORM). Но все эти уровни абстракции обречены на утечку. Я думаю, что именно поэтому их так много: поскольку вы работаете с ними, вы видите, что они несовершенны, вы решили написать DAL, который делает это правильно и в конечном итоге терпит неудачу.

Таким образом, в то время как проблемы 1 и 2 предполагают наличие DAL, которые избавляют от SQL, проблема 3 подразумевает, что не существует прямого решения иметь один (по крайней мере, для ООП), и поэтому всегда будет множество DAL с различными преимуществами и ограничениями. В конце концов, все, что вы можете сделать, это тщательно выбрать несколько и придерживаться их.

back2dos
источник
3
«СУБД плохо сочетаются с ООП» - все ли в программном обеспечении должно быть ОО?
quant_dev
@quant_dev: Нет. Но «абстракционные» слои изначально по меньшей мере «ориентированы на абстракцию». Также предоставленные фрагменты кода предполагают, что речь идет об ОО-коде.
back2dos
Я всегда думал, что встраивание SQL в C или что-то еще было самой глупой вещью, которую можно вообразить. Когда мне нужно было сделать что-то подобное, я создал средство для определения отношений между таблицами и их сохранения в базе данных, а затем использовал их для создания SQL во время выполнения для связи с базой данных. Мой код C был просто: «Найти эту сущность, используя этот ключ», «Сохранить изменения в ней».
9

Вы упускаете из виду очевидный факт, что не все платформы баз данных принимают один и тот же синтаксис SQL, поэтому встраивание операторов SQL в ваше приложение просто не будет работать для каждой платформы баз данных. Если вам когда-нибудь потребуется поддержка нескольких платформ баз данных, вам придется переосмыслить большинство (если не все) этих операторов SQL.

Бернард
источник
3
@ Примечание - Но тогда DAL должен был бы иметь полный синтаксический анализатор SQL и иметь собственный поддерживаемый диалект, который будет отличаться от любой конкретной базы данных. И тогда он будет иметь всю сложность, с которой он в настоящее время сталкивается, генерируя соответствующий оператор SQL для конкретной базы данных. Например, ключевое слово LIMIT в вашем примере допустимо в MySQL, но не в Oracle или SQL Server.
Джастин Кейв
2
Теперь мы подошли к сути вопроса. Что делает нестандартный набор имен методов и перегрузок операторов лучше, чем нестандартный диалект SQL? Использование SQL, по крайней мере, даст программисту знакомую основу для начала изучения инфраструктуры.
Обратите внимание на себя - придумайте имя
3
@ Заметка для себя: вероятно, потому что проще написать API в свободном стиле, чем написать синтаксический анализатор SQL на каком-то диалекте SQL, а затем перевести его на другой диалект SQL.
Дин Хардинг
1
Для записи я также предпочитаю использовать «родной» SQL. Большинству моих проектов никогда не требовалось поддерживать более одной базы данных, поэтому для меня это никогда не было проблемой.
Дин Хардинг
3
«Вы упускаете из виду очевидный факт, что не все платформы баз данных принимают один и тот же синтаксис SQL» - да, но как часто вы пишете код для запуска с какой-либо базой данных? Обычно платформа БД является значительным капиталовложением и не часто меняется. Кроме того, можно существенно повысить эффективность оптимизации ваших запросов по отношению к известному типу базы данных.
Quant_dev
5

Я чувствую, что SQL испытывает те же серьезные изменения, что и указатели 10 лет назад. В настоящее время предпринимаются попытки устранить ручную работу с SQL и вывести ее на более высокий уровень абстракции. То же самое произошло с указателями и ручным управлением памятью много лет назад.

Поскольку работа в настоящее время продолжается, вам нравится видеть много разных подходов, предложенных, опробованных, отказавшихся и интегрированных. Я уверен, что мы увидим это еще до того, как проявится какой-то общий подход или отраслевой стандарт.

Это, безусловно, дает вам преимущество, когда вы можете манипулировать кодом доступа к данным на том же уровне и с той же парадигмой, которую вы применяете при работе с кодом приложения.

В нескольких словах - упрощение, ловкость, быстрота, это цели.


источник
4

Джоэл написал хорошую статью 10 лет назад: не позволяйте астронавтам архитектуры пугать вас

Я думаю, что это именно так. Я использовал слой абстракции в своих собственных приложениях, так как я нашел шаблоны, и мне было легко это сделать. Но это был мой DAL, я знал каждую строку в исходном коде => полный контроль. Но я бы не советовал использовать эту среду кому-либо за пределами моей команды / проектов.

Когда вы используете что-то подобное, важно знать, как это реализовано, это означает, что вы должны тратить много времени на изучение библиотеки / инструмента. Если у вас нет времени на его изучение - не используйте. Даже если это выглядит очень легко с самого начала.

m5ba
источник
Да, компания, в которой я работал в прошлом, начала использовать Hibernate с энтузиазмом. Затем они обнаружили, насколько удивительным (странным образом) могут быть запросы, сгенерированные платформой.
Quant_Dev
@quant_dev Да, это ловушка - легко начать делать простые вещи с Hibernate или JPA.
m5ba