Я не спорю с простым запросом. Это я понимаю как сработает. Я говорю, что когда мы выполняем допустим запрос один большой(три четыре объединения) или 3 и более простых запросов. Как Вы думаете, что в данном случае быстрее выполнится?
Не понимаете разницу между вызовом одной процедуры с миллионом запросов и вызовом миллиона процедур с одним запросом?
А вы можете мне ее объяснить? Просто Вы сами понимаете что там происходит.
Давайте как я понимаю. А Вы меня поправьте если что
Итак.
Я создал процедуру. Руками, скриптом не важно. Что с ней происходит дальше??? Она я так понимаю в скомпилированном виде не храниться. Или храниться?
При вызове запроса (не процедуры) затраты будут следующие: распарсить запрос и выполнить его Так?
При вызове процедуры вызвать ее подставить данные(распарсить их) и выполнить запрос.
При одинаковых условиях тут нужно просто определиться что быстрее сработает? распарсивание запроса или данных для процедуры.
Точно так же он закеширует если запрос будет прекомпилирован. И не забывайте про накладные расходы по самому вызову процедуры. Вызов миллион процедур не самое удачное ее применение. Вот если в процедуре вызвать миллион запросов это другое дело.
Если я правильно понимаю то вызывается сие чудо так
CALL insert_many_rows(1000000);
Она вызывается один раз. И тут нет подготовленных выражений. Я прав?
фактически это равносильно
Я прав? И если я прав, то объясните мне пожалуйста очень интересно. Как процедура оказалась быстрее почти в 3 раза. Если все процедуры MySQL медленные?
Нравится может девушка а не размазываение бизнес логики между кодом сервера и процедупами.
Хорошо специально для Вас
Цитата:
Для каждого соединения (connection) ведется отдельный кэш планов
выполнения хранимых процедур, но только в рамках соединения.
Цитата:
Сервер кэширует планы выполнения хранимых процедур, что снижает накладные расходы на повторные вызовы
Следовательно в примере с 1000000 строк сам запрос не кэшируется, т.к процедура вызывалась один раз или может я не правильно понимаю кэш планов?
т.е быстрее он выполнился ...
Цитата:
Хранимая процедура работает гораздо быстрее,главным образом из-за отсутствия накладных расходов на передачу по сети, разбор, оптимизацию и т. д.
Это справедливо для простых запросов. Но сложную логику можно и на PHP сделать
caballero пишет:
В принципе можно такой алгоритм - если возвращается нормальный код то оставляем как есть, если код ошибки заведемо определенный с скрвера - возвразаем обратно. Если код непонятно какой перечитываем страницу.
Я Вам разве не про него писал??? Т.е фактически мы получаем следующее. Если все нормально сработал ajax пользователь спокоен все хорошо.
Если приложение написано без ошибок(в PHP и запросах), то следовательно 99% запросов будут летать..
А ошибки на то они и ошибки, чтобы их исправлять
Ошибки соединения мы тоже обошли. Все счастливы и довольны. Осталось только не лениться и написать 10-20 строчек кода и все будет хорошо.
Черт с ними с процедурами. Пускай каждый решает сам, мне они нравятся больше.
caballero пишет:
Ну и ты определишь когда произошла ошибка до вставки в БД или после. У тебя инет сбойнул - HTTP протокол это тебе не транзакционная БД. Или скрипт завис потому что что ты своими манипуляциями надул память и вызвался сборщик мусора который в большинстве яваскриптовых движков - тупой как сибирский валенок. Или просто по таймауту отвалился от сервера.
Во-первых это единственная проблема. На вскидку прямо так если:
Итак по умолчанию timeout=60 сек(писали выше я если честно не знаю)
Я если правильно понимаю сработает .error() запроса==> принудительно обновляем страницу. Js это умеет.
Иначе complete()--->по рез-ту запроса опять же флаг 1/0.
В обоих случаях сначала выводим сообщение типа "произошла ошибка". Да и можно перегрузить страницу, это тоже не критично.
Ну как сработает нормально?
На счет утечек памяти. Я уже писал. Что в принципе на это стоит обращать внимание, но с другой стороны допустим jQuery постоянно развивается. Они сами же его оптимизируют. Если есть желание можно найти тесты и т.д. Баги которые обнаруживаются устраняются. Я ведь не призываю пользоваться beta версией. Использовать стабильный релиз.
Единственно по работе, я столкнулся, что при отладке при большом количестве вставок DOM и включенном FierBug-е да появляются тормоза. При выключенном все работает как секунды.
Ну и где тут сказано что выполнение процедуры с запросом быстрее того же запроса выполненого напрямую.
Пример выше Вы я так понял не читали??? Про миллион вставок???
Ссылку я привел про целостность данных при процедуре.
caballero пишет:
Разумеется, к и все что руководствуется принципом "я хочу" вместо "имеет смысл и необходимость".
При чем это хотение совершенно не согласовывается с надежностью системмы.
Это Вы заказчику объяснить попытаетесь?
caballero пишет:
Переместил товар отправил апрос на сервер - инет глюкнул. В базе одна сортировка на странице другая. пошел перемещать дальже - в базу пошли цже кривые данные и т.д.
Вы вообще представляете как это все работает??? Логику и внешний вид??? На каком этапе может произойти сбой если система построена т.о
Я нажал на клавишу мыши захватил строку. Начал перемещать.(для особо кривых рук, можно указать куда (по направлению горизонт/вертикаль) и родительский элемент )
Пока я не отпустил мышку ничего никуда не отправляется.
Я отпустил(если на туже позицию тоже ничего), а вот если позиция поменялась тогда ajax.
Где callback-функция содержит проверку, если ошибка, то вернется все на место.
Страница не перерисовывается, она готова полностью к дальнейшей работе.
Даже если на этапе отправки запроса произошел сбой. Единственный сбой, который сложно предусмотреть, это разрыв соединения по timeout. Тут нужно просто подумать чуток. Как определять тип ошибки т.е ошибка соединения(и тогда одно) или все-таки ошибка в приложении. И дествовать соответственно.
Это положительно сказывается на безопасности и позволяет более
точно управлять привилегиями. Типичный пример – хранимая процедура для перевода средств с одного банковского счета на другой;
она выполняет операцию в контексте транзакции и протоколирует ее для последующего аудита. Можно дать приложению право вызывать хранимую процедуру, не открывая доступ к используемым в ней таблицам.
Это цитата из книги. Человека, который разрабатывал(-ет) MySQL
Цитата:
Хотя для абстрактного примера имеющего мало общего с практической реальностью и решений нормальных не бывает.
Идея выводить товары, так как я хочу не по цене, названию ... А просто ткнул хочу первым, хочу вторым. Это абстрактная идея?
это на одной странице? напомните кто там говорил о юзабельности.
А у нас style="display:none" Не работает уже?+Поиск по странице нужного товара ни как?
Таблица
id name sortorder
1 товар1 1
2 товар2 2
3 товар3 3
4 товар3 4
...
При выводе на странице сайта ... Order by sortorder.
Вот теперь я хочу чтобы товар с id=1 выводился третьим
Т.е таблица будет станет такая(теоретически)
1 товар1 3
2 товар2 1
3 товар3 2
4 товар3 4
А потом id=3 выводился 4
1 товар1 2
2 товар2 1
3 товар3 4
4 товар3 3
Вот поидее как должно получиться???
Вот теперь как это сделать? Я реально не понимаю как вы это собираетесь делать?
Поэтапно я знаю как, а тут ...
P.S На счет медленных процедур там пост выше есть.
именно - источник любое вменяемое руководство по проектировани БД. При чем неважно какой БД. Никто в своем уме на напишет что процедура выполняется быстрее простого запроса (даже с учетом прекомпиляции)
Странно, а Петр Зайцев и Ко в книге Оптимизация MySQL почему-то пишет по другому.
(там пример есть INSERT 1000000 строк разница процедура 101 vs Клиентское приложение 279 vs
Клиентское приложение с соединением через MySQL Proxy 309 в секундах)
Правда он тут же пишет что выигрыш дается на простых процедурах. А на сложные мы и не замахиваемя . Почти в 3 раза, ерунда какая.
А на счет
Цитата:
Не очень понимаю. что такое порядок сортировки для конкретного товара а не для конкретного поиска по каталогу и тем более зачем это запоминать в БД. В любом случае если сортировка в пределах страницы - на сервер ходитть незачем, а если вывод многостраничный - вам все равно придется перерисовать полстраницы. Уж лучше тогда взять готовый jqGrid где уже все реализовано. Упаритесь писать руками - убедитесь сами когда перейдете от слов к делу.
Есть группа продукты. В ней находятся товары 100шт. Нужно одновременно(т.к страницу не перегружаем пока все не поправили) Вот я переместил (хотя я даже не понимаю каков интерфейс данного чуда) один продукт с 96 позиции на 15 , и другой с 50 на 85.
Переместил(отметил новую позицию). Нажал сохранить. Вот теперь подскажите пожалуйста каков запрос MySQL.
есть поле sortorder, по нему выводятся товары(как раз ORDER by). Мне надо поменять порядок(изменить sortorder у конкретного товара) Как это сделать В вашем варианте? Особенно если меняются 2 товара, а страница не перегружается до момента нажатия кнопки?
Как поменять в моем варианте я знаю, причем поменяется только то что надо(если с 5 позиции на 10 а базе 10000 записей) запрос затронет только 5 позиций
В вашем варианте, я так подразумеваю надо делать UPDATE всей БД?
Цитата:
Очень медленные и неэфективные - Mysql это не промышленная БД. И потом лишний запрос он всегда лишний даже если в процедуре и на оракле.
По сравнению с чем? Простого запроса? Можно источник информации? Я думаю иначе.
Цитата:
Скажем так, исключительно хлопотно - это браузер а не редактор, не предназначен он для такого.
Спорить не буду не думал я пока об этом.
Цитата:
Все что делается корректно. А не что некоректно - юзер промахнулся мышкой а пока разобрался на складе уже накладные распечатали.
Это как-то не впечатляет, он ошибиться и распечать могут по любому
Цитата:
Для подобных систем нужно сложные проверки на сервере при изменении, которые если и делаются одним запросом то весьма навороченным.
Тут наверное как раз транзакции и процедуры, триггеры могут помочь???
Цитата:
Не будет нормально работать это через асинхронку. Либо блокировать страницу за каждым движением юзера что глупо либо рисковать что следующий асинхронных вызов может начаться до того как закончится подвисший на инете или заблокировавший транзакцией БД, первый.
Есть $.Deffered() и очередность запросов, это не сложно. Есть callback();
Все это можно отследить
Мой еще проще - не давать пользователю на ответственных страницах вообще ничего таскать с риском промахнутся мышкой и т.п. Что бы там не впаривали насчет юзабельности умники с консалтерских контор - не они будут отвечать за неконсистентность данных в БД.
Изменять порядок как-то надо???
Цитата:
минимум 1 запрос после КАЖДОГО аякс апдейта. А то и не один. Например мне надо сделать какие то проверки. Вместо одним махом эту проверку сделать перед апдейтом надо каждый раз ее делать по запросу аякса.
Это я имел ввиду порядок вывода на странице. А потом процедуры MySQL уже ни как???
Цитата:
Переписыванием обратно с аякса? Или увольнением разработчика
Зачем все запоминается. Да и потом реализовать принцип Ctrl+Z я не думаю, что проблематично
Цитата:
еще как фатально когда большая сложная база - восстановить порядок иногда можно только многочасовым копанием руками в базе.
С чего бы это так? Если я что не то исправил(допустим не тот товар), я его исправлю обратно так же.
А вот если "восстановить порядок иногда можно только многочасовым копанием руками в базе"
Это ошибки самой программы и разработчика. Все что делается через админку, должно и восстанавливаться через нее
Отслеживаем изменения через js? Который глючит и т.д.
Ну это эж вы его хотите юзать
Вот расскажите как мне переместить товар(не важно что) с 15 позиции на 150 и другой с 90 на 2.
Я предлагаю юзать js. Вы?
Алгоритм пожалуйста, хотя бы в нескольких словах.
Мой прост как 2 копейки. После каждого UPDATE ajax-запрос, 1 запрос к БД и как бы все.
Цитата:
Могу предложить более частую ситуацию. Правил я правил -смотрю направил не туда. Думал нажму Cancel (уйду со страницы или перерефрешу) и все дела - а фиг там юзабельный аякс уже поменял мне все в базе и уже слышны матюки менеджера по продажам
А типа "Вы действительно хотите сохранить изменения/удалить ?" уже как бы все ни как???
И потом эта проблемма решается после первого подобного случая, что надо думать прежде чем делать(хотя в принципе кроме удаления все остальное не серьезно(не фатально))
Вообще не перегружаем пока не сделаны окончательно все изменения. Что значит получилось не получилось. Не получилось это баг и надо править код.
Отслеживаем изменения через js? Который глючит и т.д.
caballero пишет:
Устанет несколько раз аякс дергать и ждать пока отработает. А прорисовать надо всегда один раз когда вы уже определитесь с изменениями и решите что уже все - запоминаем.
Правил, я правил и тут свет выключился, браузер завис, инет отключили, браузер дурак закрыл. И все давай снова
Я уж молчу про перетаскивание (сортировку) товаров на странице.
аякс тут при чем?
UI-sortable например??? Сохранить новую позицию снова всю страницу перегружаем???
Хотя фактически уже все прорисовано??? Нужно только получилось или нет
caballero пишет:
Не настолько существенно. Надеюсь не станете утверждать что если страница 100 строк грузится секунду то обновление строки аяксом будет 10 милисекунд?
Если медленный инет или перегружен сервер то как раз удобнее засейвить одним махом всю страницу со всеми изменениями чем за каждым телодвижением смотреть на крутилку пока аякс отрабатывает.
А я не хочу(да и редко так бывает) всем махом, сначала тут скрыл, потом эту поднял, потом еще поднял, потом еще скрыл. Устанет он ее прорисовывать.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 1232
