alex564657498765453я тебя правильно понял, а вот ты меня нет.
да, есть такое
alex564657498765453поясню
не помогло ((
как-то неструктурированно...
alex564657498765453есть обект, у него есть поле полное имя, которое есть просто конкатекация имени и фамилии.
если ты прямо в этом классе описал функцию, которая построит это поле, это нормально. если написал где-то в стороне функцию
которая смотрит на все существующие переменные, находит обьекты нужного класа, и через спл расширение вписывает им это поле - это хук, ибо новые значения влетели неизвесно откуда.
не особо всекаю при чем тут ооп, объекты и триггера в базе
я думал речь идет о месте размещения логики: в коде или в базе
наш подход: 1) только в одном месте, 2) и это место - код
alex564657498765453вот есть база, захожу я и вижу тригер на вставку,
у нас нет такого действия: захожу в базу и вижу
я его исключил на уровне архитектуры
все, что кодер знает про базу - это структура данных
ей он может управлять через код
ну и конечно у него есть доступ ко всем данным в базе, но он тоже ими управляет через код
а такого действия захожу в базу - такого действия нету
alex564657498765453смотрю ,понимаю, что при вставке нового елемента обновляються значения двух других, ибо это связанная логика. это прямое действие.
у нас подобные действия являются не хуком, как тут, а являются частью того или иного потока исполнения (алгоритма), то есть архитектура построена таким образом, что можно из любой точки А пройти весь путь до точки Z и быть уверенным, что никаких автоматических неведомо откуда срабатываний не произойдет. Все срабатывания всегда лежат на пути этого потока исполнения (алгоритма).
alex564657498765453а вот на пхп написаный код, это хук, ибо смотрю в базу и не понимаю, почему я туда заносил одни значения, а тут бац, и кто-то, нафигато , переиначил поля. более того, смотрю тут таблица с какогото перепуга появляеться и ищезает.
ну вот собственно триггеры и создают такую опасность
вроде писали одно значение, а херасе откуда-то вставилось другое
вот это херасе и есть хук
у нас такого херасе не бывает
а если какое-то херасе и происходит, то всегда можно пройтись глазами по всей соответствующей ветке алгоритма и это херасе гарантированно будет лежать прямо на пути этой ветки, либо эффект херасе иногда возникает из-за ошибки кода, но подобные ошибки всегда приводят к изменению самой структуры веток и в любом случае будет очень простой выход на ошибку
alex564657498765453ЗЫ
я понял что ты, написав опус выше, смотрел с точки зрения я пхпешник, всё остальное это плагины для моего мега кода.
нет, я не знал, что ты пехепешник
я просто думал, что ты любишь фаршировать базу логикой
и вообще я думаю ты фанат разбрасывания логики по разным местам системы)))
alex564657498765453но ведь это не так. база, центральный узел между твоими кусками кода которые запускаються независимо друг от друга(разные запросы на вебсервер) - это именно субд.
я что-то давно уже расстался с концепцией центра
мне ближе концепции атомарности, общения между атомами, специализация ответственности и т.п. вещи
alex564657498765453ЗЫЗЫ
счас модно говорить что ооп это круто, а без ооп, это куча хуков :) - изменение данных влетает не пойми откуда.
идея ооп, чтобы данные лежали вместе с логикой их взаимосвязи, изменения...
концепция ооп вообще не имеет никакого отношения к хукам
на ооп можно работать с хуками, а можно без них
ооп вообще не про это
alex564657498765453вот и подумай, где логичное место кода для
1)на каждую вставку записи про то что вася перечислил нам 10 баксов, обновить баланс у юзера вася на +10
в наших системах это реализовано так:
1.
user.updateBalance(userId)
под капотом эта функция собирает данные из платежной таблицы и складывает результат в таблицу пользователя
то есть тут используется архитектурный критерий: функция размещается там, где будет хранится конечный результат
интерфейсно, поскольку подобная функция очень дорогая, то она используется всего в двух местах:
1) кнопка "Пересчет" в форме пользователя для управления менеджером
2) кнопка "Нормализация" когда происходит обсчет всех пользователей (ну или выборки по фильтрам, вплоть до выборки всего одного) и перерасчет всех балансов (ну по этой кнопке ещё куча всяких разных обработок по пользователям происходит). короче суть этой кнопки в том, что если что-то не так, то нажимаешь, ждешь 20 минут и вся система отлично нормализована и все круто + список всяких расхождений, вопросов, сомнений, подозрений и т.п.
alex5646574987654532)при создании юзера, создать запись для этого юзера в таблице друзья и вписать другом модератора
у нас это реализовано так
1.
user.add({ userIdFriend : [user.getUserIdAdmin()] })
под капотом этой функции собран огромный набор инструментов, гибко, эффективно и понятно управляемый через входящий таскер, а комбинаций вариантов работы функции там тысячи и все это очень гибко завязано на интерфейсы и разные случаи. То есть в системе может быть до 300 различных вариантов вызовов user.add() с разными параметрами. Под 300 вариантов я имею ввиду если мы нажимаем Ctrl + Shift + F и вводим в поиск user.add( , то у нас будет найдено 300 строк во всем проекте
1.
2.
3)при вставке, что ты там вставляешь, у соседних записей,
обновить значения след пред - у текущей тоже надо выставить правильные.
у нас эта задача решается по-разному, потому что критерии что считать соседним меняются в зависимости от огромного количества внешних условий. для простых критериев типа: показывать только все нескрытые, это можно сделать простой обработкой как показано в этом топике или сейчас на тестирование отправлена новая фишка - динамическое изменение по ходу использования
alex5646574987654533 пример ещо интересен вот чем
допустим у нас
несколько процессов одновремено вставляют ещо одну.(20 пхп процессов)
это каждым собираешься всю таблицу обновлять???
мы такие задачи всегда решаем в каждом конкретном случае отдельно, потому что для нас главное вписаться в бюджеты денег и времени и частенько бывает, что в случае сложных коллизий иногда удается изменить саму задачу, а то и вообще её отменить
я кстати заметил одну вещь: по-моему ты тяготеешь к созданию систем с высокой долей универсального автоматически действующего кода ну типа я бы мог заподозрить, что в твоих системах 60-75% кода носит универсальный, фреймворковый характер, а в наших системах доля такого кода составляет 20-30%, потому что нам приходится работать в условиях очень часто изменяемых требований со стороны заказчиков и создавать решения, действующие в условиях сильной внешней параметризации со стороны пользователей
у нас вместо ваших 60-75% универсального кода, выстроена специальная архитектура и набор методов и подходов построения инструментов, ну мы используем что-то типа convention over configuration
ну в том же примере с расстановкой пре/пост индексов. у нас редко так бывает, что есть принципиальная возможность в момент создания записи сразу знать что для неё будет пре, а что пост, поэтому нам важно просто держать где-то под рукой протестированные способы расстановки пре/пост, а дальше уже в каждой конкретной ситуации подбирается наилучшее решение
alex564657498765453примеров кучу могу привести, когда мастерят костыли...чего я только не насмотрелся...таблицы аля семафоры, чтобы согласовывать работу разных пхп процессов, транкзанкции и отвалы по таймаутам, изза того что транкзанкции в очередь встали, а каждая притормозилась изза тормозов в пхп коде.... список большой, а пречина - которую ты хорошо знаешь.
если данные и код для поддержания логики с этими данными вместе, оно надёжно.
часто за смешивание данных и логики в одну кучу выступают апологеты хайлоада, но практика хайлоада показала, что часто для преодоления узких мест, вместо использования хуков, там часть подсистемы вообще решается либо на субд другого типа, либо вообще на чем-нибудь самописном под конкретную узкую-узкую задачку
ты много смешал разных тем в одну, но тебе так и не удалось убедить меня в смешивании данных и логики в одну кучу!!)))
