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