Tworzenie dodatkowego klucza podstawowego w bazie danych dla niektórych tabel

Do niektórych moich tabel chcę dodać „second_primary_key”, który będzie identyfikatorem UUID lub jakimś losowym długim kluczem. Potrzebuję tego, ponieważ dla niektórych tabel nie chcę ujawniać liczb całkowitych w mojej aplikacji internetowej. Oznacza to, że na stronie „/ faktury” mam listę faktur i link do „/ faktur /: id” gdzie: id jest liczbą całkowitą. Nie chcę, aby użytkownik wiedział, ile faktur jest w moim systemie, dlatego zamiast „/ invoices / 123” chcę użyć jego „second_primary_key”, aby adres URL miał postać „/ invoices / N_8Zk241vNa”

To samo dotyczy innych tabel, w których chcę ukryć prawdziwy identyfikator.

Zastanawiam się, czy to powszechna praktyka? Jaki jest najlepszy sposób na wdrożenie tego?

A jak się nazywa ta technika, żeby ją wyszukać?

Możesz dodać kolumnę UUID, ale tak naprawdę nie musisz (i nie powinieneś). To dotyczy warstwy prezentacji. Nie marzyłbyś o powiedzeniu, przechowując wartość waluty jako 1,999 USD, a także 1999.

Chcesz tylko w jakiś sposób ukryć wartość aplikacji w locie. Możesz to zrobić w samej aplikacji lub jako widok bazy danych.

Ponieważ mówimy tylko o jednej wartości, może spójrz na szyfrowanie dwukierunkowe, takie jak AES lub podobne - im bardziej lekkie, tym lepsze.

Hashowanie może być inną możliwością - zależy to od tego, czy chcesz odzyskać numer faktury, ponieważ mieszanie jest jednym ze sposobów.

Posiadanie „alternatywnego klucza podstawowego” to dobrze znana koncepcja w modelowaniu relacyjnych baz danych, nazywana jest „kluczem alternatywnym”, a czasem także „kluczem wtórnym”. Zestaw „potencjalnych kluczy podstawowych” nazywa się „kluczami kandydującymi”. Zobacz https://beginnersbook.com/2015/04/alternate-key-in-dbms/

Sposób implementacji zależy wyłącznie od Ciebie, zwłaszcza jeśli chcesz ukryć całkowitą liczbę rekordów. Nie ma „najlepszego sposobu”, powinieneś sprawdzić swoje wymagania, takie jak dozwolony lub użyteczny zestaw znaków, maksymalna długość, jeśli chcesz, aby w identyfikatorach rozróżniana była wielkość liter, czy nie, jeśli chcesz, aby były czytelne na drukowanej fakturze, jeśli ktoś musi być w stanie odpowiedzieć na nie bezbłędnie przez telefon i tak dalej.

Większość faktur ma numer faktury, który według większości zasad rachunkowości musi być sekwencyjny lub księgowy może nie podpisać się z wynikami roku lub IRS (lub podobny w twoim kraju) może chcieć przeprowadzić pełny audyt na twoich kartach.

Użytkownik może wywnioskować z numeru faktury, ilu klientów obsłużyłeś lub ile czasu upłynęło, zanim zmieniłeś strategię numeracji na fakturach.

Liczba faktur przechowywanych w bazie danych nie jest miarą łącznej sumy faktur. Istnieją inne sposoby, aby się tego dowiedzieć, w tym zażądanie raportów rocznych z Izby Handlowej.

Chciałbym jednak zablokować fakturę za ekranem logowania użytkownika, aby nie każdy mógł o to poprosić. Następnie przy logowaniu użytkownika mogą użyć metodologii ajax, aby zażądać zaległych faktur itp. Zabezpiecza to Twoje dane, ukrywa adres URL za pomocą ajax (zwykle nikt nie przejmuje się szczegółami, jak budowane jest zapytanie ajax) , a Ty kontrolujesz sposób wyświetlania i oferowania danych.

Możesz użyć do tego hashidów , które mają dokładnie rozwiązać ten scenariusz.

Będzie kodować identyfikator bazy danych w krótkim skrócie (podobnym do adresu URL filmu w YouTube) i nie będzie wymagał dodawania żadnych dodatkowych kluczy do tabeli.

Możesz utworzyć kolejny unikalny klucz, ale nie powinieneś. Nie z podanego powodu. Istnieją prostsze sposoby ukrywania rozmiarów tabel.

Przechowywanie N_8Zk241vNakosztuje 12 bajtów na wiersz w tabeli, a nawet więcej w indeksie. To dość marnotrawstwo na to, czego potrzebujesz.

Zaszyfrowanie liczby całkowitej nie idkosztuje miejsca i jest prawie zerowe w czasie wykonywania. Sposób wykonania zależy od języka programowania i / lub bazy danych.

Zauważ, że z AES dostajesz 128-bitową liczbę całkowitą, co oznacza 22 znaki w base64, prawdopodobnie więcej niż chcesz. Szyfr o rozmiarze bloku 64, takim jak DES lub 3DES, daje 11 znaków, tak jak chcesz.

Użyj różnych kluczy dla różnych tabel.

Jeśli wszystko, czego potrzebujesz, to ukrywanie rozmiarów tabel, możesz zastosować wspólną sekwencję dla wszystkich tabel. Pamiętaj, że może być wąskim gardłem, jeśli w wielu twoich tabelach występują częste wstawienia. Z czymś takim jak Hibernacja i algorytm Hi-Lo problem ten znika.

Utworzenie dwóch różnych kluczy podstawowych przez IMHO nie jest możliwe. Oczywiście możesz umieścić ten identyfikator użytkownika w bazie danych, aby mieć go jako „alias” dla bieżącego klucza podstawowego. Możesz umieścić indeks nad tą kolumną z unikalnym ograniczeniem, ale klucz podstawowy jest (z istoty) jednym w obrębie jednej tabeli. Może istnieć złożony klucz podstawowy, ale nie tego szukasz.

Sugeruję więc umieszczenie go tam, ale mając go tylko z indeksem. Możesz utworzyć komponent obsługi dla kwerendy danych według PK, a także innej unikalnej kolumny. Podczas obsługi żądania „/ faktury / ...” po prostu sprawdź parametr - jeśli jest liczbą całkowitą, wyszukaj identyfikator, w przeciwnym razie wyszukaj identyfikator użytkownika. Lub możesz mieć wyszukiwanie UUID jako rezerwowe, gdy wyszukiwanie ID niczego nie znalazło.

A jeśli chodzi o generowanie „losowych” uuidów: dlaczego nie coś w rodzaju „weź ID, dodaj STAŁY, przekonwertuj na szesnastkowy”. Nieprawidłowość ID zapewni unikalność Uuida, liczba szesnastkowa jest trudniejsza do odczytania dla normalnych śmiertelników + dodanie stałej pozwoli uniknąć posiadania UUID takiego jak 00000001.

Jeśli oba klucze wskazują na ten sam fakt i nigdy by się nie zderzyły. Dlaczego nie wyprowadzić drugiego klucza z oryginalnego za pomocą funkcji skalarnej, która utworzyłaby niestandardowy kod skrótu oryginalnego klucza.

Alternatywnie możesz utworzyć tabelę mapowania aneksów, w której byłyby przechowywane obie wersje klucza. ta tabela będzie działać jako słownik do wyszukiwania klucza dodatkowego.

Według mojego zrozumienia, klucze są ukrytymi indeksami, a im więcej dodajesz indeksów, tym wolniejsze będą wstawki.

Innym podejściem do konkretnego przypadku użycia jest to, że zamiast modyfikować bazę danych i aplikację, możesz po prostu utworzyć niestandardową trasę do faktur, tak więc / invoices /: f (id) gdzie f (id) jest jakąś funkcją id.

Niestandardowa trasa jest odpowiedzialna za odwzorowanie żądania na właściwą akcję po stronie serwera.

Jest to całkowicie akceptowana praktyka, zwana także „kluczem alternatywnym” (AK). Zasadniczo AK jest kolejnym unikalnym indeksem lub unikalnym ograniczeniem.

Możesz nawet tworzyć ograniczenia klucza obcego na podstawie swojej AK.

Możliwy przypadek użycia jest taki, jak wyjaśniono: masz klastrowaną PK na ciągle rosnącym numerze identyfikacyjnym, ale nie chcesz, aby ten numer był wyświetlany lub używany jako kryterium wyszukiwania, ponieważ można go po prostu zgadnąć. Zatem dodatkowo masz losowy unikalny identyfikator lub numer referencyjny jako AK, i to jest identyfikator, który przedstawiasz użytkownikowi

Istnieje kilka rodzajów kluczy / indeksów. Klucz podstawowy jest specjalnym unikalnym indeksem i, jak mówią odpowiedzi, możesz z pewnością stworzyć kolejny unikalny klucz. Zgadzam się, że najlepiej nie ujawniać wewnętrznych elementów bazy danych, chyba że istnieje bardzo uzasadniony powód.

Ponieważ pytanie dotyczy kontekstu faktur i liczb, warto zbadać, jak branża księgowa oczekuje, że wyglądają numery faktur: http://smallbusiness.chron.com/assign-invoice-numbers-52422.html

Może wydawać się niechlujny mieć wewnętrzny identyfikator, który jest kluczem podstawowym i innym unikalnym polem z widocznym numerem faktury aplikacji / klienta. Ale to nie jest tak nieczyste, kiedy, powiedzmy rok później, klient chce przyjąć nowy system numeracji faktur. W takim przypadku nie zakłóciłbyś wewnętrznego identyfikatora i jego relacji w innych tabelach, aby przenumerować całą kulkę wosku. Zachowałbyś swój wewnętrzny identyfikator w stanie, w jakim się znajduje, i ponownie numerujesz numer faktury innej niż wewnętrzna.

Idealnie starasz się nie wiązać ze sobą tabel na kluczach / kluczach obcych, które mogą się zmienić, i utrzymywać wewnętrzne tabele i relacje przezroczyste dla warstwy aplikacji.

Idź po to.

Nie różni się to od pola „ślimaka”, które często mają artykuły na blogu i tym podobne - unikalny sposób odwoływania się do rekordu bazy danych oddzielonego od klucza podstawowego, nadającego się do użycia w adresie URL. Nigdy nie słyszałem, żeby ktokolwiek się z nimi sprzeczał.