Jakiej strategii klucza podstawowego najlepiej byłoby użyć dla modelu relacyjnej bazy danych, biorąc pod uwagę następujące kwestie?

dziesiątki tysięcy użytkownikówwielu klientów na użytkownika (telefon, tablet, pulpit)miliony wierszy na tabelę (stale rośnie)

Azure SQL będzie centralnym magazynem danych, który zostanie udostępniony za pośrednictwem interfejsu API sieci Web. Klienci będą obejmować aplikację internetową i wiele rodzimych aplikacji, w tym iOS, Android, Mac, Windows 8 itp. Aplikacja internetowa będzie wymagać połączenia „zawsze włączone” i nie będzie mieć lokalnego magazynu danych, ale zamiast tego pobierze i zaktualizuje przez api - myślę, że CRUD przez RESTful API.

Wszyscy pozostali klienci (telefon, tablet, komputer stacjonarny) będą mieli lokalną bazę danych (SQLite). Przy pierwszym użyciu tego typu klienta użytkownik musi się uwierzytelnić i zsynchronizować. Po uwierzytelnieniu i zsynchronizowaniu klienci ci mogą działać w trybie offline (tworzenie, usuwanie i aktualizowanie rekordów w lokalnej dbiterze SQLite). Te zmiany zostaną zsynchronizowane z zapleczem Azure.

Rozproszony charakter baz danych pozostawia nam podstawowy kluczowy problem i powód zadawania tego pytania.

Oto, co do tej pory rozważaliśmy:

GUID

Każdy klient tworzy własne klucze. Podczas synchronizacji istnieje bardzo mała szansa na zduplikowanie klucza, ale musielibyśmy to uwzględnić, pisząc funkcjonalność do każdego klienta, aby zaktualizować wszystkie relacje za pomocą nowego klucza. Identyfikatory GUID są duże i gdy rozważanych jest wiele kluczy obcych na tabelę, przechowywanie może z czasem stać się problemem. Prawdopodobnie największym problemem jest losowy charakter GUID, co oznacza, że ​​nie mogą (lub nie powinny) być używane jako indeks klastrowany z powodu fragmentacji. Oznacza to, że musielibyśmy utworzyć indeks klastrowany (być może arbitralny) dla każdej tabeli.

Tożsamość

Każdy klient tworzy własne klucze podstawowe. Podczas synchronizacji klucze te są zastępowane kluczami wygenerowanymi przez serwer. Dodaje to dodatkową złożoność procesu synchronizacji i zmusza każdego klienta do „naprawiania” swoich kluczy, w tym wszystkich kluczy obcych, w powiązanych tabelach.

Złożony

Każdy klient ma przypisany identyfikator klienta podczas pierwszej synchronizacji. Ten identyfikator klienta jest używany w połączeniu z lokalnym identyfikatorem auto-przyrostowym jako złożony klucz podstawowy dla każdej tabeli. Ten złożony klucz będzie unikalny, więc nie powinno być konfliktów podczas synchronizacji, ale oznacza to, że większość tabel będzie wymagać złożonego klucza podstawowego. Problemem jest złożoność wydajności i zapytań.

HiLo (połączony kompozyt)

Podobnie jak podejście złożone, każdemu klientowi przypisywany jest identyfikator klienta (int32) na pierwszej synchronizacji. Identyfikator klienta jest łączony z unikalnym lokalnym identyfikatorem (int32) w pojedynczą kolumnę, aby utworzyć unikalny identyfikator aplikacji (int64). Powinno to spowodować brak konfliktów podczas synchronizacji. Podczas gdy klucze są bardziej uporządkowane w porównaniu z identyfikatorami GUID, ponieważ identyfikatory generowane przez każdego klienta są sekwencyjne, będą występować tysiące unikalnych identyfikatorów klienta, więc czy nadal istnieje ryzyko fragmentacji naszego indeksu klastrowego?

Czy coś pomijamy? Czy są jakieś inne metody warte zbadania? Dyskusja na temat zalet i wad każdego podejścia byłaby bardzo pomocna.