-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Когда использовать ORM фреймворки?
- Автор темы G-SHEFF
- Дата начала
MiksIr
miksir@home:~$
Ага, код php использующий эту вьюху менять не нужно? Хоспади, ну бредоносец, еще про УГ что-то вещает.
Забудьте про тестирование, а то услышим новую душещипательную историю как вы уже 40 лет запускаете юнит-тексты... одни и те же. Я не готов к этому.
MiksIr
miksir@home:~$
nemo насколько я помню просто тупая малолетка было? Подучился? Сомнительно.
Да лан, хватает идиотов на просторах интернета. А вот игнора не хватает на форуме, это факт.
хотя врятли)
MiksIr
miksir@home:~$
Речь не о мнениях, а о стиле подачи, умении общаться с другими. Обосновывать свое мнение как-то иначе, кроме как "подрастете - поймете". Желательно еще отстаивая свое мнения не путаться в 3 соснах понятий предметной области. Такое читать никому не интересно. Хотите посещаемость - идите на какой-нибудь php.ru. Тут, к счастью, всегда преобладало качество над количеством. Только иногда "гении" вроде вас забегают, инквизиторы хреновы.
MiksIr
miksir@home:~$
Обоснуй. Добавляется новая колонка с новыми данными. Опиши способ вывода этой колонки пользователю не меняя php код, который будет работать с вьюхой, но не будет - напрямую с таблицей. За слова отвечать нужно, "не всегда" каждый мудак может сказать, вы же себя им не считаете? Вот рассказывайте.
caballero
Новичок
я всегда обосновываю свое мнение. То что ты не понимаешь - твои трудности.
уж не свои ли посты считаешь качеством?
особенно возражение на использование представлений что считается класикой - стандартом де факто у тех кто
делал хоть что то сложнее пары говносайтов на примитивной структуре БД и готовом фреймворке
caballero
Новичок
расказываю
есть случаи когда перечень полей вьюхи не меняется
например ты выбираешь данные для некоего отчета по юзерам
потом тебе говорят вот новое поле у юзера типа userdisabled и надо выбирать с учетом только живых юзеров
в этом случае меняется только код представления в PHP все остается как есть
если нет вьюхи нужно по любому вносить изменения в сайт и хорошо если еще в одном месте
даже если у вьюхи новое поле - то в PHP оно только добавляеться
но поле во вьюхе может быть результат сложного подселекта или типа того и без вьюхи этот сложных запрос придется на PHP писать что сложнее и менее удобно в отладке
опять же в промышленных СУБД вьхи пркомпилятся и оптимизируются а иногда даже делаются предвыборки и кеширование данных что ускоряет выполнение запроса
MiksIr
miksir@home:~$
Вы говорили про отображение данных, а переехали на поля - условия выборки. Ой как некрасиво.
Во-первых, код все-равно менять придется, ибо это поле с неба не берется, его кто-то должен устанавливать. Во-вторых, в случае наличия более одной вьюхи - придется менять их всех. Причем, программисту, который разрабатывает проект (а их еще может быть несколько) нужно помнить, какие вьюхи в базе данных зависят от этой таблицы. В случае нормальной ORM - в одном месте, увы, причем это место напрямую связано с изменяемой таблицей, т.е. потерять нереально.
И да, что же делать в нашем коде, когда понадобится взять все записи... например, для бекофиса? Придется лезть напрямую в таблицу или делать еще одну вьюху и работать с разными сущностями.
Ну и всякие мелочи, как скрывание для программиста логики работы, так как ему придется каждый раз ходить в базу смотреть - не вьюха ли это и как там фильтрация устроена.
И последнее, наш мастер нагрузок, блин - какой выигрыш получим для выборки одного юзера? А уверены, что получим выигрыш?
MiksIr
miksir@home:~$
Так можно ник узнать? Что бы проникнутся, так сказать, как вы развивали этот форум, а подонки пришли и все испортили.
caballero
Новичок
мы говорили об пользе представлений куда ты перехал твои трудности
и как я уже написал при добавлении поля которое не является просто копией с таблицы а является
результатом сложного запроса PHP код в любом случае исправлять наного проще - с его точки зрения добавилось поле хотя для этого поля может понадобилось два десятка SQL кода
с чего это вдруг
как раз в случае вьюхи и не придется - на то она и вьюха чтобы как раз скрывать особенности выборки с БД
и кому нужен просто юзер
посмотри на страницу этого форума - что тут выбирается просто посты или юзера , количество просмотров, ответов,
даты всяческие, надписи "понравилось" которыми вы тут хвалите друг друга. Уж поверь выбрать это одним представлением
или парой представлений которые легко приджойнить гораздо проще. и возможности для оптимизации выборки на стороне БД гораздо больше. особенно когда есть грамотный DBA и програмисту незачем лезть не в вою область
зачем спорить с очевидными вещами
какая разница кто развивал - важен конечный результат.
Представь что человек открыл страницу в надежде получить инфу а тут с тупым упрямством отрицают полезность представлений в БД лишь бы во чтобы то ни стало уесть чужака.
Не все так плохо. В нормальных средствах разработки все зависимости влет просчитываются. Что для таблиц, что для полей. Да и базой там занимаются отдельные люди. Обычно. PHP-девелоперы просто делают свою работу - просят данные и показывают их.
Участвовал в нескольких таких проектах. С Oracle. Не понравилось. Много слов на эту тему говорить не буду. Я - сторонник описания бизнес-логики на нормальном ООП языке. PHP, кстати вполне подходит под это описание.
Дальше. Возвращаясь к теме ORM. Использовал NHibernate в проекте на C# и словил только огромную кучу плюсов. А производительность тоже резко возросла. Из-за продвинутого кеширования, встроенного в саму ORM. В PHP, конечно, немного другая ситуация, но плюсов тоже больше.
В своей жизни я встречал уже несколько таких "знатоков SQL". У них тоже был только один аргумент - ты просто плохо знаешь SQL. К сожалению, ни один из них не сумел потянуть ни одного сложного проекта, который им доверяли.
caballero
Новичок
я тоже и не вижу тут противоречий с использований представлений - если бы шла речь
об использовнии хранимок триггеров и т.д. тогда другой вопрос
Ну в яве использование Hibernate обычное дело - но кроме плюсов (включая маппинг аннотациями) куча траблов - например неизбежное использование нативных запросов. Но как раз тут представления очень помогают потому как в результате на ORM мапится линейные структуры вместо витиеватого join кучи таблиц и не менее витиеватыми группировками.
так что никаких противречий. Если ты тоже хотел возразить из политических соображений то мимо. Только в отличие от предыдущего оратора который просто чушь несет ты написал то чему собственно особых возражений (по теме использования представлений) и нет
MiksIr
miksir@home:~$
Вам показалось. Я прекрасно знаю, когда представления нужны и работают, а когда они не нужны и являются лишь способом самовыражения.
С чего вы взяли, что это хорошо? Вы, извините, проповедуете хуйню. Не потому, что она вредная и не работает вообще. А потому, что она вредная и не работает в 99,99% случаев обсуждений на этом форуме. И это не показывает вас как профессионала с большим опытом. Это показывает вас как нахватавшегося юнца (не физически), который теперь пошел во двор показывать свою крутость. Ибо профессионал очень хорошо понимает, когда что стоит использовать и вообще обсуждать.
Это я к чему, вьюха - это отличный способ разделения ответственности. Еще это способ менять бизнес-логику, когда в исходном коде ее менять сложно. Тут оба способа не работают. Ибо во-первых, разработчики и архитекторы базы данных - одни лица, разделять нечего. Во-вторых, PHP легко изменяемый язык, как любой интерпретатор. То, что вам сложно поменять PHP, а легче написать километровый SQL говорит не о том, что вы гений SQL, а только о том, что ваш PHP инструментарий слаб.
И написание километрового SQL пусть скрытого за вьюхой в случае сильного PHP инструментария обернется одной-двумя строчками связи. Все.
ORM использовать нужно. Какую именно реализацию - зависит от ситуации. Все они разные, но говорить что "ограниченные" лишь подписываться под своей неграмотностью. ORM - это общий принцип. Все реализации этот принцип реализуют. Хотите красоты и гибкости - DM. Что попроще - AR. Нужно ковырять сразу огромные объемы данных в таблице - TDG. И разве что DM создан, что бы убрать SQL из объектов, остальные это не запрещают, пишите SQL... это все-равно будет ORM. Так что о хуйне спорите, разберитесь сначала.