Как разделять логику запросов в СУБД и PHP?

Question

[elailasou]

Раньше, когда были небольшие проекты и не было времени уделять должное время изучению MySQL, я делал простой или пару-тройку простых запрос в MySQL, затем уже обрабатывал результат в PHP, возможно в цикле делая еще пару запросов. Естественно это неправильно. Начал изучать плотнее СУБД. В новых версиях очень много возможностей, включая условия и прочее.
Так вот, как не перегрузить логику запроса к БД? Как правильно разделить работу СУБД и PHP?

Answer 1

[Станислав Макаров]

Как правильно разделить работу СУБД и PHP?

Есть очень простой принцип.

СУБД - это подсистема, которая хранит и извлекает данные, а приложение (на PHP или на чем угодно) - их обрабатывает и модиифицирует, если нужно.
СУБД архитектурно (и физически) "ближе" к данным. Одна из важнейших задач СУБД - выбрать из всего объема БД только нужные сейчас данные. Именно на уровне СУБД нужно производить максимум фильтраций. У нее есть все нужное для этого - индексы и прочие хитрые структуры данных.

Однако, чтобы СУБД лучше выполняла свои основные задачи, не стоит нагружать ее лишней вычислительной работой. Все, что не связано с поддержанием целостности и согласованности данных, отдают на уровень приложения - тогда эти вычисления (куда относятся, к примеру, подготовка JSON-ответов или сборка web-страницы по шаблону) можно выполнить логически и физически на других узлах, что влечет за собой очевидные преимущества.

Поэтому вывод такой: выбирайте как можно меньше записей и столбцов/атрибутов в запросе к БД (т.е., например, никаких * в плановых запросах), и делайте как можно больше работы с ними на уровне приложения (настолько, насколько удается соблюдать требуемые гарантии целостности).
Под "как можно меньше записей" я имею в виду делать запрос максимально конкретным и узконаправленным, но достаточным для выполнения текущей задачи.

Comments

[Кирилл]

Важнейшая задача СУБД - consistency, если что :) Что значит лишняя работа, понятно что html генерить не стоит, но все же ?

[Станислав Макаров]

Кирилл "одна из важнейших" - так лучше?) Тем более что способности к consistency у разных СУБД сильно различаются (как в плане ссылок и внешних ключей, так и в плане изоляции транзакций), а вот фильтрация и извлечение есть точно у всех.

[Станислав Макаров]

Кирилл
> Что значит лишняя работа
Вот как раз то, что вы сказали - html генерить не стоит. Есть много последователей идеи "все можно сделать на хранимках и триггерах", всю бизнес-логику и даже немножко от представления, никогда не сталкивались с такими?)

[Кирилл]

Станислав Макаров: нет

[Кирилл]

Станислав Макаров: это такая холиварная тема, СУБД = ACID, способности по C, ага, различаются, у нас на одном проекте MySql "доживает" вот там периодически появляются записи с foreign key "вникуда" и вообще куча "нежданчиков" )

[Станислав Макаров]

Кирилл
Не понял к чему "нет" и почему тема холиварная.
Кстати, вы Монгу вообще СУБД не считаете, верно?)

[Кирилл]

Станислав Макаров: нет всмысле не видел, обычно люди не умеют работать с СУБД и скрывают это за ОРМ/ДАЛ и прочими аббревиатурами, либо умеют и там все более менее "ок", короче на практике такого небыло.

Монга достаточно неплахая штука и у нее есть своя ниша использования, одняко ряд особенностей не позволяют ее использовать там где нужна поддержка целостности и прочие прелести которые есть в современных (да и не очень) РСУБД, + внезапно она не такая гибкая как тотже Postgres

Answer 2

[Макс]

я бы все-же постарался максимально процесс выборки данных отдать в СУБД. Такой вариант однозначно быстрее и надежнее.

Answer 3

[Кирилл]

У всех разное понимание "правильно". По сути все сводится к "либо все, либо ничего".
Если есть понимание как работает СУБД и её возможностей, вы скорее всего будете все выносить в нее: приложение будет туда только "ходить за данными" (дергать одну "хранимку" всесто кучи запросов), и записывать данные, опять же через "хранимку" и одним запросом вместо кучи. У нас даже "шедулеры" в самой БД (если они должны менять данные или что-то с ними делать).

Либо вариант когда СУБД выступает как хранилище строк с продвинутыми возможностями типа вторичных ключей и индексов + более развесистый синтаксис на "селект", такое обычно с MySql в виду его "особенностей"

Answer 4

[Dave]

В дополнение к тому что сказал Вячеслав:

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

2. Теоритически - также проблематично будет мигрировать на другую БД, скажем на MongoDB, к примеру. Ведь подсчёты жетско прописаны в определенном движке. А так придётся дублировать логику подсчетов в новом движке, что весьма не правильно.

3. Есть такой принцип - называется SoC. Так вот, он гласит что ответсвенности должны разделяться. Бизнес логика и вычесления - это одна ответсвенность, а хранение данных - это другая.

Comments

[Кирилл]

1. Нет, даже наоборот, просто тесты пишутся на sql и запускаются в БД
2. На другую БД в любом случае мигрировать проблематично
3. Давно РСУБД это просто "хранение данных" ?

[Dave]

Кирилл: 1. Допустим в запросе используются переменные и выполняются вычисления. Как для этого написать фикстуры? А ну ка подскажи? 2) Не верно в корне. Есть такой паттерн, называется Data Mapper (martinfowler.com/eaaCatalog/dataMapper.html) - Будь то MySQL/Mongo/Arango/что-угодно - главное чтобы они реализовывали один интерфейс. 3) СУБД - может больше чем просто хранить данные, и это понятно. Но когда речь о веб-приложениях и масштабируемой архитектуре, ответсвенности должны разделятся.

[Кирилл]

1) pgTAP как пример
2) ха-ха-ха
3) "речь о веб-приложениях и масштабируемой архитектуре" и тут да, возможности РСУБД использовать зло, ибо они ататат, зато Data Mapper засунуть можно, "ок"

[Dave]

Кирилл: 1) pgTAP - специфичен для PG. А как для любой БД написать, а? 2) Что ха-ха-ха? Аргументов против типа больше нет? 3) Практика разделения концепций - формировалась десятилетиями, и это можно сказать закон качественной архитектуры. А кто сказал что использовать возможности СУБД нельзя в Data Mapper? лолки))) Это в ActiveRecord/ORM нельзя - да (хотя можно через "raw" методы, если имеются в наличии)

[Кирилл]

Ну, как бы они, пускалки тестов, в том или ином виде есть для любой СУБД, да и самому пускалку тестов написать не та уж и проблема
Чем оно поможет при смене СУБД, хотя "легкая" смена БД - это больше маркетинговый булшит, но все же
Вообще дастовляет само существование "паттерна" "Data Mapper", что оно вообще значит, то что другой "паттерн" будет говорить о том что: "объект книжка должен самосохряняться" ? Дак вот, если уж, к примеру, драйвер БД может мапить строки на объекты (невидаль такая), то, вам, что есть "хранимки" что их нет, нужно переписать свое "ПО" чуть более чем полностью чтобы влезть в другую СУБД. Повторюсь, проблематика смены СУБД есть и всегда будет и до момента "Х" о ней даже думать не стоит и если назвать функцию сохранения/извлечения данных из СУБД хоть датамапером, хоть еще чем - это не поможет. Однако, тут как бы все гуд, но, вот эти вот оглядки на легко/не легко, паттерны/не паттерны, нагрузка/не нагрузка приводят к тому, что возможности СУБД не используются вовсе. При всем при этом что любая современная "РСУБД" это такой "монстр" на стероидах который моэет обрабатывать десятки тысяч транзакций в секунду, но в "умелых" ручках сдыхает при 10 Гб данных и 100 запросах

[Кирилл]

djay: пруф про "использовать возможности" Как организовать ленту обновлений с SQL базой данных? Как оптимизировать БД для highload проекта на перспективу? ну и т.д.

[Dave]

Кирилл: Судя по твоим комментариям, у тебя нет опыта работы в реальных масштабируемых и ты видать не работал толком в реальных условиях. Но обо всем по порядку, итак: 1) Твои аргументы по поводу "проблематичности разных DB" рабиваются в пух и прах этим примером - pastebin.com/JSD8x0tf 2) Ты видать даже не понял сути паттерна Data Mapper. Крайне рекомендую почитать книгу Мартина Фаулера - Patterns of Enterprise Application Architecture (ну хотя бы на досуге, там это всё разжеванно). 3) Все примеры которые ты приводишь не уникальны - с этим уже давно сталкивались тысячи других разрабов и решения имеются, искать ответы надо на сайтах типа StackOverFlow и Программерс.Стакесченг.ком...

[Кирилл]

djay: Каюсь, так и есть, не работал, пример с "выбрать книжку по id и удалить" впечатлил, правда вот не знаю как это поможет когда есть, скажем 1000-2000 запросов заточенных под конкретную РСУБД.
При этом использование примера выше, в силу того что ну вот нельзя взять проект и легким взмахом перенести, как бы избыточно, есть у меня метод который возвращает книжку по id GetBookByID() Book и SaveBook(Book) и гуд
Насчет примеров я не совсем уверен, т.к. особо ничего в пример и не приводил, однако и в поиске ответов на "StackOverFlow и Программерс.Стакесченг.ком" я тоже не особо уверен )

[Dave]

Кирилл: Выбрать книжку, удалить книжку - это всего лишь примеры, для демонстрации самой концепции. Я ж не буду рассписывать детально и тратить часы своего времени на это только чтобы тебя убедить, сам понимаешь. И да, пусть будет хоть 1 000 000 запросов в секунду заточенных под контретную СУБД - и что? Ты думаешь суть меняется от этого? В таких случаях, обычно в этом же методе маппера пишется специфичная логика/запрос касатально этой СУБД. И да, насчет примеров - а я вот уверен (исходя из опыта), обычно когда что-нибудь с хайлодом или смежными областями, я обычно задаю вопрос на СерверФолт.ком и обычно находится какой-нить вменяемый чел, который внятно и адекватно обьясняет. И тебе советую. Попробуй.

[Кирилл]

djay: ну 1 000 000 одинаковых запросов в секунду никого не интересует, а вот от переписывания всех что есть тот самый датамапер не спасает, ну да ладно. Я рад что когда у вас когда возникает ситуация: "обычно когда что-нибудь с хайлодом или смежными областями" вы находите ответ на СерверФолт.ком, это здорово что специалист, или как вы выражаетесь " вменяемый чел", находит время что-то там объяснить. За совет конечно спасибо, если вдруг мне приспичит что-то спросить, я им воспользуюсь ;)