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

Закрито . Це питання має бути більш зосередженим . Наразі відповіді не приймаються.

Хочете вдосконалити це питання? Оновіть питання, щоб воно зосередило увагу на одній проблемі, лише відредагувавши цю публікацію .

Закрито 5 років тому .

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

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

EDIT 1 - Я припускаю, що ви вже розділили його на модельний шар

sql code-formatting

— медуза
джерело

Це питання, безумовно, доречне тут - організація коду: "надихайте [відповіді] відповіді, що пояснюють" чому "і" як "." та з предметів «Шаблони дизайну» та «Архітектура» (від Faq )

— Michael K

Я саме збирався задати це саме запитання. Я б хотів, щоб тут було більше відповідей.

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

Відповіді:

Для мене 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 як основну частину програмування, а не абстрагуйтесь заради абстракції.

— гахуа
джерело

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

— медуза

"не абстрагуватися заради абстракції" - Добрий момент. Анотація заради більш зрозумілого коду.

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

"Ще одна порада полягає в тому, щоб насправді мати хороший метод запиту до бази даних": я безумовно згоден. Це дуже допомагає, коли є лише одне місце для зміни коду, коли бізнес-логіка змінюється.

— Майкл К

Куди ви поставите SQL? Чи компілюється він у додаток та надсилається за допомогою наведених вище методів?

— johnny

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

— JeffO

Як правило, найкращим підходом є наявність окремого шару моделі. Існує ряд моделей дизайну підприємств, які дають шляхи архітектури цього.

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

Вибачте, я повинен був бути більш конкретним ... Я вже припускаю, що ви їх розділили на шар моделі. Але шар моделі все ще може бути досить розпорошеним за допомогою SQL-коду. Можливо, це неминуче. Інша річ , яка хвилює мене в коді моделі є код , який «будує SQL запит» на основі деякої логіки ... може бути , це повинно бути відокремлена в свою власну фабрику або що - то ...

— jellyfishtree

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

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

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

— jellyfishtree

Можливо, було б добре поділити ваш модельний шар на 3 підшари - "сутності", "сховища" та "послуги". Це допоможе вам розділити проблеми та зібрати SQL в одному місці, з вашої ділової логіки.

У цьому сценарії весь код пошуку даних, включаючи складний SQL, буде розташований у сховищах. Таким чином, мета репозиторію полягає в тому, щоб приховати складні оператори SQL за методами, що роз'яснюються, як getUsersWithActiveSubscription().

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

Сервісний рівень - це місце для бізнес-логіки. Сервіс витягує об'єкти, що використовують сховища, діє на них і зберігає їх назад.

— GerKirill
джерело