Возврат первичного ключа

[tokloo]

после очистки таблицы первичный ключ исчесляется с прежнего места, как вернуть его на 1?

[mrgrudge]

если есть phpMyadmin, то заходишь в таблицу-> операции-> там есть поле AUTO_INCREMENT в котором лежит последний записаный id, как осуществить это с помощью sql запроса думаю гугл ответит

[Serge_Bliznykov]

Сообщение от tokloo

после очистки таблицы первичный ключ исчесляется с прежнего места, как вернуть его на 1?

tokloo, ЗАЧЕМ ???!!

Единственное требование к первичному ключу - это его УНИКАЛЬНОСТЬ!
Всё! Нельзя к нему привязывать какие-то свои аттрибуты!! (ну, например, номер документа и т.п.) НЕЛЬЗЯ!
Заводите отдельное поле и делайте с ним что хотите. Хоть обнуляйте, хоть наращивайте, хоть что.. И оставьте в покое первичный ключ.


сорри, если был излишне эмоционален...

[tokloo]

спс, а то я не знал про переменую эту, сейчас уже нашел как ее изменять

Serge_Bliznykov, ты меня не так понял, я удалил несколько строк в конце таблицы, во и хочу изменить AUTO_INCREMENT, чтобы он мне следующие записи не 40 какие-нибуть ставил, а следующим номером по порядку от наибольшего в таблице

сейчас попробую проверку в скрипт записи в БД добавить и при надобности пусть правит AUTO_INCREMENT

[Serge_Bliznykov]

Serge_Bliznykov, ты меня не так понял, я удалил несколько строк в конце таблицы, во и хочу изменить AUTO_INCREMENT, чтобы он мне следующие записи не 40 какие-нибуть ставил, а следующим номером по порядку от наибольшего в таблице

я Вас прекрасно понял.
А вот Вы меня - нет!

моя основная мысль - это то, что каждая запись в таблице должна иметь свой уникальный (первичный) ключ.
Пусть это будут такие, например, ключи: 1, 2, 54, 87, 34, 32, 2000, 7, 55, 56....
И всё нормально.
Ещё раз. Они должны быть уникальны. Точка.
Поймите, что большего от ключа ничего и не требуется.

[TranceSmile]

Да только заводить ещё одно поле для порядкового номера излишество

[Serge_Bliznykov]

Да только заводить ещё одно поле для порядкового номера излишество

глупости...
не надо смешивать мух и котлеты!

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

Нужны Вам ещё какие-то естественные ключи - номер документа, инн организации, порядковый номер заявки - да что угодно - создавайте нужные поля и пользуйтесь ими как хотите. Первичный ключ - не трогайте!

И избежите кучи ненужных проблем, косяков, глюков, переделок структуры БД, криков, как это, два одинаковых номера договора НЕ МОЖЕТ БЫТЬ, что же Вы сразу не сказали и т.д. и т.п...
Уж поверьте моему (и не только моему) опыту...


В качестве дополнительной информации могу порекомендовать статью Анатолия Тенцера "Естественные ключи против искуственных ключей"

[TranceSmile]

Сообщение от Serge_Bliznykov

глупости...
не надо смешивать мух и котлеты!

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

Нужны Вам ещё какие-то естественные ключи - номер документа, инн организации, порядковый номер заявки - да что угодно - создавайте нужные поля и пользуйтесь ими как хотите. Первичный ключ - не трогайте!

И избежите кучи ненужных проблем, косяков, глюков, переделок структуры БД, криков, как это, два одинаковых номера договора НЕ МОЖЕТ БЫТЬ, что же Вы сразу не сказали и т.д. и т.п...
Уж поверьте моему (и не только моему) опыту...


В качестве дополнительной информации могу порекомендовать статью Анатолия Тенцера "Естественные ключи против искуственных ключей"

А можно ли узнать примеры глюков или косяков???

[Serge_Bliznykov]

А можно ли узнать примеры глюков или косяков???

ну, посмотрите, например, такую тему
ID в таблице
как Вы думаете, откуда возник такой вопрос у автора темы?

из собственной реальной практики - сейчас вряд ли вспомню ВСЕ замеченные косяки/проблемы...
ну, так, навскидку. Есть регистрация и выдача неких технических условий.
В номере техусловия присуствует порядковый номер (там сложный длинный код, в котором закодировно предприятие, подразделение и порядковый номер... Этот порядковый номер был единый в рамках предприятия (логично же, да - брался по auto_increment (в Oracle использовался sequence)) и всё было хорошо. пока в один прекрасный момент не было объявлено, что по каждому подразделению нумерация должна вестись ОТДЕЛЬНО. В результате изменение структур БД (отдельная таблица, где по каждому подразделению ведётся своя нумерация), изменение ряда процедур и функций и т.д.

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

впрочем, учитывать это или не учитывать это в своей работе - дело ваше.
Как говаривала одна знакомая: "Пока не попаду под трамвай - не поверю, что это больно"...

[tokloo]

Сообщение от Serge_Bliznykov

В качестве дополнительной информации могу порекомендовать статью Анатолия Тенцера "Естественные ключи против искуственных ключей"

хм... интересная статья

В общем-то, выводы очевидны – введение СК позволяет получить лучше управляемую, более компактную и быстродействующую БД. Разумеется, это не панацея. В некоторых случаях (например, таблица на которую нет REFERENCES и в которую осуществляется интенсивная вставка данных и т.п.) более верно использовать ЕК...