Как вы встраиваете SQL в свой код?

$topic = Topic::load($request->get('topic_id')); ... $topic->id()

А шош ты беря сырые данные из реквеста не проверяешь есть ли что-то в объекте топика али ни? Так жиш тебе пост создадут с нулевым топик-айди в лучшем случае. В худшем вывалит нотайсы. То же касается и прочих реквестовых данных при вставке.

А шош ты беря сырые данные из реквеста не проверяешь есть ли что-то в объекте топика али ни?

Так просто пример же.

Так жиш тебе пост создадут с нулевым топик-айди в лучшем случае

Скорее (в этом примере на практике), если доморощенный хакер подсунет кривой tipic_id, то просто вылетит Exception о вызове метода от NULL. Собственно, я машинально потому $topic->id() и вписал вместо уже имеющегося $request->get('topic_id'). У добросовестного юзера всё сработает штатно, а подсунувший левые данные получит ошибку (которая подробно прологгируется). Так что, в общем, можно даже проверку лишнюю не ставить (хотя, повторюсь, я об этом не задумывался на простом примере).

То же касается и прочих реквестовых данных при вставке.

title и text итак юзер может отправить любые. Так что лишней проверки тоже не нужно.

В худшем вывалит нотайсы

Вообще, я подумываю о «без-NPE-шной» системе. Когда NULL отсутствует как класс и от любого объекта можно вызвать любой метод. Просто в случае ошибок будет выходить Null-объект, любой метод которого — тоже Null. Вот тут придётся в редких местах ставить assert-проверки на not Null. Как, например, после загрузки топика. Что-то типа:

$topic = Topic::load($request->get('topic_id'))
    ->assertNotNull("Incorrect topic_id!");

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

В принципе, некоторые компоненты фреймворка так и работают уже. Но целиком переводить не спешу, т.к. много legacy.

Использую ORM.

Слишком велосипедисто.
Все должно быть просто.

Модели, либы, классы — НЕ ДОЛЖНЫ ничего валидировать и проверять и тем более бросать исключения по причине того что им не нравится что-то из поданного на вход.

Валидация должна проходить отдельно, до какого-либо подтягивания крудов. Но во время валидации можно и попользоваться чем-то, ридонли, например для проверки уникальности мыла в БД.

Так вот именно зафейленная валидация должна бросить иксепшн, который может еще и покакать в лог, а не какой-то там класс в момент вставки данных в БД, когда уже «почки отказали».

Таким образом твои модели будут тонкими, а волосы гладкими и шелковистыми. А тесты гонять в таком случае нужно только на валидаторах. И жрать это все будет сраные копейки. Это к тому что у тебя пых.

Модели, либы, классы — НЕ ДОЛЖНЫ ничего валидировать

1. В рассмотренном примере — не модель
2. Вся структура обычно и разбивается на классы. Классы моделей, классы представлений, классы контроллеров... Так что валидация в классах контроллеров — это как раз то, что нужно.
3. «Не должны валидировать либы» выглядить прикольно на фоне целой кучи библиотек валидации.

Валидация должна проходить отдельно, до какого-либо подтягивания крудов

assert — не валидация. assert — это контроль на некорректные данные, пропущенные валидатором.

Таким образом твои модели будут тонкими

Они итак настолько тонкие, что часто их описание содержит только человекочитаемое название типа объектов в yaml :)

А тесты гонять в таком случае нужно только на валидаторах

Задача валидатора — проверка входных данных. Задача тестов намного шире.

Кстати, что твой валидатор сделает при конфликте UNIQUE-ключа? Будешь создавать новый объект в валидаторе? А если и для проверки валидности, и для создания объекта нужен результат сложного запроса? Будешь его кешировать, вводя новую постороннюю сущность и обеспечивая связи с ней между модулями?

И жрать это все будет сраные копейки

Оно итак обычно жрёт копейки на фоне затрат самой БД.

Удобно использовать heredoc/nowdoc для SQL - кода

избыточный ОРМ не дает напрямую формировать запросы

весь запрос должен умещаться как бы на ладони

неосиляторы биндинга совершенствуют приемы работы с кавычками и не оставят бд без нагрузки

в идеале код лежит в статике или константах, когда осилен биндинг и осознаны масштабы инъекций

В рассмотренном примере — не модель, структура обычно разбивается, на фоне целой кучи библиотек валидации

Так и знал что придерёшься.

валидация в классах контроллеров — это как раз то, что нужно

Ужс. Т.е. у тебя контроллеры валидируют? Надеюсь что нет, а просто подтягивают валидаторы и просят их повалидировать.

assert — не валидация

А попытка глотнуть боржоми, я выше писал.

пропущенные валидатором

Это проблема валидатора что он такой хреновый как фаервол в оффтопике.

Задача тестов намного шире

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

при конфликте UNIQUE-ключа

Я ж уточнял — ридонли, никаких вставок и апдейтов.

результат сложного запроса

Так сделай его ридонли, зато при вставке/апдейте будешь уверен что уже все проверено. Обложись транзакцией если все так критично.

новую постороннюю сущность

Проблемы архитектуры.

итак обычно жрёт копейки

Сколько? Для меня копейки это 300-700 кб при скорости генерации 0.002-0.009 сек. без каких либо кешей и прочих. А для тебя?

Классы моделей, классы представлений, классы контроллеров...

Блин, MVC на сервере, конечно хорошо. А если оно уже присутствует на клиенте. Не жирно будет два MVC в одном проекте?

По возможности никак не встраиваются, юзаю ORM. Если по каким-то причинам приходится велосипедить, пихаю весь database-related код в DAO.

чтобы стыдливо прикрывать SQL?

Когда это использование высокоуровневых абстракцией для избежания катания на велосипедах с костылями стали «стыдливым прикрыванием» обзывать?

Да я не спорю. Просто интересуюсь.

А если, скажем приходится писать на трех языках одновременно. Использовать три ORM-a от трех разработчиков с разными дефектами мышления?

Для меня копейки это 300-700 кб при скорости генерации 0.002-0.009 сек. без каких либо кешей и прочих. А для тебя?

У меня на средней типовой странице одних SQL-запросов набегает на 0.2-0.6 сек :) На этом фоне что 0.002 сек. скрипт работает, что 0.05 сек — разницы нет. Даже 0.1 сек. роли большой уже не играют.

Ну и про память — совсем смешно. Вот уж во что на веб-серверах в своей практике никогда не утыкался. Даже когда недавно на одном проекте обрабатывал на пиковой загрузке до 108 тыс. человек онлайна (а всего хитов за сутки было что-то сильно за 10 млн, но уже не помню точно и миллиона полтора уников). Впрочем, и без памяти — один фиг, не тормозило :)

Использую ORM и не встраиваю SQL код в текст программы. В прошлом писал на PRO*C и PL/SQL, там все было вокруг SQL и такой проблемы вообще не возникало. Юзай ORM, они рулят.

INI, JSON, StoredProc - Всё в зависимости от _потребности_ и _окружения_. И причин зацикливаться на одном определенном способу хранения - ну никак не вижу.

Встраиваю прямо в код программы.

Как в соседней теме недавно говорил(а?) Iron_Bug — байтики считать нужно. И тут я полностью согласен. И ни о какой преждевременной оптимизации можно даже не заикаться.

Вот на твоем примере. Ты же выше кидал пример запроса с агрегациями. И скорее всего у тебя таких агрегаций, на фоне всего кол-ва запросов — много. Что тебе мешало нарушить нормальную форму и впилить таблицы статистики чтобы не делать группировки/мин/макс/авг/каунт, а делать простые запросы? Ну и обновлять в них данные единоразово во время каких-то изменений. Ну или вообще все эти счетчики хранить не в БД.

Тогда бы ты уже не писал что

на фоне работы SQL 0.2-0.6 сек. эти 0.002-0.050 роли не играют

А по поводу памяти — то-то я и вижу, что, чем современнее программа, тем больше она жрёт.

Вон последние линуксы еле шевелятся на старом железе. На последнем Ардоуре невозможно что-то записывать и сводить, он просто охерел до ресурсов. А ведь раньше им хватало. Про пых? ZF2 обсерился перед ZF1, в два раза, да, и по скорости и по памяти.

Новая версия программы должна лучше делать фичи старой, жрать меньше ресурсов и уметь что-то новое. А иначе это не прогресс, а регресс.

Вместо того чтобы грамотно продумать архитектуру, оптимизировать узкие места и прочее — прям так и вижу, сидят пейсатели, обложившись кучей либ, из которых юзают 2-3 метода, и «формочки клепают».

Я, кстати тоже сижу «формочки клепаю», но только там, где это уже въелось и не выгонишь. Ну а для себя то, для души — можно и «на спичках поэкономить». Ой, какой же унизительной успели сделать эту фразу, прям фу. Вместо того чтобы нормально делать — отмазались фразочкой.

https://cs7056.vk.me/c7005/v7005974/5caff/VUkhjjhK0tI.jpg

встраиваете SQL в свой код?

ты про язык или может фреймворк какой говоришь?

Фи, фреймворк. Мелко берешь. Проприетарная CMS на PHP отечественной разработки с Borland Database Engine в качестве хранилища

ты про битрикс+1с?

Да, это я пытался пошутить. Из вышепреведенных ответов можно судить, что большинство используют фреймворки с ОРМ. А те, что не используют - пишут sql прямо в коде

вот тут вот я плюсую. потому что действительно частенько в последние годы новый софт жрёт дофига ресурсов, тормозит и глючит. байтики считать стало немодно. заодно наплевали на всю оптимизацию в целом.
как пример: на прошлой работе (сотовый оператор) стояли мощнейшие хранилища данных EMC и брендовые сервера, которые стоили мильёны баксов, и которые едва не загибались под обслуживанием одной-единственной базы Oracle. и база-то была не сказать, что прямо слишком велика. просто никто никогда не запаривался с оптимизацией её структуры. изначально, много лет назад, по неопытности наплодили монстрозных таблиц и потом, когда накопилось дохрена данных, уже не хотели переделывать структуру, боялись вообще прикоснуться к ней: кабы чего не вышло. при этом со стороны админов были вылизаны все оптимизационные возможности системы, самой базы, всех каналов и т.д. но сама структура базы не давала работать эффективно. на один дохляцкий запросец баланса юзера серверу приходилось шуровать по огромным джойнам, агрегируя одни и те же данные из раза в раз. на фоне нескольких тысяч запросов в минуту это убивало на корню даже самое мощное брендовое железо. в итоге было принято решение рядом с этим монстром поставить махонький линюкс-сервачок, который отдельно, в своей маленькой in-memory базёнке, отслеживал и считал эти самые балансы и быстренько выдавал их по первому требованию. решение, так сказать, per anus ad astra. но оно работало, по крайней мере.
P.S. Ardour, кстати, старый пока юзаю. и что-то мне уже страшно стало переходить на новый. пока на старом меня всё устраивает, пусть себе работает. мне от него много не нужно, лишь бы писал в хорошем качестве на винт быстро и без заиканий.

Я старпёр и ретроград, и поэтому отказываюсь пользоваться чем либо кроме Oracle Pro*FORTRAN. Пробовал новомодные хипсторские поделки и нашел их намного менее удобными.

У тебя сервер - это по сути какой-то сервис, с которым «внезапно» умеет работать клиент, т.е. приложение, работающее в веб-браузере и используещее твой сервис. Я к тому, что ты можешь рассматривать клиентскую и серверную части как отдельные приложения, тогда и вопросов про 2 mvc не будет.

Когда клиент сам обрабатывает ввод пользователя и рендерит контент, возникает вопрос в необходимости M, V, и C на сервере

У вас проблема была не в этом, а в отвратительной культуре разработки (или менеджменте). Невозможно написать идеальный софт с первого раза. Софт пишется и развивается. А вы написали какую-то первую версию и оставили её работать в неизменном виде. Судя по всему и те, кто писали, куда-то подевались. При нормальной культуре разработки постоянно ищутся проблемы производительности и ищутся способы их устранения. А «боялись прикоснуться, как бы чего не вышло», это так бухгалтеры относятся к компьютерам, а не грамотные IT-шники. Ну или зелёные студенты к своему первому поделию размером больше 10 000 строк спагетти-кода.

А если бы вы с самого начала считали байты, этот софт просто не был бы написан вообще никогда.

когда уже закончатся любители хранимок?

а что в них плохого ?

скажу по собственному опыту: культуры разработки в этой стране нет. ну, мне не доводилось видеть. сейчас работаю на заграницу, требования гораздо выше, но и то не так, чтобы прямо идеально. всё равно там и сям я вижу косяки.
по-моему мнению, косяки происходят обычно от недостатка времени на разработку. когда разработчиков гонят менеджеры, в итоге принимаются какие-то временные решения, которые потом становятся постоянными. и нет ничего более постоянного, чем временные решения. как правило, у разработчиков нет времени не исправление и пересмотр. копится технический долг, обслуживать и дописывать такую систему становится сложно, и дальше всё по нарастающей. и обычно начальство этого не понимает и не выделяет времени на оптимизацию или полное переписывание старого глючного барахла. и так происходит во многих компаниях, где софт писался десятилетиями, разными программистами и с разными подходами.
я всегда стремлюсь с самого начала продумать всю архитектуру приложения, причём ещё и с учётом дальнейших возможных доработок (и про байты тоже не забываю). да, это занимает много времени. у меня 90% времени уходит на продумывание, а потом я быстро пишу код. код писать легко, когда точно знаешь, чего ты хочешь.

V на сервере - это набор данных, которые получит твое клиентское приложение. Как ты сформируешь эту V, твое дело, MVC - это просто один из хороших и проверенных временем подходов.

MVC - это просто один из хороших и проверенных временем подходов

Который, судя по всему, появился как способ организации GUI в Smalltalk-80. Впоследствии вполне резонно был перенесен на веб 1.0. Хотя, при желании и у JSON-RPC сервиса можно реализовать контроллеры и представления. Вопрос - нужно ли? Я не знаю

MVC сейчас это такой баззворд, который в 90% случаев имеет очень мало общего с тем MVC, который был в Smalltalk.

если бы вы с самого начала считали байты, этот софт просто не был бы написан вообще никогда

Не говори за всех сразу, ладно?

потом придумали ORM, чтобы стыдливо прикрывать SQL?

Не чтобы прикрывать, а чтобы не склеивать запрос из строк и работать с записью в таблице как с объектом.

Ну, склеивать это, конечно, вообще беспредел. Есть же биндинг. А вот превращение в объекты - идея хорошая. Правда, как продемонстрировал господин KRoN73, при малейшей сложности, идея скатывается в стыдливую эмуляцию синтаксиса SQL через функции языка. Хотя, наверное, есть ORM, которые делают это лучше

Правда, как продемонстрировал господин KRoN73, при малейшей сложности, идея скатывается в стыдливую эмуляцию синтаксиса SQL через функции языка.

Задача ORM не обеспечить «альтернативный синтаксис». А обеспечить переносимую реализацию связки бэкенда с объектами языка. Синтаксис может быть хоть копией SQL, если обеспечит нормальную работу с объектами решения. Это дело десятое.

связки бэкенда с объектами языка

Что дает эта запись кроме получения списка объектов?

echo $db->from('user')
    ->join('role', array('role.id' => 'user.id'))
    ->select()
    ->sql();

Каким образом эта запись связывает бэкенд и язык? Я правда не понимаю. Может я просто не достаточно умен чтобы понять

Что дает эта запись кроме получения списка объектов?

А что ещё нужно от ORM?

Каким образом эта запись связывает бэкенд и язык?

Не понимаю вопроса. Язык — то, на чём написан этот код. Бэкенд — любой, реализующий данный набор команд, хоть SQL, хоть NoSQL. Это в общем случае. В частном случае конкретного движка Saprrow — только SQL, но в вариантах mysql, pgsql и sqlite.

Я правда не понимаю

Я пока не понял, что тут непонятного :)

Что дает эта запись кроме получения списка объектов?

А что ещё нужно от ORM?

Тогда по твоей логике вот эта функция - ORM

http://lua.sqlite.org/index.cgi/doc/tip/doc/lsqlite3.wiki#db_nrows

Тогда по твоей логике вот эта функция - ORM

Это не ORM, потому что не обеспечивает загрузку объектов из БД и сохранение после их модификации.

Суть ORM — именно в реализации механизма связывания бэкенда данных и объектной модели языка программирования.

prepared statements + тонкие абстракции

не обеспечивает загрузку объектов из БД

Именно это она и делает.

сохранение после их модификации

Что я и пытаюсь выяснить битый час, связывает ли эта функция данные и сохраняет ли их после модификации?

echo $db->from('user') ->join('role', array('role.id' => 'user.id')) ->select() ->sql();

Именно это она и делает

Она возвращает простой хеш. А не инициирует данными объект со своими методами и логикой. И не обеспечивает последующее сохранение модифицированного кеша.

Что я и пытаюсь выяснить битый час, связывает ли эта функция данные и сохраняет ли их после модификации?

Да, загрузка — это только одна половина ORM. Вторая — сохранение. Хотя именно во взятом в качестве примера Sparrow сохранение ручное и не особо удобное. Я его приводил просто как пример синтаксиса с поддержкой JOIN.

Вот как в других ORM, так нагляднее:

Axon:

$product=new Axon('products'); // Automatically reads the schema
$product->product_id=123;
$product->description='Sofa bed';
$product->save(); // ORM knows it's a new record

Idiorm:

$user = ORM::for_table('user')
    ->where_equal('username', 'j4mie')
    ->find_one();

$user->first_name = 'Jamie';
$user->save();

В некоторых, например у меня, сохранение происходит автоматически по завершению работы скрипта (хотя где нужно — можно вызвать и принудительно, конечно) и я предпочитаю использовать методы, а не свойства:

$user = User::find(['user_name' => 'j4mie'])
    ->first();

$user->set_first_name('Jamie');
// $user->save(); — не обязательно

Так понятно. Спасибо

Ну, склеивать это, конечно, вообще беспредел. Есть же биндинг.

Биндинга бывает недостаточно, если у тебя есть переменное количество джоинов и условий в where.

идея скатывается в стыдливую эмуляцию синтаксиса SQL через функции языка

Ага. Но идея ORM не в том, чтобы заменять SQL.

$obj = Article::findPk(123);
// делаем манипуляции с $obj, меняем или не меняем поля, можем передавать куда-то, где его поменяют
$obj->save(); // ORM сохранит все измененные поля
// сделай это без ORM и ты увидишь, что подобный шаблон кода повторяется

Роман, что-то не вижу у тебя в примерах ОРМ-ов биндингов.

Ты их используешь вообще?

Роман, что-то не вижу у тебя в примерах ОРМ-ов биндингов.

Ты имеешь в виду привязку полей объектов к полям записей БД? Класс модели имеет метод table_fields(), который возвращает массив, элементы которого могут быть:

— Строкой. Тогда это одновременно имя свойства в классе и столбца в таблице БД.

— Хеш-элементом «строка1 => строка2». Тогда это указание, имя свойства класса = строка1, имя столбца БД = строка2.

— Хеш-элементом «строка1 => функция(строка2)». Тогда это указание, имя свойства класса = строка1, имя столбца БД = строка2. При получении нужно провести преобразование (например, UNIX_TIMESTAMP(Date)), при записи — обратное преобразование.

— Хеш-элементом вида «строка => массив». Тогда массив — это подробное описание поля (все элементы опциональны) — имя столбца, функции преобразования, человекочитаемое название поля для автоадминки, тип поля для автоадминки (в более простых случаях выше автодетектится), связанные классы, если это поле содержит ID элемента и т.д.

Модель может задаваться как в лоб в PHP, так и в YAML.

Если метод table_fields() не переопределён, то система пытается парсить БД и использовать её поля как свойства объектов. Но на практике оказалось, что это не лучший вариант. Через год простоя сложно работать с классом, не помня все поля в БД, постоянно приходится заглядывать в БД... Так что лучше один раз описать в классе. Тем более, что есть кривоватая, но команда в консольной утилите для преобразования тблицы БД в класс.

Примеры:

table_fields:
    country_id:
        class: aviaport_data_country
        title: Страна
        edit_type: combobox
        per_page: 20
        width: 640
    prefix:
        title: Префикс
    presentation_begin:
        title: Начало интервала представления
    presentation_end:
        title: Конец интервала представления

table_fields:
    cabinet_id:
    target_class_name:
    target_id:
    modify_time:
        name: UNIX_TIMESTAMP(`modify_ts`)
        is_editable: false
    create_time:
        name: UNIX_TIMESTAMP(`create_ts`)
        is_editable: false

А вот пример очень запутанного legacy-случая с прибиванием гвоздями:

    function table_fields()
    {
        return [
            'id',

            'type_ids_concat' => array(
                'field' => '(SELECT GROUP_CONCAT(type_id) FROM events_x_types WHERE event_id = events.id)',
                'is_editabe' => false,
            ),

            'alias' => array(
                'title' => ec('Алиас'),
                'comment' => ec('Краткое название на латинице для формирования ссылок'),
                'check_regexp' => '/^[\w\d]+$/'),

            'begin_date'=> array(
                'field' => 'UNIX_TIMESTAMP(`start_date`)',
                'title' => ec('Дата начала мероприятия'),
                'type' => 'date',
            ),
            'end_date' => array(
                'field' => 'UNIX_TIMESTAMP(`end_date`)',
                'title' => ec('Дата окончания мероприятия'),
                'type' => 'date',
            ),
            'title'     => array(
                'field' => 'russian_name',
                'post_function' => 'html_entity_decode',
                'title' => ec('Краткое название (наше)'),
                'comment' => ec('Наше максимально короткое название. Год обаятелен'),
                'type' => 'text:2',
            ),
            'original_name' => array(
                'post_function' => 'html_entity_decode',
                'title' => ec('Оригинальное название'),
                'comment' => ec('Так как называет мероприятий организатор с типом и всеми регалиями'),
                'type' => 'text:2',
            ),
            'nav_name' => array(
                'title' => ec('Навигационное название'),
                'comment' => ec('Наше полное название без типа с минимумом регалий'),
            ),
// ...
        ];
    }

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

Это параметрические запросы вида 'SELECT * FROM foo WHERE ID = $1' например для postgresql.

Понятно, что биндинг в рамках ORM непросто реализовать.

prepare и плейсхолдеры — это же внутренняя реализация бэкенда. Их может и не быть, например, если бэкенд — .json файл.

Приведённый пример запроса же — как раз тот случай, от которого и хотят уходить, начиная использовать ORM.

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

Работа с запросами не позволяет абстрагироваться от бэкенда и работать одинаково с любыми моделями. Плюс просто рождает больше возни и кода.

Что до редких исключений, когда в код нужно залезть руками — это можно сделать и отдельно с ORM.