Никогда так не делайте.
У меня есть функции которые занимают десятки строк,а могут занимать две. Но в первом случае я сразу нахожу то, что хочу поправить и быстро правлю во втором только сносить и писать заново, ибо даже я сам врядли без ошибок разберу это дело.
Анатолий K: точно, про crc32 забыл, попробую комбинацию, замерю производительность и решу. Нет не для сбора, хочу отказаться от назначения имен запросам, очень много запросов формируется динамически.
FanatPHP: а он и не говорит не используйте никогда, у него каждые 2 минуты звучит фраза "должны обрабатывать". Не использовать p: не есть панацея, выше я объяснил почему для pg. Кроме всего есть такая штука pgbouncer, тот вообще соединения в пределах пула не кладет. Впринципе понятно почему такая паника по поводу Mysql: порог вхождения низкий и люди с отключенными мозгами используют направо и налево, но база это либо нишевая, либо нафиг не нужная.
FanatPHP: чистит там не php а сам Mysqli вызывая change_user и отключить это поведение как я тебе показал не проблема. Тем более, что штука весьма медленная и не всегда нужнная.
Если ты сильно сдуешь свое ЧСВ и подумаешь что бывают не только сделанные как попало сайтики с нагрузкой 50чел/сутки то поймешь что бывают иные мнения. И уж подготовку запроса я бы не назвал экономией на спичках.
Anton B: если вы используете в одном вопросе то и динамический запрос вроде бы никчему. Использовать повсеместно - bad practice.
Во первых потому, что запроса там два, не лучше ли выбрать сначала те которые нужно обновить причем все сразу?
Во вторых auto_increment увеличивается вне зависимости от того вставили мы строку или нет (почитай выше к чему такое может привести)
FanatPHP: "не использовал но осуждаю" это про postgre.
Mysqli вычищает только если не стоит директива MYSQLI_NO_CHANGE_USER_ON_PCONNECT. Как раз чтобы "кодеры" не включали мозг.
ЗЫ я чето так и не увидел в ветке выше фрагмент "правильного" кода использования pg.
ЗЫЗЫ я бы сказал сударь что дураком скорей ты себя выставляешь втыкая свое мнение (не ответ) по всему тостеру, жуть кошмарная. Ну ничего, я думаю это пройдет когда будешь искать решение проблемы, а в ответ будешь получать сплошняком такие ответы. За сим пожалуй откланяюсь, не вижу смысла кормить агрессивных троллей.
FanatPHP: не использовал но осуждаю?)
У mysqli тоже есть персистентные соединения и их никто ничем не чистит, в обычном режиме соединение просто автоматом закрывается при завершении процесса. Но в mysqli при обычной топорной архитектуре никто обычно не заморачивается постоянными соединениями, pg же на каждое соединение стартует отдельный процесс, посему тут интересней.
Все якобы "проблемы" есть лишь особенности работы с такими вещами, не можете с ними справиться - не лезьте.
FanatPHP: там нет прочих проблем что он описывает. Забирать данные это само собой разумеется. Тут уж либо мозгами шевели либо класс-обертку пиши либо не пользуйся.
ЗЫ чего там про препареды между вызовами? какими вызовами?
FanatPHP: проблемы может и были но быстрое гугление ничего не дало. Да и Posgre сложноват для большей части похапешников и слабопопулярен. Большая часть не заморачивалась оберткой над стандартными функциями итд итп.
ЗЫ коли вы такой умный можно увидеть кусок кода как вы работаете с postgre?
Забавные вещи говорит, стоит часть послушать, однако вы невнимательно слушали докладчика: он говорит о проблемах если вы используете персистентные соединения где попало и ничего против не имеет использования их там, где они изначально задуманы.
Например он часто вспоминает MySQL, но большая часть проблем не имеет места быть при работе с php mysqli и он об этом упоминает(кстати предыдущее расширание уже года два как не рекомендуется к использованию). Остальные подводные камни имхо самособойразумеются и должны быть понятны при реализации логики.
ЦА лекции имхо в основном новички (относительно конечно). С таким же кстати успехом можно попугать людей сессиями, ибо 95% "программеров" про session_commit даже не в курсе и не догадывается о возможных проблемах.
FanatPHP: я не нервничаю, я удивляюсь к чему тебе тут столько оффтопа. Я задал вопрос - получил идеи - чудно. И тут фанат, оказался единственный кто во 1 сразу же начал текст с "ТЫ" и сразу же начал с разоблачения)
olamedia .: про разные базы или таблицы у вас в посте ни слова. Я так понимаю вы пытаетесь сортировать нечто вроде сложного union?
Если таблицы в пределах базы - используйте одну последовательность в обоих таблицах.
Если нет - проблема. Если не критична производительность инсерта, можно триггером назначать айди(в таблице 1 заканчивать на 1, в таблица 2 на 2 итд)
UUID не предназначен для таких целей, его задача - уникальность идентификатора.
FanatPHP: коллизии md5 я уже встречал не раз и не два, кроме того для тех же паролей md5 рекомендуется вообще никогда не использовать, зачем с ней носиться и кому именно стоить показывать я не знаю. Собственно как бы вы поступили мне не очень интересно. Далее по тексту идет совсем непонятный бред.
Давайте подумаем: все отлажено и работает, но при вводе нового типа именования запроса, видим ошибочку, которая намекает что количество параметров переданных и в запросе страсть как не сходится, да еще в таком запросе, где сам текст и количество параметров динамические. Отсюда делаем вывод, имя запроса соответствует неверному телу запроса, конец исследования, следующая задача.
