Доброго времени суток всем, у меня токая ситуация. С помощью pdo я пытаю изменить id и строку(name) в базе данных но не получается, точней строка получается а id нет, можете сказать что тут не правильно PHP: $id = $_POST['id']; $category_name = $_POST['name']; $category_id = category_translate($category_name); $data = $pdo->prepare('UPDATE `categorys` SET `id` = :id, `name` = :name, `category_id` = :category_id WHERE `id` = :id'); $data->execute([ ':id' => $id, ':name' => $category_name, ':category_id' => $category_id ];
Для наглядности, что у тебя выходит: UPDATE `categorys` SET `id`=53 WHERE `id`=53 Думай, что ты сделал не так))
"Такая ситуация" через "о" написал, вот пхп и в отказ пошел) Если серьезно, то зачем менять значение ключевого поля?
Чтобы поменял местами категории. я знаю что вывод такой и еше знаю что дольжень быт таким Код (Text): UPDATE `categorys` SET `id`=53 WHERE `id`=25 но не знаю ка этого добиться.
прямо в самой базе наживую лучше не делать, и вообще гиблое это дело. Можно убрать у поля id автоинктемент и индекс и первичный ключ и внешние ключи , сделать изменение id и снова вернуть автоинкремент индекс первичный ключ и др. Ну если очень надо, то проще сделать дамп базы в sql файл и исправить в блокноте id , а потом заново импортировать таблицу из этого sql файла
Для начало я хочу сказать зачем мне это и как хочу чтобы в результате получилось. Я пишу админу для магазина и категории могут удалятся, изменятся или добавляться а также их места могут меняться (например первое будет четвертая) как в wp но без анимации. Я 100% не уверен что логику создаю правильно но я учусь и надеюсь что вы поможете мне. --- Добавлено --- В БД ручное меняется а с кодом не получается , автоинкремент убрал и заново поставил не получилось.
Вот именно такие вещи происходят когда лезут в практику без теории... Для отображения порядка категорий заведите отдельное поле. В итоге категорию можно даже не удалять, а просто присвоить этому полю null и не отображать. При желании её можно всегда вернуть, присвоив какой либо порядковый номер.
@Hovik , а как вы id собрались менять если у вас Код (Text): UPDATE `categorys` SET `id` = :id WHERE `id` = :id' Чтобы что то изменилось вам нужен :newid. Но это так, на будущее. Primary key обычно никогда не меняется. Он служит только для идентификации сущности в таблице, дополнительную смысловую нагрузку не верно на него накладывать
@Hovik, вот с какого перепугу оно new_id ? Каково назначение поля? Сортировка. Назови его order или хотя бы sort
Можно спокойно менять id в пределах ниже тек. автоинкрементального значения, только осторожно. Код бестолковый. Но ТС это и сам понимает: При смене id, естественно, нужно передавать и новый, и старый id, например: POST /categories/<старый_id> $_POST['id']: <новый_id> Естественно, не пытайтесь в какой-то момент времени дублировать id, а используйте для обмена третье, промежуточное, значение. Только учитывайте то, что я написал в первом предложении. Если нет незанятого значения в обозначенных пределах, но свободен 0, можно использовать в качестве промежуточного значения его, предварительно убедившись в наличии SQL_MODE = "NO_AUTO_VALUE_ON_ZERO". Если и 0 занят, тогда уже лезете за пределы, только не используйте значение, оч. близкое к пограничному автоинкрементальному. Оставьте на всякий случай небольшой запас. Ну а в общем Валик вам уже ответил. Если есть постоянная необходимость менять порядок, заведите спец. поле order. Первоначальное значение можно устанавливать триггером по id. Достаточно это поле сделать просто ключевым (НЕ юником), чтобы можно было обмениваться значениями без промежуточного. --- Добавлено --- P.S. Естественно, можно сделать и обмен значений всех полей (юники в расчет не беру) кроме самого id. Но тогда нужно где-то сохранить промежуточные значения.
P.P.S. Надеюсь, вы понимаете, что в нек. случаях смена id, т.е. отрыв старых значений id от значений всех прочих полей соотв. записей может быть весьма болезненным действием. Прежде всего проверьте, не светятся ли где-то id, например в адресах морды вроде /category/<тут_id>.
ID служит не для сортировки, а для уникального указания на запись. Если надо управлять порядком следования записей, заведи дополнительное поле специально для этого, например `sort_order`. Пусть он будет по умолчанию нулевой. Для сортировки записей с одинаковым значением sort_order пригодится составной индекс (sort_order, name) — обычно пользователи ожидают что записи будут отсортированы не по какому-то неведомому признаку, а в алфавитном поряке
Сортировать по id вполне норм. Вместо времени создания, которого может и не быть. Даже если есть одно поле со временем, в нем может отражаться время изменения, а именно по времени создания при этом можно сортировать, используя id. Но ТС пытается менять порядок, меняя id, что нарушает хронологию, разрывает связь конкретного id с прочим содержимым записи, поэтому см. «в общем».
@miketomlin, id - это идентификатор строки обеспечивающий её уникальность и точка. То что при определённых обстоятельствах id может по смыслу совпадать с чем-то иным (включая хронологию) это абсолютно ничего не значит. Не стоит опираться на подобного рода совпадения при создании архитектуры базы данных и написании кода.
@Valick, если так определить: тогда конечно: Но Хто сказал, что к id нельзя подвязывать «доп. соглашения»? --- Добавлено --- Т.е. при таком определении о какой-то сортировке с помощью id с ТСом вообще не о чем разговаривать, однако мы имеем то, что имеем.
Я понятия не имею, что ты подразумеваешь под словосочетанием «доп. соглашения», но скорее всего в данном контексте "нельзя" сказала третья нормальная форма. В таком случае это уже денормализация и это отдельный разговор требующий серьёзного обоснования.
@Valick, причем тут это?! Я про придание доп. смыслов значениям id, если ты еще не понял. --- Добавлено --- Например, какой-нибудь особый смысл нулевого идентификатора, соответствие порядка следования значений id хронологии создания записей и т.д.