У меня аккурат этой ночью проводной интернет от ростелекома отвалился, еще думал, что с утра надо будет их дергать, а оно само к утру ожило. Мобильный интернет работал
Интересно, меняется ли что-либо в зависимости от того, оказываешь ли ты услуги юрлицу или физикам? Как входящие платежи фиксируются? Есть ли что-то вроде обязательных чеков, которые надо выдавать физикам?
Соглашусь, что в случае с Nested Sets обновлять ключи Left/Right у какого-то количества записей надо будет почти всегда. Но какие операции выполняются чаще - вставки или выборки? Насколько я знаю, выборка выполняется гораздо чаще - тут и выборка поддерева структуры, и получение списка элементов на определенном уровне конкретного дистрибьютора и пр. В случае с хранением пути это все выборки через LIKE '%x%', а в Nested Sets - выборка по индексированным числовым ключам, что однозначно быстрее будет. А уж если речь о бинарном дереве, которое очень быстро и неравномерно растет в глубину, и, стало быть, увеличивает длину пути, то выборка по путям особо тормозить будет
В данном случае худший случай это какой, вставка узла в корень? Во-первых, это крайне редкий случай в МЛМ. А, во-вторых, в таком кейсе у автора также будет апдейт всех записей (т.к. надо будет обновить путь для всех узлов)
Где же тут наглядность? Если нет нормального человеческого интерфейса, то наглядно лишь представление аплайна (что требуется не так уж и часто), больше никакой наглядности нет. Но если nested sets сложен для понимания, и увеличение времени запросов в разы (если не на порядки) не смущает, то можно и так, конечно.
А чем не подошел метод nested sets? Да, он чуть более ресурсоемкий при добавлении новых записей, но зато очень эффективен на выборках. Тем более, что при работе с MLM-структурами нередко требуются специфические выборки, например, сравнение двух веток, подсчет дочерних дистрибьюторов на определенных уровнях и т.д., и такой метод хранения структуры позволяет все эти операции выполнять одним запросом. И все это без LIKE, а на числовых индексированных полях
У нас все сложнее было - львиная часть кода вообще на ассемблере (во-первых, экономия памяти и производительность, во-вторых - управление всяким оборудованием, трудно было обойтись без ассемблера), а эта реализация Паскаля позволяла ассемблерный код вставлять прямо в тело процедуры, при этом из ассемблерного кода можно было обращаться к переменным и вызывать процедуры и функции прямо по их именам. Поэтому процедуры и функции оформлялись в синтаксисе Паскаля (заголовки, объявление типизированных переменных), а само тело - ассемблер. На чистом Паскале только интерфейс пользователя писался
Ой, прям ностальгия пробила! У нас, кстати, СМ-4 поставлялись с операционной системой ОСРВ СМ - "Операционная система реального времени для серии СМ", которая позволяла работать в многопользовательском многотерминальном режиме. По факту это была криво переведенная RSX-11 ("процесс из цомплетед"). Мы даже умудрились где-то найти оригинальную RSX-11 и работали с ней, а заодно с Pascal-2 для PDP-11, когда все кругом писали на Фортране
Вброс на вентилятор засчитан. Если принять все описанное за чистую монету, то можно сделать вывод, что, автор так и не смог найти нормальной работы ни на PHP, ни на Ruby, автор получал "фидбэки", но не получил работу (иначе не было б такой статьи, или она была бы совсем другой). Может, тогда проблема не в языках?
Немного смущает термин "быстрый" в заголовке. Если я верно понял из описания, то алгоритм, в целом, такой: 1) разбиваем поисковую строку на слова 2) находим записи по каждому слову из поиска 3) по всем найденным записям вычисляем релевантность 4) дергаем из базы записи в соответствии с релевантностью
Звучит все просто и логично (возникло даже желания в одном из своих проектов такой подход попробовать). Но насколько быстро это работает на больших объемах? Ведь п.2 может вернуть овердофига записей
Ладно, народ, потерпите немного, осенью обещали выдать отечественный сериал про Чернобыль. Судя по анонсам, там все будет закручено вокруг героя советского контрразведчика, который стремится вычислить американского шпиона, готовившего диверсию на АЭС.
Даже интересно, вызовет ли российский фильм такую же бурю негодования, будут ли так же громко возмущаться «лживой пропагандистской поделкой» те, кто недоволен сериалом от HBO, или это будет «ок, норм»?
Угу, более того, сценарист в интервью эпизод с вертолетом приводит в качестве примера, где они осознанно изменили хронологию событий, и не скрывают этого. Почему в художественном фильме это воспринимается, как преднамеренная ложь?
Что меня не перестает удивлять, так это то, что возмущающиеся «лживым» сериалом сами откровенно лгут. Который раз уже встречаю, что якобы Мазин заявлял о «100% правды», но почему-то никто не может процитировать, где он такое сказал. Может, потому что он такого никогда не говорил?
На всякий случай напомню, что одна из ключевых фигур сериала вообще вымышленная (и авторы этого вовсе не скрывают), и то, что сцена суда хоть и снята в максимально близком к достоверности антураже, но все ж полностью придумана сценаристом — это Мазин сам рассказывал. Как и том, что какие-то события они в хронологии сдвигали и меняли. Потому что это — художественный фильм, хоть и основанный на реальных событиях.
Вороватый ру-центр радостно потирает ручонки - тысячи новых непуганных клиентов, которым можно втихаря подключать ненужные услуги и тырить по мелочи
Поясните насчет 8.1, возможно, я от жизни отстал, но работаю локально под php 8.1 (и именно под OSP) и проблем пока не испытывал.
А если говорить о максимально приближении, то под Линуксом пилить надо (если, конечно, у вас прод не под Виндой и не под OSP)
Если речь про установку на локальном компе сугубо для разработки, то зачем возиться с ssl?
У меня аккурат этой ночью проводной интернет от ростелекома отвалился, еще думал, что с утра надо будет их дергать, а оно само к утру ожило. Мобильный интернет работал
Интересно, меняется ли что-либо в зависимости от того, оказываешь ли ты услуги юрлицу или физикам? Как входящие платежи фиксируются? Есть ли что-то вроде обязательных чеков, которые надо выдавать физикам?
Я не соглашусь. Во всяком случае, я такого тренда не вижу.
Соглашусь, что в случае с Nested Sets обновлять ключи Left/Right у какого-то количества записей надо будет почти всегда. Но какие операции выполняются чаще - вставки или выборки? Насколько я знаю, выборка выполняется гораздо чаще - тут и выборка поддерева структуры, и получение списка элементов на определенном уровне конкретного дистрибьютора и пр. В случае с хранением пути это все выборки через LIKE '%x%', а в Nested Sets - выборка по индексированным числовым ключам, что однозначно быстрее будет. А уж если речь о бинарном дереве, которое очень быстро и неравномерно растет в глубину, и, стало быть, увеличивает длину пути, то выборка по путям особо тормозить будет
В данном случае худший случай это какой, вставка узла в корень? Во-первых, это крайне редкий случай в МЛМ. А, во-вторых, в таком кейсе у автора также будет апдейт всех записей (т.к. надо будет обновить путь для всех узлов)
Если есть желание, то можно, конечно, поспорить, что будет отрабатывать быстрее: LIKE по строкам или поиск по индексированным числовым полям
Где же тут наглядность? Если нет нормального человеческого интерфейса, то наглядно лишь представление аплайна (что требуется не так уж и часто), больше никакой наглядности нет. Но если nested sets сложен для понимания, и увеличение времени запросов в разы (если не на порядки) не смущает, то можно и так, конечно.
А чем не подошел метод nested sets? Да, он чуть более ресурсоемкий при добавлении новых записей, но зато очень эффективен на выборках. Тем более, что при работе с MLM-структурами нередко требуются специфические выборки, например, сравнение двух веток, подсчет дочерних дистрибьюторов на определенных уровнях и т.д., и такой метод хранения структуры позволяет все эти операции выполнять одним запросом. И все это без LIKE, а на числовых индексированных полях
Вы не поверите, но я застал то время, когда платили за ПРОСМОТР банеров. И это были мои первые деньги, который я заработал в онлайне
У нас все сложнее было - львиная часть кода вообще на ассемблере (во-первых, экономия памяти и производительность, во-вторых - управление всяким оборудованием, трудно было обойтись без ассемблера), а эта реализация Паскаля позволяла ассемблерный код вставлять прямо в тело процедуры, при этом из ассемблерного кода можно было обращаться к переменным и вызывать процедуры и функции прямо по их именам. Поэтому процедуры и функции оформлялись в синтаксисе Паскаля (заголовки, объявление типизированных переменных), а само тело - ассемблер. На чистом Паскале только интерфейс пользователя писался
Ой, прям ностальгия пробила! У нас, кстати, СМ-4 поставлялись с операционной системой ОСРВ СМ - "Операционная система реального времени для серии СМ", которая позволяла работать в многопользовательском многотерминальном режиме. По факту это была криво переведенная RSX-11 ("процесс из цомплетед"). Мы даже умудрились где-то найти оригинальную RSX-11 и работали с ней, а заодно с Pascal-2 для PDP-11, когда все кругом писали на Фортране
Вброс на вентилятор засчитан. Если принять все описанное за чистую монету, то можно сделать вывод, что, автор так и не смог найти нормальной работы ни на PHP, ни на Ruby, автор получал "фидбэки", но не получил работу (иначе не было б такой статьи, или она была бы совсем другой). Может, тогда проблема не в языках?
Немного смущает термин "быстрый" в заголовке. Если я верно понял из описания, то алгоритм, в целом, такой:
1) разбиваем поисковую строку на слова
2) находим записи по каждому слову из поиска
3) по всем найденным записям вычисляем релевантность
4) дергаем из базы записи в соответствии с релевантностью
Звучит все просто и логично (возникло даже желания в одном из своих проектов такой подход попробовать). Но насколько быстро это работает на больших объемах? Ведь п.2 может вернуть овердофига записей
Даже интересно, вызовет ли российский фильм такую же бурю негодования, будут ли так же громко возмущаться «лживой пропагандистской поделкой» те, кто недоволен сериалом от HBO, или это будет «ок, норм»?
Т.е. Вы считаете зрителей дебилами, которые не могут отличить художественный фильм от документального? Что ж так плохо о людях думаете?
На всякий случай напомню, что одна из ключевых фигур сериала вообще вымышленная (и авторы этого вовсе не скрывают), и то, что сцена суда хоть и снята в максимально близком к достоверности антураже, но все ж полностью придумана сценаристом — это Мазин сам рассказывал. Как и том, что какие-то события они в хронологии сдвигали и меняли. Потому что это — художественный фильм, хоть и основанный на реальных событиях.