модель, однозначно нужна. ну по простому -

модель file



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

вот в этом плане модель нужна! но зачем если в файловом хранилище есть команда move, реализоваывать ей в модели через copy+delete

если база само может тригером изменение поля залогировать, то зачем это в модель тащить

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

NekZalex564657498765453,

Прочитал твой поток сознания пост. Что бы хотелось заметить -- ты мыслишь больно узко, смотря только на связку PHP/MySQL и всего, что отсюда вытекает, поэтому и выводы делаешь соответствующие. Вопрос стоял шире -- зачем-нужен-ORM?
Если мы обратимся к DDD подходу, тут рассматривается построение модели предметной области и вся бизнес-логика будет заложена именно в клиентском коде (толстом клиенте), т.е. не в базе данных, на триггерах, хранимых процедурах, представлениях и прочем. Подход с перекладыванием бизнес-логики в БД, привязывает вашу программу к именно этой базе. А что если сойдутся звёзды, и, тебе придётся переходить на PostgreSQL, то все ваши хранимочки придётся переписывать на другой встроенный язык БД? No way!
Перекладывание вычислительной мощности на клиентский код решает множество проблем, в т.ч. и распределение нагрузки.
Отслеживание онлайна юзеров -- почему бы не использовать memcache/redis для этого и хранить все ID пользователей в быстрой памяти.
На базе сферического в вакууме ORM'а можно построить неплохую модель предметной области, полностью абстрагируясь от используемой системы хранения данных, будь она в памяти, на диске, а может быть сразу на разных серверах и в памяти клиентского кода одновременно, со всеми кэшами, триггерами/коллбэками и прочим

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

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

я противник именно того что всё тащат в этот орм. вот это зачем???

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

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

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

третий, зачем орм проверяет уникальность емейла нового юзера, вместо вставки записи и в случае ошибки анализировать её(что ты там говорил про разгрузить базу???)

четвертый - обновление преагрегированных данных.

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

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

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

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

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

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

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

Програмёр,

Тоесть ОРМ не нужен! но изза того что это хорошо для бизнеса, надо делать?

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

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

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

а в ОРМ зачем тащить фукнции по контролю целостности данных?

давай детальней.
1)- зачем орм учим при вставке отдельным запросом проверить уникальность емейла, вместо просто вставки, а в случае ошибки, драйвер текущей субд нам сообщит - мол UK_user_email
а у нас есть масив сообщений про ошибку, что если с этим индексом трабла возникла - выдать, такой емейл уже есть.?

2)- зачем в ОРМ тулим, что после вставки связанной записи, для преагрегированного счётчика числа дочерних елементов надо +1 сделать и подобные действия...когда всегда изменение данных требует действия в другой таблице(другой записи) (NSTree например)

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

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

так и цмс комплектовать с разными субд.

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

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

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

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

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

Програмёрalex564657498765453,

1. Для работы с php на высоком уровне достаточно иметь одного узко квалифицированного работника, а для работы с mysql + php на том же уровне - двух узко квалифицированных, или одного "профи на все руки". (важно для бизнеса. определяет стоимость разработки и сложность найма исполнителя)

2. Удобство "цельной логики". Объект является самодостаточной сущностью, и ему не нужно ничего дополнительного извне (в том числе из возможностей БД). (мне было бы не удобно, меняя логику работы модуля, менять его модели, а потом ещё и в базу бежать и смотреть, не связано ли там это изменение с чем либо. А так открыл модель, и всё видно)

3. При разворачивании CMS на новом хосте, ты представляешь какую адскую работу нужно будет провести по созданию разных триггеров, связей и т.д.? Разумеется это можно сделать автоматом (скриптом), но если CMS работает с 4-мя типами баз, то это же надо предусмотреть для любой из них.

Ну вот вроде 3 основных момента на мой взгляд: простота, удобство, универсальность (краткий итог описанных пунктов)


А насчёт мудизма клиента, не обязательно так. Может у него уже сервер/сервера работают, и там уже установлена, настроена и обслуживается админом некая база данных. Ставить ещё одну - лишние сложности... легче заюзать то, что есть :)

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

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

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

NekZ,

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

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

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 вставок , и на каждую вставку у связаной записи надо поле обновить!!! зачем делать два запроса? а если три, обновить у родителя, и у дедушки... транкзанкция? и зачем родителя лочить, чтобы больше никто не мог ничег осделать, потому что у нас между вторым и третим запросом сеть начала лагать, или сервер в кому впал, и запрос только через минуту отослался...