какими методами пользоваться?

Не очень понимаю. что такое порядок сортировки для конкретного товара а не для конкретного поиска по каталогу и тем более зачем это запоминать в БД. В любом случае если сортировка в пределах страницы - на сервер ходитть незачем, а если вывод многостраничный - вам все равно придется перерисовать полстраницы. Уж лучше тогда взять готовый jqGrid где уже все реализовано. Упаритесь писать руками - убедитесь сами когда перейдете от слов к делу.


В ЛЮБОМ варианте делается апдейт НУЖНЫХ записей а не всей БД.



именно - источник любое вменяемое руководство по проектировани БД. При чем неважно какой БД. Никто в своем уме на напишет что процедура выполняется быстрее простого запроса (даже с учетом прекомпиляции)


Это все разные вещи для разных задач и помочь в данном случае не могут никак.


Можно но опять все сведется к блокировнию юзера пока вся цепочка не отработает. Про надежность всей этой цепочки калбаков я уже молчу.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Странно, а Петр Зайцев и Ко в книге Оптимизация MySQL почему-то пишет по другому.
(там пример есть INSERT 1000000 строк разница процедура 101 vs Клиентское приложение 279 vs
Клиентское приложение с соединением через MySQL Proxy 309 в секундах)
Правда он тут же пишет что выигрыш дается на простых процедурах. А на сложные мы и не замахиваемя . Почти в 3 раза, ерунда какая.

А на счет

Есть группа продукты. В ней находятся товары 100шт. Нужно одновременно(т.к страницу не перегружаем пока все не поправили) Вот я переместил (хотя я даже не понимаю каков интерфейс данного чуда) один продукт с 96 позиции на 15 , и другой с 50 на 85.
Переместил(отметил новую позицию). Нажал сохранить. Вот теперь подскажите пожалуйста каков запрос MySQL.

(Отредактировано автором: 11 Декабря, 2011 - 20:00:21)

на запрос в 1000000 записей тоже. Впрочем вы потеряли нить разговора - речь шла о дополнительном вызове общего проверочного запроса каждый раз при апдейте аяксом.


это на одной странице? напомните кто там говорил о юзабельности.


Откуда я знаю что вы подразумеваете позицией и зачем ее перемещать. Нужен какой то критерий для перемещения. Все мне известные для сортировки (по названию, цене, популярности, рейтингу и т.д.) в перемещении не нуждаются а только в сортировке при выборке.
Если даже предположить что есть некое число с которым вы хотите связать нечто именуемое позицией то навскидку даже не представляю это одним запросом. Даже если передать массив товаров с их позиций в процедуру все равно это будет не один апдейт хотя в данном случае это будет чуть быстрее чем несколько запросов, хотя и не настолько существенно чтобы возится с медленными процедупами в Mysql

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

А у нас 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 все медленное и триггера и процедуры - просто там нет нормального оптимизатра - mysql не для этого предназначен
в промышленных серверах - да
но там свои особенности в некоторых таких как DB2 на каждую процедуру создается отдельная транзакция со своими вытекающими отсюда особенностями. В любом случае однократный вызов простого запроса быстрее этого же запроса внутри процедуры.


Сделать можно массой способов. Например запоминать в массиве последовательность перемещений.
Хотя для абстрактного примера имеющего мало общего с практической реальностью и решений нормальных не бывает.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Это цитата из книги. Человека, который разрабатывал(-ет) MySQL

Идея выводить товары, так как я хочу не по цене, названию ... А просто ткнул хочу первым, хочу вторым. Это абстрактная идея?

Ну и где тут сказано что выполнение процедуры с запросом быстрее того же запроса выполненого напрямую.


Разумеется, к и все что руководствуется принципом "я хочу" вместо "имеет смысл и необходимость".
При чем это хотение совершенно не согласовывается с надежностью системмы.
Переместил товар отправил апрос на сервер - инет глюкнул. В базе одна сортировка на странице другая. пошел перемещать дальже - в базу пошли цже кривые данные и т.д.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Пример выше Вы я так понял не читали??? Про миллион вставок???
Ссылку я привел про целостность данных при процедуре.

Это Вы заказчику объяснить попытаетесь?

Вы вообще представляете как это все работает??? Логику и внешний вид??? На каком этапе может произойти сбой если система построена т.о
Я нажал на клавишу мыши захватил строку. Начал перемещать.(для особо кривых рук, можно указать куда (по направлению горизонт/вертикаль) и родительский элемент )
Пока я не отпустил мышку ничего никуда не отправляется.
Я отпустил(если на туже позицию тоже ничего), а вот если позиция поменялась тогда ajax.
Где callback-функция содержит проверку, если ошибка, то вернется все на место.
Страница не перерисовывается, она готова полностью к дальнейшей работе.
Даже если на этапе отправки запроса произошел сбой. Единственный сбой, который сложно предусмотреть, это разрыв соединения по timeout. Тут нужно просто подумать чуток. Как определять тип ошибки т.е ошибка соединения(и тогда одно) или все-таки ошибка в приложении. И дествовать соответственно.

Пример некорректный
при миллионе вставок очевидно что если программист не новичок, то запрос
будет прекомпилирован(prepared) и по любому будет работать быстрее. По любому - миллион вызовов процедур и вызовов запроса внутри будет медленне просто миллиона запросов.



Ну и как ты определишь когда произошла ошибка до вставки в БД или после. У тебя инет сбойнул - HTTP протокол это тебе не транзакционная БД. Или скрипт завис потому что что ты своими манипуляциями надул память и вызвался сборщик мусора который в большинстве яваскриптовых движков - тупой как сибирский валенок. Или просто по таймауту отвалился от сервера.

(Отредактировано автором: 11 Декабря, 2011 - 23:35:20)

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Черт с ними с процедурами. Пускай каждый решает сам, мне они нравятся больше.


Во-первых это единственная проблема. На вскидку прямо так если:
Итак по умолчанию timeout=60 сек(писали выше я если честно не знаю)
Я если правильно понимаю сработает .error() запроса==> принудительно обновляем страницу. Js это умеет.
Иначе complete()--->по рез-ту запроса опять же флаг 1/0.
В обоих случаях сначала выводим сообщение типа "произошла ошибка". Да и можно перегрузить страницу, это тоже не критично.
Ну как сработает нормально?
На счет утечек памяти. Я уже писал. Что в принципе на это стоит обращать внимание, но с другой стороны допустим jQuery постоянно развивается. Они сами же его оптимизируют. Если есть желание можно найти тесты и т.д. Баги которые обнаруживаются устраняются. Я ведь не призываю пользоваться beta версией. Использовать стабильный релиз.
Единственно по работе, я столкнулся, что при отладке при большом количестве вставок DOM и включенном FierBug-е да появляются тормоза. При выключенном все работает как секунды.

Нравится может девушка а не размазываение бизнес логики между кодом сервера и процедупами.


Это единсивенный способ гарантировать соответствие БД содержимому страницы. Можно даже аяксом перегружать но это сложнее и никакого преимущества пос корости даже теретического.

В принципе можно такой алгоритм - если возвращается нормальный код то оставляем как есть, если код ошибки заведемо определенный с скрвера - возвразаем обратно. Если код непонятно какой перечитываем страницу.
Но надежность все равно низкая и все равно надо блокировать пользователя чтобы не начал переставлять товары пока не засейвился предыдущий удачно.
Как ни крути для таких страниц аякс - не лучшее решение. Тем более увидит сие гениальное творение только админ сайта.

(Отредактировано автором: 12 Декабря, 2011 - 00:01:06)

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Хорошо специально для Вас


Следовательно в примере с 1000000 строк сам запрос не кэшируется, т.к процедура вызывалась один раз или может я не правильно понимаю кэш планов?
т.е быстрее он выполнился ...

Это справедливо для простых запросов. Но сложную логику можно и на PHP сделать


Я Вам разве не про него писал??? Т.е фактически мы получаем следующее. Если все нормально сработал ajax пользователь спокоен все хорошо.
Если приложение написано без ошибок(в PHP и запросах), то следовательно 99% запросов будут летать..
А ошибки на то они и ошибки, чтобы их исправлять
Ошибки соединения мы тоже обошли. Все счастливы и довольны. Осталось только не лениться и написать 10-20 строчек кода и все будет хорошо.

(Отредактировано автором: 12 Декабря, 2011 - 00:22:15)

Точно так же он закеширует если запрос будет прекомпилирован. И не забывайте про накладные расходы по самому вызову процедуры. Вызов миллион процедур не самое удачное ее применение. Вот если в процедуре вызвать миллион запросов это другое дело.



разумеется всю логику нужно делать в одном месте - это упрощает понимание кода и отладку (отладка хранимок - гемор еще тот). Но иногда процедура очень полезна - например надо пройтись курсором по записям и проделать там какие нибудь изменения. Или собрать данные в набор когда одним запросом накрутить не получится. Лет 30 назад когда не было высокоуровневых языков и сред разработки а приложения строились по двухзвенной схеме, тогда бизнес логика писалась в основном в процедурах.
Но в Mysql процедуры не слишком эфективны по скорости, не говоря уже про нагрузку на сервер.

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore

Что ж Вы не верите то а...

Равносильно но сравнивать не корректно.

Не понимаете разницу между вызовом одной процедуры с миллионом запросов и вызовом миллиона процедур с одним запросом?
(Добавление)
Однократный вызов процедуры тоже будет медленнее однократного вызова прекомпилированного (prepared) запроса а в mysql скорее всего даже обычного.
Теория - одно а практика другое. На практике все сервера БД не соответствуют реляционной алгебре. Ну и толк цитировать книги отцов-основателей.

Представте себе строку в программе и ту же строку в функции которую надо вызвать. Что будет быстрее?

(Отредактировано автором: 12 Декабря, 2011 - 01:21:43)

-----
Бесплатная система складского учета с открытым кодом https://zippy[dot]com[dot]ua/zstore