Pracujemy nad aplikacją internetową, która nie jest jeszcze dostępna dla użytkowników. Mój szef zauważył, że nowo utworzone rekordy mają identyfikator ponad 10 000, mimo że w tabeli mamy tylko mniej niż 100 rekordów. Zakłada, że interfejs sieciowy z jakiegoś powodu tworzy ponad 100 razy więcej tymczasowych rekordów niż rzeczywiste (i usuwa je), i że może to doprowadzić nas do wyczerpania zasięgu w ciągu kilku miesięcy od wydania.
Nie sądzę, żeby miała rację co do przyczyny inflacji tożsamości (kolega, który może odpowiedzieć na to, jest na wakacjach, więc nie wiemy tego na pewno), ale załóżmy, że tak. Powiedziała, że nie chciałaby używać kolumny bigint i że chciałaby, abyśmy przestali automatycznie zwiększać kolumnę identyfikatora i napisali kod po stronie serwera, który wybiera pierwszą „nieużywaną” liczbę całkowitą i używa jej jako identyfikatora.
Jestem studentem informatyki z niewielkim praktycznym doświadczeniem, pełniąc rolę młodszego programisty. Ma wieloletnie doświadczenie w zarządzaniu wszystkimi bazami danych naszej organizacji i projektowaniu większości z nich. I pomyśleć , że jest niepoprawna w tym przypadku, że bigint Identyfikator ma się czego bać i że naśladując funkcjonalność DBMS pachnie o antywzorzec projektowy. Ale jeszcze nie ufam mojemu osądowi.
Jakie są argumenty za i przeciw każdej pozycji? Jakie złe rzeczy mogą się zdarzyć, jeśli użyjemy biginta i jakie są niebezpieczeństwa związane z ponownym opracowaniem funkcji automatycznego zwiększania kół ? Czy istnieje trzecie rozwiązanie, które jest lepsze od któregoś z nich? Jakie mogą być jej powody, dla których warto unikać inflacji wartości nominalnych? Chciałbym usłyszeć również o pragmatycznych powodach - może identyfikatory bigint działają teoretycznie, ale powodują bóle głowy w praktyce?
Aplikacja nie powinna obsługiwać bardzo dużych ilości danych. Wątpię, czy w ciągu najbliższych kilku lat osiągnie 10 000 faktycznych rekordów.
Jeśli robi to jakąkolwiek różnicę, korzystamy z serwera Microsoft SQL. Aplikacja jest napisana w języku C # i używa Linq do SQL.
Aktualizacja
Dziękuję, uznałem istniejące odpowiedzi i komentarze za interesujące. Ale obawiam się, że źle zrozumiałeś moje pytanie, więc zawierają one to, co chciałem wiedzieć.
Tak naprawdę nie martwię się prawdziwym powodem wysokich ID. Jeśli sami nie możemy tego znaleźć, mogę zadać inne pytanie. W tym przypadku interesuje mnie zrozumienie procesu decyzyjnego. W tym celu należy założyć, że aplikacja będzie zapisywać 1000 rekordów dziennie, a następnie usunie ich 9999 . Jestem prawie pewien, że tak nie jest, ale tak właśnie uwierzył mój szef, kiedy poprosiła. Więc w tych hipotetycznych okolicznościach, jakie byłyby zalety i wady używania biginta lub pisania własnego kodu, który przypisuje identyfikatory (w sposób, który ponownie wykorzystuje identyfikatory już usuniętych rekordów, aby upewnić się, że nie ma luk)?
Jeśli chodzi o faktyczny powód, mocno podejrzewam, że dzieje się tak, ponieważ kiedyś napisaliśmy kod do importowania danych z innej bazy danych, co jest dowodem na to, że późniejszą migrację można wykonać w pewnym stopniu. Myślę, że mój kolega faktycznie utworzył kilka tysięcy rekordów podczas importu, a później je usunął. Muszę potwierdzić, czy rzeczywiście tak było, ale jeśli tak, to nie ma nawet potrzeby działania.