Entity Framework Core - usuwanie obiektu, a relacje

0

Cześć Wam,

Mam dwa przypadki dotyczące EF Core i usuwania obiektów z BD:

  1. obiekt posiłek, który składa się z produktów. Obiekt posiłek jest obiektem "podrzędnym" tzn. po jego usunięciu, chcę osiągnąć taki efekt, że zostanie on usunięty z bazy danych, ale produkty pozostaną - tutaj wydaje mi się, że wszystko działa poprawnie
  2. drugi przypadek to usuwanie produktu, chciałbym określić poprzez EF Core co wtedy ma się zadziać - pożądany przeze mnie efekt (w przypadku mojej aplikacji) to usunięcie z bazy produktu oraz zaktualizowanie wszystkich tabel, do których ma odwołanie o null'e

Nie wiem niestety czy jest to dobre podejście, czy lepiej "nie usuwać" lub nie pozwolić użytkownikowi na froncie usuwać obiektu, który jest w użyciu przez inne?

Prośba o porady, wszystkie komentarze mile widziane :)

2

Przy tworzeniu relacji określ usuwanie jako kaskadowe.

builder.HasOne(x => x.Order)
                .WithMany(x => x.Categories)
                .OnDelete(DeleteBehavior.Cascade)
                .HasForeignKey(x => x.OrderId);

Wtedy przy usuwaniu osiągniesz dokładnie taki efekt o ,którym piszesz.

1

@Botek: "2) drugi przypadek to usuwanie produktu, chciałbym określić poprzez EF Core co wtedy ma się zadziać - pożądany przeze mnie efekt (w przypadku mojej aplikacji) to usunięcie z bazy produktu oraz zaktualizowanie wszystkich tabel, do których ma odwołanie o null'e' "- ja taki przypadek określiłbym jako źle zaprojektowana struktura bazy danych. Może po prostu brakuje w Twoim projekcie jeszcze jednej tabeli łączącej ze sobą rekordy z tabeli A i B. W takiej tabeli C wystarczyło by usunąć rekord i połączenia pomiędzy A i B znika bez konieczności aktualizacji tabel A i B.

2
cw napisał(a):

ja taki przypadek określiłbym jako źle zaprojektowana struktura bazy danych.

Ja bym powiedział raczej, że to jest źle zaprojektowana rzeczywistość. No chyba, że autor wątku dysponuje technologią pozwalającą na podróżowanie w czasie.

Jeśli zjadłem kiedyś ziemniaka, a teraz ziemniaki już nie istnieją, to nie sprawia nagle, że ja jednak nie zjadłem tego ziemniaka.

A w ogólnym przypadku, to danych się zazwyczaj z baz danych nie usuwa. A już na pewno nie takich, które zostały użyte.

0
somekind napisał(a):
cw napisał(a):

ja taki przypadek określiłbym jako źle zaprojektowana struktura bazy danych.

Ja bym powiedział raczej, że to jest źle zaprojektowana rzeczywistość. No chyba, że autor wątku dysponuje technologią pozwalającą na podróżowanie w czasie.

Jeśli zjadłem kiedyś ziemniaka, a teraz ziemniaki już nie istnieją, to nie sprawia nagle, że ja jednak nie zjadłem tego ziemniaka.

A w ogólnym przypadku, to danych się zazwyczaj z baz danych nie usuwa. A już na pewno nie takich, które zostały użyte.

No to powiem jak to u mnie w tej chwili wygląda.
Tabele poniżej:
Products -> MealsProducts <- Meals
Usuwając wiersz z tabeli Products, usuwam go jednocześnie z MealsProducts (efekt pożądany), wtedy na froncie wygląda to tak, że w obiekcie Meals jeśli było 10 produktów, to teraz jest 9.

2

W sumie to @somekind to dobrze opisał. Ja tylko dodam od siebie dla potwierdzenia, że to jest problem natury procesów biznesowych a nie techniczny jako taki.

W pewnym sensie fajnie przedstawiłeś tym wątkiem błąd myślowy jakim często wykazują się programiści. I nie jest to żadna krytyka w Twoją stronę bo wszyscy czasem w to popadamy. Skupiasz się na detalach technicznych, a powinieneś skupić się na odpowiednim technicznym zamodelowaniu rzeczywistości. W realnym scenariuszu odpowiedź na Twoje pytanie miał by ekspert domenowy/klient a nie inny programista.

1 użytkowników online, w tym zalogowanych: 0, gości: 1