Kiedy najlepiej zakładać constrainty przy migracji danych?

dzień dobry
otóż rzecz jest taka
zmienia się format danych no i trzeba migrować dane

baza danych to MSSQL

migracja polega na tym

1. utworzenie nowego schematu (tabel)
2. wypełnienie go danymi
3. usuniecie starego schematu (tabel)

Jak widać nic wielkiego

pytanie mam takie

Kiedy najlepiej tworzyć constrainty (PK, FK) na nowych tabelach

1. od razu przy tworzeniu tabel
2. dopiero po migracji i napełnianiu tabel danymi

Testowałem to na własną rękę i wychodziło mi że jak zwykle to zależy
czyli im więcej danych w tabeli tym bardziej podejście drugie im miej tym bardziej podejście pierwsze
(spadek wydajności 2 vs 1 przy małych - do miliona rekordów - do 30%)
(wzrost wydajności 2 vs 1 przy dużych - dziesiątki/setki milionów rekordów - do 12-15%)

Jako że nie jestem ekspertem i nie mam zbyt dużego doświadczenia ośmielam się Was prosić o poradę (może coś źle robiłem albo coś) może macie swoje doświadczenia migracja danych a zakładanie constraintów na bazie
z góry dziękuję za odpowiedź

Na początku. Lepiej zapobiegać niż leczyć.

Podstawowe pytanie czy to rzeczywiście jest problem iż migracja będzie trwać o te 30% dłużej? Jeśli system działa od 8-16, albo macie deploy niebiesko-zielony to najwyżej wypijesz jedną kawę więcej. Jeśli faktycznie walczycie z czasem i macie krótkie okno czasowe to może warto to optymalizować. Lub przekonać szefa iż pora ra deploy niebiesko-zielony

Rozdziel te dwa zagadnienia:

• instalacja systemu ( tabele, klucze główne, obce, triggery, indeksy itd.)
• migracja danych

Skupisz się wówczas na samym procesie migracji i jego technicznej realizacji w ramach uzgodnionej strategii migracji. Whaaaaat?

W zależności od tego co klient akceptuje/chce/może/musi jest kilka opcji (strategii) realizacji takich migracji, np.

• big bang
• phased
• online
• trickle
• hybrid

Którą wybrać, to już wynika od konkretnego przypadku. Różne branże mają różne ograniczenia, różni klienci inne spojrzenie na ciągłość biznesu, utratę przychodu, starty wizerunkowe, koszty wynikające z implementacji wybranej strategii, dostępność zasobów, ograniczenia czasowe itp.

Zakładając, że robisz big banga (czyli masz downtime) to możesz sobie technicznie pozwolić na:
a) zdjęcie constraintów/indeksów/ograniczeń
b) batchowe ładowanie danych
c) dodanie constraintów

Przy big bangu i braku constraintów, żadne procesy zewnętrzne nie wstawią Ci niepoprawnych danych (bo będzie downtime). Bez constraintów dane zostaną załadowane szybciej. Dodawanie constraintów możesz zrealizować równolegle (przy zachowaniu odpowiednich zależności, tj. dodajesz najpierw PK, a dopiero później FK). Minusem jest to, że jak będziesz miał dane, które nie pasują do nowego modelu, to się ten proces technicznie wywali i co wtedy?

Rozwiązaniem jest odpowiednie zaprojektowanie procesu migracji, tak by:

• wyłapać błędy przychodzące ze źródła (niezgodność danych z deklarowanym formatem danych, brak spójności referencyjnej)
• wyłapać przypadki brzegowe i je zaadresować w rozwiązaniu jako osobne use case'y ("aaa tak, czasem w polu PESEL trzymamy FOO#567 i ten FOO# to taki specjalny prefiks na obejście problemu z ...)
• naprawić błędy u źródła (data cleansing)
• raportować problemy na każdym etapie
• robić dry-runy jak często się da, na jak najświeższych ekstraktach danych produkcyjnych