> Zeqfreed ©   (29.06.08 18:47) [19]
> > ProgRAMmer Dimonych ©   (29.06.08 18:43) [18]
> Что мешает сделать поле pos точно так же автоматически
> инкрементируемым? :)

Э-э-э... Хм... Ну... Уже второй раз за день туплю.

Спасибо.

> ProgRAMmer Dimonych ©   (29.06.08 18:50) [20]

Хм. Оказалось, что так нельзя сделать. Видимо, придется вручную рассчитывать значение. Но в принципе при вставке обычно уже известно общее число записей в таблице. А вот в постгресе, кажется, такое можно.

> Zeqfreed ©   (29.06.08 19:22) [21]

Да, насчёт того, что так не получится тоже увидел. Обидно :( Получается, вручную - это два запроса.

P.S. Хотя, нет. Пока писал, понял, что можно проще. Вот так ведь должно сработать?




Вряд ли при одновременном доступе всё пройдёт гладко, но админов не так много, чтобы одновременно ухитриться обратиться к БД. :)

> ProgRAMmer Dimonych ©   (29.06.08 21:26) [22]

Поправочка... :)

Да, с подзапросом в принципе нормальный вариант.

> Zeqfreed ©   (29.06.08 22:18) [24]
> Да, с подзапросом в принципе нормальный вариант.

Вот, ёлки-пионерки... :( использовать в подзапросе поле, которое будет заполняться INSERT'ом не даёт.

Как в MySQLi (PHP) получить результат запроса


?

> ProgRAMmer Dimonych ©   (29.06.08 22:58) [25]

P.S. В смысле, как получить результат скалярного запроса?

ProgRAMmer Dimonych ©   (29.06.08 15:01)
Пусть есть три новости, у которых значения этого order-поля равны, скажем, 35, 36 и 37. Я хочу поставить 35-ую новость между 36-й и 37-й. Если не туплю, то придётся тупо обменивать значения order-поля (в дроби уходить не хочется, они тоже имеют предел прочности). Получается 3 запроса: 1) найти две записи, между которыми будем обменивать значения order-полей; 2) обновить первую запись; 3) обновить вторую запись.

А нельзя одним запросом?
UPDATE TABLICA SET POS = POS + 1 WHERE POS >= 35
а потом инзертить 35ю новость.
Или MySQL не поддерживает тактх запросов?

> Prohodil Mimo ©   (30.06.08 00:10) [27]

Запросов много. Сдвинули все, которые мешают - это раз. Потом два апдейта - всё равно три. Ну, если сдвигать начинать с 37-й, то можно в два уложиться, но хорошо ли это: почти целую таблицу можно сдвигать для первых записей.

ProgRAMmer Dimonych ©   (30.06.08 0:13) [28]
Потом два апдейта
в каком месте? что потом апдейтить и почему два раза?

> ProgRAMmer Dimonych ©   (29.06.08 23:00) [26]

http://ru2.php.net/manual/en/mysqli-result.fetch-field-direct.php
http://ru2.php.net/manual/en/mysqli-result.fetch-field.php
Что-нибудь из этого? :)

> Prohodil Mimo ©   (30.06.08 00:17) [29]

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

> Zeqfreed ©   (30.06.08 00:25) [30]

Уже не знаю. {Здесь грустная и виноватая улыбка} :)

Появилась бредовая идейка... Если выдрать ассоциативный массив Fetch'ем, то, по логике, индекс будет совпадать с названием поля, так ведь? Но поскольку у меня табличка пока пуста, значение должно быть равно 0, а при попытке вывода оно просто не отображается. В общем, сейчас попробую. Последний вопрос временно снимается.

> Prohodil Mimo  (30.06.2008 0:10:27)  [27]

Если без ручного образования дырок, то три запроса.
Если с дырками, то возможно придется сделать кучу ненужной работы, например переименовать миллионы записей, вместо нескольких.

Автор привел очень плохой пример, взял три записи подряд, а ты рассмотри какая ерунда получится, если например вставить 5 между 7 и 8
Кроме того если на номер наложено ограничение уникальности, то данный метод вообще не позволит обновить и все равно непонятно зачем вторую то запись обновлять, что бы сделать 37 равным 37. А если уникальности нет, то после первого обновления будут две 35 записи и отличить их по номеру уже не получится.

Прежде чем советовать надо знать некоторые данные, имеется ли ИД и можно ли иметь одинаковые номера. Если нельзя то алгоритм будет в три запроса. И ни в коем случае не пытаться перенумеровывать миллионы записей, поскольку следующей жалобой будет жалоба на тормоз. Для указаного второго диапазона, надо 6 и 7 уменьшить на единицу, а 5 увеличить на единицу. Два запроса и минимум записей затронуто.

Прежде чем писать запросы надо голову поправить, надо что бы она была на ТЫ с реляционной и обычной логикой.

Anatoly Podgoretsky ©   (30.06.08 9:09) [32]
Это смотря какая логика. А если ещё и поиск дырок реализовывать, то лучше не браться. Надо делать так, чт бы дарок не появлялось. Лучше уж периодически причёсывать все записи.

Если я правильно понял, то это дело надо для админа и он не будет лопатить по сотне новых записей в секунду, что бы заметить тормоза, страница и то дольше открывается, чем пройдёт перенумерация.

Я привёл пример для вклинивания новой записи, для сдвига существующей, надо посылать как минимум два запроса, для смены номера у каждой записи из двух, меняемых местами.

В любом случае дело за автором, т.к. нам его схема неизвестна, а потому и советы такие разрозненные.

Автор пытается экономить на спичках.
Основная нагрузка на сайт - это всегда его просмотр, для базы - это запросы SELECT получаются.

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