Вы, наверное, слышали, что все данные хранятся в двоичном виде. Не все десятичные дроби можно точно представить в двоичном виде, поэтому тип данных обеспечивает точность не всех знаков, а определенного числа знаков.
На самом деле проблему можно решить гораздо проще:
Alex_pac пишет:
<b>hello<b>привет</b> world</b>
такого просто не должно быть. Это не валидно. Внутри <b> не может быть другого <b>, поэтому, в зависимости от нашего желания, наша регулярка в праве выбрать любую пару <b></b> и проигнорировать остальные <b> и </b>. Например, /\[b\].+?\[\/b\]/ и без всяких recursive.
Она будет и проще, и быстрее. А написание парсера, "корректно" обрабатывающего невалидные данные - странная задача)
А еще есть рекурсивные подмаски - (?R) http://php[dot]ru/manual/regexp.reference.recursive.html
Наткнулся на свой же глупый вопрос) Теперь, когда я стал умнее, напишу, что решением этой проблемы является HAVING - в нем можно указывать фильтры по вычисляемым в списке полей выражениям. Штука с select from select конечно тоже работает, но если эта тема кому-нибудь попадется, то о хэвинге тоже надо знать
SELECT t2.id FROM tbl t1 JOIN tbl t2 ON t2.parent_id = t1.parent_id WHERE t1.id = 2
UNIONALL
SELECT t3.id FROM tbl t1 JOIN tbl t2 ON t2.parent_id = t1.parent_id JOIN tbl t3 ON t3.parent_id = t2.parent_id WHERE t1.id = 2
...;
DELETEFROM tbl WHERE id IN(SELECT*FROM __tmp)
2. Создать строковый столбец pathToRoot, содержащий для каждой строки путь к ней со всеми айдишками с разделителем типа 0,2,33,44
и удалить delete from tbl where pathToRoot like '0,2,%'.
pathToRoot обновлять триггером при вставке и обновлении. Правда для обновления значений pathToRoot в дочерних строках придется дополнительно вызывать что-то типа update tbl set id=id чтобы триггер всё проставил (либо делать update + replace приложением)
3. Внешний ключ с каскадным удалением (не знаю, будет ли работать, но почему бы нет)
Мне прочему-то кажется, что в том случае, когда Вы не можете преодолеть 2 147 483 647 , и виновато приведение к инту на стороне пхп, вариант всего один: у Вас 32 разрядный PHP, поэтом в инте всего 4 млрд чисел, из которых 2 положиткльных
Надо бы сделать чтоб один и тот же топик был всегда доступен по одной и той же ссылки, куда бы его не переносили.
Во-первых, эта ссылка шлется автору топика при создании темы и при перемещении с изменением ссылки потеряется.
Во-вторых, индексируется поисковиками и при перемещении со сменой опять-таки теряется.
В-третьих, если тема перемещена, пока кто-то пишет в ней ответ, то сообщение не сохраняется и может стать обидно.
RomAndry, надо бы, наверное. при переносе темы в другой раздел, чтобы автору слалось письмо об этом. А то авторы, не найдя по ссылке, которая им пришла при создании темы, свою тему, начинают создавать новые. Или просто в непонимании обижаются
Hapson, md5 имеет такое свойство, что во-первых из хеша невозможно вычислить исходное значение (только подобрать). Во-вторых, изменение входных данных ведет к непредсказуемому изменению на выходе. Соль - это как раз такое изменение данных на входе.
Соль, состящая из всякого бессмысленного набора символов с большой вероятностью делает хеш не словарным. И не важно - знаем мы соль или нет, нам это мало поможет.
Универсальное решение, видимо, только одно - то, которое привел EuGen. В принципе, это первый курс колледжа, приходит в голову довольно быстро. (Добавление) Contr, можно пез первого cte с лимитом. Его можно использовать и в анкорной части рекурсивного cte. (Добавление)
Ну а вот еще решение:
SELECTDISTINCT fid FROM profile_fields WHERE name ='profile_last_name'
) t
LEFTJOIN profile_values pv ON pv.uid = cof.courier_id AND pv.fid = t.fid
И создать для этого один индекс по pv.uid и pv.fid вместе.
Еще, как говорили, подзапрос к profile_fields можно выполнить заранее и подставить полученные значения. Но это нехорошо, если он может возвращать большое количество записей.
Еще у меня все-таки есть предположение, что большинство лефл джойнов могут быть иннер. Это должно позволить уменьшить число 4636 из експлейна.
А вообще, если вы приложите дампчик, я с интересом поэксперементирую.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 4334
