Вот фишка с циклом для меня новость. И че-то совсем не пойму, почему, если добавить новую ссылку на массив, то копирования в цикле уже не происходит. В чём тут оптимизация и что оптимизируется - для меня выглядит туманно
И в чем разница? Рекурсивная процедура ничуть не лучше рекурсии на php.
Речь не о рекурсивной процедуре, а о рекурсивном запросе.
Но и рекурсивная процедура будет лучше кода на php, потому что в случае кода на php будет послали данные - получили - послали - получили (query-fetch-query-fetch).
EuGen пишет:
50 JOIN - плохо, если данных действительно много.
Нуу не факт. Они не будут тяжелее того же рекурсивного CTE или рекусривной процедуры на стороне СУБД. Там ведь у первой таблицы берется одна строка, и каждая следующая таблица приджойнивается по первичному ключу. И потом все 50 джойнов не будут выполняться. Когда мускуль в очередном джойне не найдет данных, ему уже нечего будет джойнить. Хотя я призадумался, поймет ли он это. Надо поэксперементировать. Заодно и скорость рекурсивной процедуры посмотрю)
EuGen пишет:
То, что я предлагал с полным путем - вряд ли изящно тоже, так как в случае перемещения узла где-нибудь в середине пути будет очень много запросов на поиск и обновление (по сути обновить нужно будет все нижележащие поддеревья).
Но всё-таки, по-моему, это редкое явление - перемещение узла, так что эту затрату можно не считать большим минусом.
А что такого в том, что она длинная?)
Если набирать лень, то это можно сделать циклом. Если есть опасения, что мускуль такую длинную строку не съест, то нужно попробовать. Должен съесть. (Добавление)
Чуть выше, на 43 строке heredoc неправильно закрыт - его надо закрывать прям от начала строки без всяких пробелов и табов. И ниже несколько раз такая же вещь. (Добавление)
Даже тут в подсвеченном синтаксисе это заметно. PHP считает всю ту хрень одни большим хередоком и на 46 строке в нем не поймет как трактовать $myrow['login'] вот такой индекс массива
Столько раз, сколько достаточно, чтоб покрыть максимально предполагаемую вложенность. Ну и проверку, дотянулись ли до корня и, если не дотянулись, то в этом редком случае второй запрос.
xsh не надо этого делать. Вы занимаетесь хернёй. Лучше расскажите, почему функции завязаны на айдишки и что они делают. А мы объясним, как сделать грамотно.
По моим наблюдениям mysql начинает задыхаться на 30Гб таблице при интенсивных вставках и апдейтах.
Интенсивные - это до 50 в секунду в пики, но в среднем(точнее, медиана) около 450 в минуту. Структура таблицы 40 столбцов разных типов (в том числе варчары и даже один text). по 10 столбцам есть индексы (все индексированные столбцы - int и 3 столбца datetime). Таблица партицирована интенсивная работа идет с партицией размером 15% от всей таблицы.
В моменты пиков в логах вижу 2-3 в день сообщения deadlock found.
Сервачок сильный - 48Г оперативки, 4 проца model name : Intel(R) Xeon(R) CPU E5620 @ 2.40GHz
Так что либо у меня кривые руки в плане админства мускуля (хотя таблица эта до меня создавалась и вообще я почти в админсво не вмешиваюсь), либо 200-300Гб данных всё завышенные цифры.
int(10), 10 это максимальное значение, и его можно менять,например int(1000)
Бред. (Добавление)
Есть bigint (от 0 до 18446744073709551615 если unsigned). Сколько в него влезет, столько строк точно можно. Если обеспечивать PK одним столбцом не нужно, то можно сувать и больше строк. Не знаю, есть ли ограничение, но диапозона чисел bigint более, чем достоточно.
unsiogned int - от 0 до 4294967295. Число в скобках - это число десятичных знаков при отображении, а не максимальное значение никакое, как утверждает Данил_123.
Данил_123, воздержитесь пожалуйста от не соответствующих действительности высказываний
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 4334
