[Nofenak]

Czy dodajecie tego typu constrainty na klucze obce w bazach danych?
#programowanie #naukaprogramowania #programista15k #java

[Patres]

@Nofenak tak

[fiolkins]

@Nofenak co skłoniło Cię do zadania tego pytania?

[Nofenak]

@fiolkins: Bo taka walidacja jest też zazwyczaj po stronie apki. Np. żeby dodać Screening to musi istnieć jakiś Film.

[fiolkins]

@Nofenak taka „walidacja” powinna być przedewszystkim po stronie bazy danych. W 99% przypadków spójność danych będzie najważniejsza

[Pharos]

@fiolkins: W dodatku po stronie bazy danych to w zasadzie jedyny sposób na zachowanie konsystencji. Niewiele osób się tym przejmuje, ale domyślny poziom izolacji transakcji w wielu silnikach bazodanowych - committed read, gdyby nie np. unikalne klucze, to pozwoli na dodanie duplikatów. Zresztą bardzo łatwo jest taki case odtworzyć, bo wystarczy zatrzymać transakcję bazodanową na zwykłym insercie w debuggerze i puścić drugi raz ten sam request.

[tylko_zerknalem]

Bo taka walidacja jest też zazwyczaj po stronie apki. Np. żeby dodać Screening to musi istnieć jakiś Film.

@Nofenak: W ogólności walidację warto mieć na każdej warstwie, czyli baza danych + backend + frontend. Twój przypadek oczywiście nie dotyczy tego ostatniego. Dodatkowo im więcej takich checków może za Ciebie zrobić baza danych, tym lepiej. Długoterminowo będziesz miał dzięki temu większą gwarancję spójności danych.

committed read, gdyby nie np. unikalne klucze, to

[Pharos]

Poziom "serializable" też pozwoli przy braku unikalnych kluczy.

@tylko_zerknalem: Prawda. Napisane z rozpędu.

[Saly]

@Nofenak: możesz używać bazy na różne sposoby. WIększość używa takich constraintów, bo jest to wygodne. Aplikacja jest dużo bardziej elastyczna niż baza danych i jeśli nie masz jakiegoś event sourcingu (tj. bazę można odtworzyć) to powinieneś dbać o to, żeby baza sprawdzała najważniejsze założenia odnośnie modelu bazy