|
Страници по тази тема: 1 | 2 | >> (покажи всички)
Тема
|
lipsva6ti ID-ta
|
|
Автор | jijo (Нерегистриран) |
Публикувано | 21.02.07 12:01 |
|
kak da namerq lipsva6tite stojnosti v kolona ID (auto increment, not null) ?
| |
Тема
|
липсващи?
[re: jijo]
|
|
Автор |
Dakota (erotoman) |
Публикувано | 21.02.07 14:42 |
|
Не знам какво имаш предвид под липсващи, но ако приемем, че общият брой на всички ID-та е този на стойностите за дадения тип, то липсващите са всички останали освен съществуващите.
Т.е. ако имаш съществуващи стойности {1, 2 ,3}, то липсващите за беззнаковия тип tinyint са всички от интервала [4, 127]; за тип smallint - [4, 32767], и т.н.
Everything louder than everything else...
| |
Тема
|
Re: липсващи?
[re: Dakota]
|
|
Автор | motokar4e (Нерегистриран) |
Публикувано | 21.02.07 15:16 |
|
lipsva6ti imah predvid za tezi kojto sa iztriti po nqkakva pri4ina, kolonata e autoincrement
{1,2,3,4,6,7,8,9,11,12,13}
lipsva6tite 5 i 10
| |
Тема
|
Re: липсващи?
[re: motokar4e]
|
|
Автор | TA (Нерегистриран) |
Публикувано | 21.02.07 17:28 |
|
Моята идея е следната:
Създаваш нова таблица, която съдържа една единствена колона ID и я попълваш със стойности от 1 до последното заето ID от твоята таблица. После правиш вразка между двете таблици (LEFT JOIN например) и от полученото query виждаш за кои записи няма съответствие в твоята таблица - това са пропуснатите ID-та.
Може би има и по-елегантен начин, ама и това върши работа.
| |
|
Първо, какво ти гарантира, че е имало такива записи? Може просто съответната транзакция да не е минала. Второ, ако приемем, че на база дупки можеш да разчиташ, че нещо е било изтрито, какво ти гарантира, че не е имало и записи 14, 15 и 16?
За какво ти е изобщо това, ако не е тайна?
Everything louder than everything else...
| |
|
не е тайна, просто искам да знам кои записи са били изтрити.
Да липсващите записи са били изтрити и на мен ми трябва да знам кой. Понеже базата е с много записа и не е удобно да ги гледам всичките, питам за SQL решение на проблема
| |
|
Добре де, а защо ти трябва да го знаеш?
Иначе решението на ТА би ти свършило работа.
Everything louder than everything else...
| |
Тема
|
Re: lipsva6ti ID-ta
[re: jijo]
|
|
Автор | Lubo (Нерегистриран) |
Публикувано | 23.02.07 22:42 |
|
select after=bottom.id
, before=top.id
from <your table> top, <your table> bottom
where bottom.id < top.id
group by bottom.id
having min(top.id) - bottom.id >1;
kolonite "after" i "before" ti davat na4aloto i kraia na lipswashtite intervali
| |
Тема
|
Re: Хитро
[re: Lubo]
|
|
Автор |
salle (един такъв) |
Публикувано | 24.02.07 22:48 |
|
Доста хитро решение
Има само един недостатък, но то е заради един от принципните проблем и в случая а именно, че когато има изтрити редове от края на поредицата не е толкова лесно да се "открият".
Редактирано от salle на 24.02.07 23:03.
| |
|
Имаш два много сериозни проблема едивият от които обезсмисял цялото начинание
1) Трябва да правиш допълнителна проверка за последния ред. Ако се вгледаме в твоя пример:
{1,2,3,4,6,7,8,9,11,12,13}
какво ни гарантира, че не е имало редове с id > 13 ?
Т.е. трябва да провериш каква е максимално използваната стойност а това не е толкова лесно. (Има различни начини, но няма да се спирам на тях)
2) Липсващите стойности не означават непременно изтрити редове. Няма начин да докажеш, че редовете с 5 и 10 от твоя пример въобще са съществували в таблицата.
Примери:
А. След реда с id=4 e изпълнена заявка INSERT INTO tbl (id) VALUES(6); Съответно брояча е преместен и следващата автоматично генерирана стойност е 7
Б. След реда с id=4 е броячът е променен "ръчно" на 6 с ALTER TABLE tbl AUTO_INCREMENT = 6; Съответно следващият INSERT ще генерира 6
В. Ако таблицата поддържа транзакции е напълно възможно редове 5 и 10 да са били "запазени" от отказани транзакции (ROLLBACK)
И в трите случая става въпрос за редове които никога не са съществували в таблицата.
Та въпросът защо ти е изобщо да си губиш времето с това е съвсем основателен.
| |
|
Страници по тази тема: 1 | 2 | >> (покажи всички)
|
|
|