| Внимание! В связи с устареванием топика эта страница была взята из кэша.
|
 atrius
Зарегистрирован: 24.06.03
Сообщения: 85
|
 Добавлено: 07/04/04 в 13:16
|
|
Совсем я глупый стал или старый 
Есть таблица типа field1, field2, field3
field1 - integer, autoincrement. Остальные - текстовые поля.
Добавляю в базу так: Insert into table values (0,'v1','v2');
Поле field1 замечательно инкременируется само и все хорошо. Но когда делаем Delete * from table, а потом опять Insert новых данных, то происходит забавная вещь: поле field1 начинает нумерацию не с 1, а с последнего номера, который был до выполнения Delete. Как бы сделать так, чтобы нумерация начиналась с начала?
Спасибо за внимание.
|
|
K началу
|
|
| |
Core
Зарегистрирован: 07.09.03
Сообщения: 808
|
|
Добавлено: 07/04/04 в 13:33
|
|
| atrius писал: | Совсем я глупый стал или старый
Есть таблица типа field1, field2, field3
field1 - integer, autoincrement. Остальные - текстовые поля.
Добавляю в базу так: Insert into table values (0,'v1','v2');
Поле field1 замечательно инкременируется само и все хорошо. Но когда делаем Delete * from table, а потом опять Insert новых данных, то происходит забавная вещь: поле field1 начинает нумерацию не с 1, а с последнего номера, который был до выполнения Delete. Как бы сделать так, чтобы нумерация начиналась с начала?
Спасибо за внимание. |
А никак... :-) А зачем тебе? какая разница? Насильно передавай ему 1,2,3 и т.д.
|
|
K началу
|
|
| |
atrius
Зарегистрирован: 24.06.03
Сообщения: 85
|
|
Добавлено: 07/04/04 в 13:44
|
|
На самом деле нумерация не так важна, просто за рамки integer выйдет скоро  Вот я и подумал, может есть какое-нибудь красивое решение. Как-то не хочется делать Drop | Create table
|
|
K началу
|
|
| |
Core
Зарегистрирован: 07.09.03
Сообщения: 808
|
|
Добавлено: 07/04/04 в 14:07
|
|
| atrius писал: | На самом деле нумерация не так важна, просто за рамки integer выйдет скоро Вот я и подумал, может есть какое-нибудь красивое решение. Как-то не хочется делать Drop | Create table
|
Поставь тип поля не int а big int и забудь ...
|
|
K началу
|
|
| |
WEBoy
Зарегистрирован: 10.04.03
Сообщения: 79
|
|
Добавлено: 07/04/04 в 14:12
|
|
TRUNCATE TABLE table_name
|
|
K началу
|
|
| |
Core
Зарегистрирован: 07.09.03
Сообщения: 808
|
|
Добавлено: 07/04/04 в 14:14
|
|
| WEBoy писал: | | TRUNCATE TABLE table_name |
Молодца! :-)
|
|
K началу
|
|
| |
Jark
Зарегистрирован: 05.01.04
Сообщения: 92
|
|
Добавлено: 07/04/04 в 16:49
|
|
Вот это должно сработать:
| Код: |
ALTER TABLE `table_name` AUTO_INCREMENT = 1
|
Хотя после DELETE * и так должно всё ОК быть...
|
|
K началу
|
|
| |
fly2k
Зарегистрирован: 17.03.03
Сообщения: 45
|
|
Добавлено: 07/04/04 в 17:20
|
|
| atrius писал: | Совсем я глупый стал или старый
|
Скорее молодой, раз таким вещам удивляешься
Все по уму именно так и должно быть. Сам задумайся - для чего нужны автоинкременты? Как правило для primary key, то есть чтобы на запись можно было ссылаться (скажем из другой таблички) по этому _уникальному_ номеру... Ну а дальше есть два варианта:
1) Если DB взрослая и позволяет работать с тригерами, то как правило там вместо автоинкремента используются или тригеры или последовательности. В этом случае ты можешь сам написать тригер, который и будет рулить этими уникальными ключами как тебе надо, при этом поддерживая ссылочную целостность данных (удаляю или меняя автоматом данные в других таблицах)
2) Если база игрушечная(Mysql) то остается только надеятся что все будет целым и правильным А представь если у тебя была запись с примари кей 5, ты ее удалил, и новая запись тоже получит номер 5, правильно ли будет что на нее будут ссылаться те, которые раньше ссылались на предыдущую?
Так что все прально!
|
|
K началу
|
|
| |
sexvendor
Зарегистрирован: 07.10.03
Сообщения: 66
|
|
Добавлено: 08/04/04 в 06:01
|
|
| fly2k писал: | Скорее молодой, раз таким вещам удивляешься
Все по уму именно так и должно быть. Сам задумайся - для чего нужны автоинкременты? Как правило для primary key, то есть чтобы на запись можно было ссылаться (скажем из другой таблички) по этому _уникальному_ номеру... Ну а дальше есть два варианта:
1) Если DB взрослая и позволяет работать с тригерами, то как правило там вместо автоинкремента используются или тригеры или последовательности. В этом случае ты можешь сам написать тригер, который и будет рулить этими уникальными ключами как тебе надо, при этом поддерживая ссылочную целостность данных (удаляю или меняя автоматом данные в других таблицах)
2) Если база игрушечная(Mysql) то остается только надеятся что все будет целым и правильным А представь если у тебя была запись с примари кей 5, ты ее удалил, и новая запись тоже получит номер 5, правильно ли будет что на нее будут ссылаться те, которые раньше ссылались на предыдущую?
Так что все прально! |
По первому пункту не очень понял, причём тут замена автоинкремента тригером. Ссылочной целосностью рулят, как правило, FOREIGN KEYS,
и в MySQL они есть для таблиц типа InnoDB, причем с вариантами поведений при UPDATE и DELETE (почти тригеры). Тригеры позволяют не только следить за целостностью данных, а так же выполнять хуеву тучу всяких действий. Конечно этих вкусностей, таких как тригеры, условия на значения полей, хранимые процедуры, которые есть в большенстве бд Enterprise класса, MySQL'ю ой как не хватает.
Я вообще после 3 лет програмирования под MSSQL вообще зачастую чуствую себя беспомощным из-за отсутствия этих инструментов. Можно конечно реализовать тоже самое с помощью скриптов, но по хорошему многие вещи должны делаться на уровне базы данных.
|
|
K началу
|
|
| |
Quantum[Tau]
Зарегистрирован: 15.03.04
Сообщения: 618
|
|
Добавлено: 08/04/04 в 16:58
|
|
MySQL не предназначен для замены взрослых реляционных баз данных уровня предприятия и никогда так не позиционировался. "Если бы у бабушки был х#й она была бы дедушкой".
В своей нише он лучший. Если жизнь не мила без триггеров, хранимых процедур и прочих полезных примочек, а денег на Oracle или другие серьезные СУБД нет, то юзайте фришный стабильный PostgreSQL.
|
|
K началу
|
|
| |
Jark
Зарегистрирован: 05.01.04
Сообщения: 92
|
|
Добавлено: 08/04/04 в 22:59
|
|
| Цитата: |
...то юзайте фришный стабильный PostgreSQL
|
и узнайте что происходит с триггерами и прочими "прелесями" на большом числе запросов 
|
|
K началу
|
|
| |
Quantum[Tau]
Зарегистрирован: 15.03.04
Сообщения: 618
|
|
Добавлено: 08/04/04 в 23:28
|
|
| Jark писал: | | и узнайте что происходит с триггерами и прочими "прелесями" на большом числе запросов |
А что с ними происходит? Аппетиты к памяти и остальному железу растут или целостность данных нарушается? О втором никогда не слышал (postgreSQL).
|
|
K началу
|
|
| |
Текстовая реклама в форме ответа
Заголовок и до четырех строчек текста
Длина текста до 350 символов
Купить рекламу в этом месте! |
Внимание! В связи с устареванием топика эта страница была взята из кэша.
|
