Да нет там не глобальная переменная была, там массив передовался в один метод, обрабатывался, возвращался и в другой метод. Где именно, произошла перезапись сложно отследить 'тогда я правда не пользовался xdebug', да и не всегда заметно баг. Да и тут, правильно люди говорят, что массив или объект должны использоваться по ситуации, если система построена на MVC с прослойками абстракции, и там по архитектуре приложения используються объекты, значит мы должны использовать объекты. Если удобно, и это вписываеться в архитектуру, то нужны массивы, если становиться неудобно то нужен объект. В общем всем должен управлять сдравый смысл.
Если это одномерный массив да. Но когда многомерный, и его можно в любом месте, приложения перезаписать $array['test'] = 3 к стати как то я 3 дня искал баг, и как раз из за этого. Если у вас объект вы можете защитить данные разграничить классы которые могут туда записать и т.д. и слёгкостью отследить в какой момент произошла запись вызов сеттера(исли он реализован).
Да не всё нормально в PHP, просто когда на поддержке работаешь, особено после фрилансеров и веб студий, которые клепают сайты под ключ, довольно много непонятного кода. Но это во всех языках "кастыли" пишут и на c++, c, pascal, java, js, php в общем, "кастыли" "языконезависимые".
Вы стараетесь я стараюсь, а начинающие программисты не утруждают себя ставить элементарные скобки, и любят сокращёный синтаксис. Не давно на стэковерфлоу
Если посмотреть на zend coding style, то там написано что не следует ипользовать, сокращённый синтаксис. И это не просто так, так как усложняет понимания кода, не всегда явно видно что вот такая строка есть где то в коде $bar = $foo ?? $green;. И потом не всегда понятно от куда $bar = 'red' когда ожидалось $bar = 'green'.
MySql хороша по всем параметрам. Но когда у проэкта возрастает посещаимость и нагрузки. Начинаються проблемы производительностью:
Код который делает перебор разбор данных, рендер и т.д.
Маштабируемость, невозможно на уровне о.с. сделать, так что бы, было несколько серверов с mysql, и какойто сервер балансер который распределял бы запросы по серверам(разграничение нагрузки)
Иногда приложению, не необходимо хранить структуру данных(допусти страницу в cms, понимаю грубый пример но всё же).
Я люблю разделение труда команды, т.е. php программист это один человек, mysql проэктироващик и программист это другой, и третьи лица фронтэнд разработчики. Такая команда добьёться большего результата. Работая в одном направление в месте.
Мне пришлось переписать большую часть приложения для использования PHP7. Плюс не думаю что CMS WordPress будет его поддерживать. Так как в wordpress один большой кастыль. Да и говорить что мы полностью поддерживаем PHP7 в тот момент когда его небыло, как то не вызывает доверия. К сожаления PHP7(точнее расширения к нему) падает с segfault на 2-х машинах и только на одном работает(на домашней машине).
Большинству разработчиков, необходима лишь IDE, терминал(urxvt) и тестовая среда (для веб это браузер к примеру), всеми остальными приложениями удобнее пользоваться в консоли.
Я тоже должен извиниться, я только начинаю изучать mongoDB, и нахожу всё больше и больше плюсов по сравнению с sql, может это просто первое впечатление. Ну да ладно, оффтоп, спс за ссылку.
да нет не вся ветка, я в посте не привёл все данные 'сопутствующие' что бы легче читать было, в посте приходит id страницы. Если нет в посте reply производиться insert в монго т.е. комментарий первого уровня, а вот уже реплики на комментарий привязываеться к родителю(т.е. тогда когда есть reply ), по коду к стати довольно хорошо это видно, видимо плохо видно, видимо мой касяк.
Так то храниться отдельно комент и е го потомки в одном документе. т.е. получаеться при выборке коллекция комментариев, в которых есть дочерние элементы.
ok. Вы имеете id | parent_id | comment | name минимальный набор полей как построить дерево. Сделать рекурсию и к каждому корневому коментарию, выбирать с базы parent'ы. Ок, всё выбираеться. Но есть одно но вы сделали кучу запросов и сервер упал на этапе, просто выборки. Алгоритм выполняет много запросов и обрабатывает кучу данных, что не так оптимально. И так вы модернизируете алгоритм вводите понятия level и right_id и left_id что бы одним запросом вытянуть все коментарии, в порядке комент level1-> комент level2 ->комент level1 всё вроде бы просто…
Но вам надо сформировать массив вида comment['parent']->array(comment[]) думаю ясно логика, вы делаете перебор линейного массива и строите, древовидную структуру. Так вот вы взяли данные, выполнили операции перебора этих данных и модификации в массив. В монгоДБ мы просто сохраняем этот массив и просто берём его, тут вы взяли данные и не произвели над ними операций. Какой алгоритм лучше по вашему мнению? Да и видно что вы не строили древовидные структуры?
$array['test'] = 3
к стати как то я 3 дня искал баг, и как раз из за этого. Если у вас объект вы можете защитить данные разграничить классы которые могут туда записать и т.д. и слёгкостью отследить в какой момент произошла запись вызов сеттера(исли он реализован).можно и статическим методом обойтись, зачем каждый раз инстацировать объект, для выполнения одного вычисления?
лиш бы не ставить скобки )
$bar = $foo ?? $green;
. И потом не всегда понятно от куда$bar = 'red'
когда ожидалось$bar = 'green'
.Я люблю разделение труда команды, т.е. php программист это один человек, mysql проэктироващик и программист это другой, и третьи лица фронтэнд разработчики. Такая команда добьёться большего результата. Работая в одном направление в месте.
id
страницы. Если нет в постеreply
производитьсяinsert
в монго т.е. комментарий первого уровня, а вот уже реплики на комментарий привязываеться к родителю(т.е. тогда когда естьreply
), по коду к стати довольно хорошо это видно, видимо плохо видно, видимо мой касяк.P.S. Спасибо!
Но вам надо сформировать массив вида comment['parent']->array(comment[]) думаю ясно логика, вы делаете перебор линейного массива и строите, древовидную структуру. Так вот вы взяли данные, выполнили операции перебора этих данных и модификации в массив. В монгоДБ мы просто сохраняем этот массив и просто берём его, тут вы взяли данные и не произвели над ними операций. Какой алгоритм лучше по вашему мнению? Да и видно что вы не строили древовидные структуры?