Лучший способ организовать запросы SQL, хранящиеся в вашем коде? (или ты должен?) [закрыто]

Закрыто . Этот вопрос должен быть более сфокусированным . В настоящее время он не принимает ответы.

Хотите улучшить этот вопрос? Обновите вопрос, чтобы он был сосредоточен только на одной проблеме, отредактировав этот пост .

Закрыто 5 лет назад .

Я уверен, что я не единственный, кто расстраивается, когда видит страницу кода, заваленную SQL-запросами. ActiveRecord и другие шаблоны ORM помогают уменьшить объем SQL, используемый в проекте, но во многих случаях сложных запросов использование SQL, по-видимому, неизбежно.

Я ищу мнения о том, как SQL-запросы должны быть организованы с остальной частью кода (или за его пределами), чтобы предотвратить его разброс по всему? Одна очевидная идея - использование представлений, но часто представления могут быть источником проблем с производительностью при работе с несколькими большими индексированными таблицами и т. Д.

РЕДАКТИРОВАТЬ 1 - Я предполагаю, что вы уже разделили его на слой модели

sql code-formatting

— jellyfishtree
источник

Этот вопрос определенно уместен здесь - организация кода: «вдохновлять ответы, которые объясняют« почему »и« как »». и имеет предметы «Шаблоны проектирования» и «Архитектура» (из часто задаваемых вопросов )

— Майкл К.

Я как раз собирался задать этот же вопрос. Хотелось бы, чтобы здесь было больше ответов.

— Майкл Кристофик

Ответы:

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

Когда я смотрю на это, чтение данных, обработка данных, запись данных, поиск данных ... все они являются похожими операциями и лучше всего хранятся в одном месте.

Если вы начинаете ощущать дублирование усилий с запросами, то, возможно, вам нужно представление базы данных или объект, который может инкапсулировать этот аспект доступа к базе данных.

Другой совет, чтобы действительно иметь хороший метод запроса к базе данных. В программном обеспечении, которое я пишу (PostgreSQL, MySQL, SQL Server), я гарантировал, что большая часть моих операций с запросами может выполняться как единое выражение кода.

GetValue(SQL, [transaction], [array_of_params])
GetRow(SQL, [transaction], [array_of_params])
GetRowList(SQL, [transaction], [array_of_params])
GetValueList(SQL, [transaction], [array_of_params])
Execute(SQL, [transaction], [array_of_params])

Это (примерно) основные вызовы функций, которые я гарантирую, являются частью моего "объекта соединения". Это зависит от языка, от того, что вы на самом деле реализуете, но моя цель - сделать его действительно очень простым и безболезненным.

Таким образом, рассматривайте SQL как неотъемлемую часть программирования и не абстрагируйтесь ради абстракции.

— gahooa
источник

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

— медуза

«не абстрагируйся ради абстракции» - хорошая мысль. Аннотация ради более понятного кода.

— Джейсон Бейкер

«Другой совет - на самом деле иметь хороший метод запроса к базе данных»: я определенно согласен. Это очень помогает, когда есть только одно место для изменения кода при изменении бизнес-логики.

— Майкл К

Где вы положили SQL? Скомпилировано ли оно в приложение и отправлено ли с помощью описанных выше методов?

— Джонни

На основании комментария ОП к ответу Джейсона Бейкера «смотреть вниз на гигантский запрос SQL ...», как это решает проблему чтения больших блоков текста SQL?

— JeffO

Как правило, лучше всего иметь отдельный слой модели. Существует ряд шаблонов корпоративного дизайна, которые позволяют спроектировать это.

— Джейсон Бейкер
источник

извините, я должен был быть более конкретным ... я уже предполагаю, что вы разделили их на слой модели. Но уровень модели все еще может сильно рассыпаться с помощью кода SQL. Может быть, это неизбежно. Еще одна вещь, которая меня бесит в коде модели, это код, который «строит SQL-запрос» на основе некоторой логики ... может быть, это должно быть выделено в его собственную фабрику или что-то в этом роде

— jellyfishtree

@jellyfishtree - боюсь, я не понимаю, в чем проблема. Я имею в виду, вы боитесь, что на вашем уровне модели может оказаться слишком много кода модели?

— Джейсон Бейкер

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

— jellyfishtree

Было бы неплохо разделить слой модели на 3 подуровня: «сущности», «репозитории» и «сервисы». Это позволит вам разделить проблемы и собрать SQL в одном месте из вашей бизнес-логики.

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

Сущность абстрагирует реальные имена полей таблицы БД с помощью методов получения и установки, может обеспечить некоторую конвертацию данных между типами полей БД и типами, доступными в вашем приложении / языке программирования. Если ваш ORM поддерживает это - сущности могут обрабатывать ассоциации.

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

— GerKirill
источник