Inkrementacja indexu w ms SQL

Witam
Chce, żeby SQL server sam inkrementował mi indexy w tabeli, więc przestawiłem w opcjach pola index w SQL server menegement opcję Identitty Specification na YES (Identity Increment 1, Identity Seed 1).

No i po tych zmianach indeksy są inkrementowane, ale pojawia się problem, ponieważ w przypadku skasowania jakiś danych w tabeli indeks się nie zmniejsza.

Załóżmy, że mam 2 rzędy danych w tabeli. W przypadku, gdy skasuje rząd o indeksie 2, a następnie dodam nowy rząd danych to zostanie mu przypisany indeks 3 ( a chcę żeby miał 2 ).

Czy da się ten problem rozwiązać po stronie SQL servera ?

Z góry dzięki za pomoc

Opieranie sie na sqlowej inkrementacji w jakiejkolwiej logice biznesowej oznacza zwykle blad w projektowaniu badz bledne zalozenia. Po co Ci taka funkcjonalnosc?

Czyli jak mam to rozwiązać - myślałem, że ustawia się w opcji i to ma działać.

Nie odpowiedziales na pytanie. To rzadko kiedy jest rozwiazanie problemu. I nie, mssql nie ma takiej mozliwosci, zwykle nie jest potrzebna. Inkrementacja tutaj gwarantuje tylko unikalnosc wartosci. Zalepianie dziur byloby malo wydajne i niepotrzebne.

Chciałem, żeby w mojej bazie ID było takim identyfikatorem- czyli np. dana osoba, podaje swoje ID do znalezienia swoich danych.

A w czym Ci przeszkadzają luki?

Dokladnie, id moze miec milion dziur, ale ciagle bedzie identyfikatorem (czyt. unikalne).

jezeli chcesz miec ciaglosc to musisz kontrolowac operacje delete

przywrocenie identity na kolejna poprawna wartosc (wynikajaca z zalozonego przez Ciebie ciagu) dokonuje sie przez instrukcje reseed

Poszytaj o tym

Ale to jest operacja bez sensu. Jeśli danych będzie np. milion rekordów to usunięcie pierwszego spowoduje kaskadowe zmiany w milionie rekordów (+ w tabelach gdzie masz klucz obcy też). Poważnie chcesz żeby tak było? o_O To może skutkować modyfikacją niemalże całej bazy, przebudowaniem wszystkich indeksów itd.
Korzyści żadnej, a wydajność bazy znacznie spadnie.

Jeśli chcesz coś szybszego to proponuje stworzyć cos takiego
Tabela A( twoja tabela glowna )
Kolumny ID(autoinkrementowane) oraz np. kolumne Kolejne_ID

TABELA B
ID_usuniete

Teraz 2 triggery.
Jeden BEFORE DELETE ( kopiujesz Kolejne_ID do tabeli B )
oraz
AFTER INSERT ( updateujesz wiersz i pobierasz z tabeli B "skasowane id" lub jesli takowego nie ma robisz numer kolejny poprzez COUNT(*) )

A ja sie tylko zastanawiam po co... Pare duzych i malych baz widzialem i obslugiwalem i jakos nigdy taki bajer nie byl potrzebny.

@gosc ale autor twierdzi że chce przesunąć wszystkie ID w tył po usuwaniu, a nie wstawiać na "puste" miejsca ;)

To sie w ogóle kłóci z zasadami tworzenie Bazy Danych. Przecież jednym z warunków na Klucz Główny jest to że ma być niezmienny w czasie!

Proponuję przy wyciąganiu danych zastosować funkcję RANK() np.:

select id, RANK() OVER (ORDER BY id) as ranking from Foo

dzięki temu uzyskasz to, co chcesz (zakładam, że potrzebne Ci coś w rodzaju "liczby porządkowej") i nie zaburzysz spójności bazy

przypomne tylko ze to polecenie jest od 2005 dopiero.

Ogolnie to nie spotkalem sie nigdy z takim zapotrzebowaniem na zmiane id'kow.
Przeciez Id nie prezentujesz uzytkownikowi tylko inne dane (jesli beda dziury to trudno - trzeba z tym zyc).

Projektujac rozwiazania bazodanowe nalezy pamietac o jej wydajnosci - to powinno byc glowne kryterium