NekZ,

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

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

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

skyANA,

продаолжаем.

Давайте глобальней.

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

если ОРМ выполняет прямое своё значение, это замечательно.

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

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

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

НО ОРМ, иишный.
позавчера узнал что этот шлак не умеет даже работать с базой толком - он не знает что ответ может быть множественным, и надо выбрать все результаты перед следующим запросом - результат, мультизапросы не работают.
но вчера узнал что и апдейт множественный не сделать с джоином.
тоесть база знает про связанные сущности, то толку от этого нифига нету, кроме как выборка множественная, можно считать что работает впринципе. вот написано кода по дебагу фигова туча, и идеи не плохие, но всё сыровато... возможно в 2.0 уже получше ситуация.

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

skyANAalex564657498765453НО ОРМ, иишный.
позавчера узнал что этот шлак не умеет даже работать с базой толком - он не знает что ответ может быть множественным, и надо выбрать все результаты перед следующим запросом - результат, мультизапросы не работаютиспользуйте ORM, что поддерживает multiple result sets :)

alex564657498765453так вот на тему ОРМ я забыл один из аргументов - а зачем нужно недоделанноеиспользуйте доделанный ORM :)

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

ORM - это тупо инструмент, который надо применять где следует, при этом для различных операций следует применять различные ORM-стратегии
Тоже самое с триггерами и хранимками

Возводить одно в абсолют, а другое называть шлаком - это глупо, не профессионально

ооо, вот наконецто пришли к противоречию.

я во всех своих постах писал, что ОРМ как конвертер програмного обьекта из/в стуктуру реляционной базы хорошо, а вот тащить туда то, что можно делать другими иструментами, притом массово плохо.

А это вы батенька, изволите считать, что ОРМ это хорошо, а остальное - один две максимум тригреа на проект как неизбежный костыль!!!

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

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

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

визуально, если у нас есть несколько хранилищ и наш код , то код будет в центре , а хранилища по кругу лучиками из центра подсоеденены. и стаёт очидно что в коде должна быть логика взаимосвязи между данными. НО ОРМ то тут причом? ваш пример кеш и реляционная база. где в кеше реляционность, а в ОРМ буква Р это и означает. это уже не ОРМ в чистом виде.

ладно.. заказаную норму холивара на ОРМ тему думаю выполнили...

Nekz, давай новую тему. например зачем надо ноускл базы. :)

skyANAА, или зачем нужен репозиторий в случае когда данные распределены :)

похоже вы занимаетесь поисковым сервисом на подобе гугла/яндекса, и считаете похоже - что это самая сложная задача!?

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

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

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

и тут как не крути. Крутые доктрины, skyANA и его клоны 10 человек(очень умных програмистов), но они за пол года дадут тот же результат - мусор, вто время как простые тригеры, которые как любит говорить мой начальник - дебил любой сделает - таки гарантируют что мы не будем иметь мусор - ресурс за который платим но он не используется.

я к чему виду, уважаемый skyANA.
есть задача, хранить два числа, а, и рядом с. А - может меняться как угодно, а С должно хранить величину - сумму положительных изменений а.
тоесть при каждом увеличении а, с=с+1, при каждом уменьшении а- с=с-1
можно конечно на ваять кучу кода, и кричать о гибкости, и даже это частично верно - но гарантировать это можно только тригером, всё остальное - действительно костыли, которые иногда будут давать осечку.

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

Так что подводя черту, наверно надо резюмировать.

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

есть задача удобсва хранения обьектов програмных в базе. это и разница в типах, ну например у меня в программе, есть набор значений да/нет, 8 штук, в базе это один байт, или хеши текст, но в базе яж не лох варчар40, у меня бинари20. и вот хочеться не задумываться о этом постоянно. ОРМ - самое что ни наесть решение этой задачи.

есть задача синхронизации данных между хранилищами(полная частичная функциональная...не важно как, суть что при изменении в одном хранилище, чтото должно поменяться в другом)
тут не то не то не решает эту задачу, это нужно создавать сервисы(с нуля или на базе существующих) которые могут приклеиваться к ОРМ и/или к логике зашитой в субд.

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

skyANAalex564657498765453, если вы реализуете бизнес логику на уровне СУБД, то пишите лучше хранимки.
Триггеры - зло :)
Это я как разработчик системы для нефтянки, работавшей на сотне серверов по всей России на Oracle говорю.

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

st_stПомню несколько лет назад читал обзоры крупнейших web-проектов (ебей, амазон и т.д.), все в один голос твердили, что любая логика в бд - злейшее зло, бд должна быть не загружена никакой лишней шнягой и отвечать быстро на любые запросы. БД у них - "тупое хранилище" с простейшими sql-запросами к ней, вся обработка только на application-серверах, которые просто добавляешь по мере необходимости или обновляешь из образа одним нажатием кнопки.

Насчёт ORM и смены субд - у меня на одном проекте MS SQL на винде, потребовалось часть базы перенести на сервер в другую страну к определённому хостеру, у которого нет винды, есть только линукс. Пришлось ставить mysql, mono и т.д. Но так как у меня в бд нет триггеров, хранимок и прочего, то перенос прошёл быстро и безболезненно.

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

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

Програмёрalex564657498765453Так что подводя черту, наверно надо резюмировать.

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

есть задача удобсва хранения обьектов програмных в базе. это и разница в типах, ну например у меня в программе, есть набор значений да/нет, 8 штук, в базе это один байт, или хеши текст, но в базе яж не лох варчар40, у меня бинари20. и вот хочеться не задумываться о этом постоянно. ОРМ - самое что ни наесть решение этой задачи.

есть задача синхронизации данных между хранилищами(полная частичная функциональная...не важно как, суть что при изменении в одном хранилище, чтото должно поменяться в другом)
тут не то не то не решает эту задачу, это нужно создавать сервисы(с нуля или на базе существующих) которые могут приклеиваться к ОРМ и/или к логике зашитой в субд.

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

"есть задача - контроль целостности данных, её решать лучше инструментарием самой субд" - да, именно так. Но, это не значит проверку входных данных, или перезаписывание связей. Это например использование внешних ключей, и запрет удаление записей, у которых есть связь по такому ключу. Всё остальное делает ORM (а также и саму проверку целостности свою проводит) :)

"есть задача удобсва хранения обьектов програмных в базе..." - ну да. То есть преобразование неудобных для объектного восприятия данных в удобные. Но для указанного примера я бы выбрал тип данных SET (mysql), а не двоичный или строковый (ничего лишнего не запишешь, и человекопонятно). Тогда на ORM возлагается лишь задача оглавления нужных констант, и чтение данного столбца как числовой. Далее задача сводится к определению установлен ли какой-либо флаг (это легче чем сравнивать 8 значений по очереди, проверяя интересующий результат). Так что тут в процесс хранения данных без необходимости лучше не лезть. Но если всё же лезть надо - тогда ORM

"если при создании юзера он автологинится, а логированые юзеры у нас в кеше, то врядли из базы его туда надо толкать" - небольшое отступление (не в обиду... для общего образования): "логированые" от слова "логировать", "лог"... "логинить" - "залогиненные" )) .
А если по теме, то как тебе кэш поможет при логине пользователя? Может ты имел ввиду сохранение сессии? Так это возможно только на клиенте :) Не забывай, что для базы ты всегда один и тот же пользователь при обращении из скрипта (если там конечно явно не указаны разные кейсы). Потому по сути в данном случае не вижу выбора как такового :) ORM

"с другой стороны, если идёт добавка товара на склад, и есть другая база, которая хранит табличку типо склад - сумма материальных ценностей на нём..." - дальше не смог осознать поток мыслей :) По тому, что тут написано (без учёта того, что дальше по тексту), как-то неверно подход выбран. Зачем вообще нужна вторая таблица?
Если человеку надо удобочитаемый вид в базе, для этого есть представления (на них таблицы отчётности строятся в 2 счёта... ничего извне не надо). Если же надо получить данные по складу (количество товаров, сумму и т.д.), для этого делается специальный запрос со стороны ORM к базе. То есть, для тебя это атрибут или некий метод склада, а ORM уже сама в базу запрос кинет нужный по выборке (COUNT, SUMM и т.д.). Зачем для этого отдельную таблицу (объект) создавать?!
Потому и тут ORM :)

Итак... итог по примерам:
1. Целостность данных (запрет на изменение и удаление данных с активными внешними связями, добавление данных без требуемых связей) - База. Всё остальное (типа автоизменение связанных данных) ORM
2. ORM
3. ORM и никак иначе
4. ORM

4 из 4 (то есть все) случаев связанных с логикой решаются средствами ORM.
Средствами базы производится только контроль целостности данных, на случай если у сервака электричество отберут, или ещё что завалится в момент записи. Все остальные вопросы целостности (проверка на правильность данных на входе, обработчики ошибок целостности и т.д.) регулируются посредством ORM.

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

эээ, ты начудил стрикоробо.

1)ОРМ проверка целосности - бред. простой пример.
вставка юзера, емейл уникальный индекс, база вставляет делая проверку на уникальность, и ок, или при проверке ошибка и возвращает. вариант через орм, делать в базу запрос, влюбом случае база возвращает ответ, есть совпадение или нету, и потом идёт вставка, которая - вот не задача...может оказаться неудачной, ибо уже такой емейл есть!!! аналогично контроль связи один к одному.при проверке все было нормально, а при вставке уже нет. так что я бы сказал даже так, можно решать через орм пытаться, но максимальный результат - это очень близко подойти к контролю целостности. итого 1 - НЕ ОРМ

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

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

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

тут даже не обсуждаеться ОРМ. что-то я не заметил чтобы отказывались от кластера базы, исопльзуя вместо этого ОРМ... кластер базы, пусть это какая нибудь галера для мускла - но принцип её тотже - на уровне базы действие одно. либо запись вставилась бронь, и все базы про это знают одновременно, или ничего не произошло.

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

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

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

представим себе ситуацию.
10000 юзеров одновременно логиняться, нельзя двойной логин сделать!!! и вот есть два варианта, сразу юзера логинить, вписывая сесию, при условии что текущее значение сессии не нулл, и сначала селект сделать а потом апдейт. тригерры сдесь нипричом - но ты каким способом пойдёшь? первым или вторым!? наверно первым.

ну а если 10000 юзеров создаються , то зачем ити вторым вплане нельзя два юзера с одним мылом/логином ?!

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