C# - Rejestracja:prawie 7 lat
- Ostatnio:ponad 2 lata
- Postów:27
0
IsDeleted pole w bazie, najbardziej debilny pomysł z jakim się spotkałem!
Bo to oznacza same problemy. Załóżmy, że w tabeli jest unikalny indeks na pola: Nazwa i IsDeleted, po oznaczeniu rekordu z nazwą "Ala" jako skasowany, teoretycznie możemy wpisać drugi rekord z taką nazwą ale jego skasowanie już się nie uda.
Z baz danych nic się nie kasuje.
Skasowanie w sensie zmiana flagi IsDeleted.
@.Adam: To jak robisz soft-delete?
:-|
A nie jest problem z tym soft-delete, to że przy wyciąganiu czegoś z bazy ciągle musimy pamiętać o dopisywaniu !IsDelete?
Nie wiem, pytam. Wydaje mi się to błędogenne. A może by przenosić usunięte rekordy do drugiej bazy danych, tylko ze skasowanymi.
Największy problem jest chyba z tym, że po "usunięciu" rekordu wartość w kolumnie z unikalnym indeksem nie jest zwracana do puli wolnych wartości. Ale czy naprawdę jest to taki problem? Jeśli mamy np. tabelę użytkowników, to czy jest sens pozwalać nowym użytkownikom na wybranie nazwy, którą wcześniej nosił jakiś zbanowany użytkownik?
@nobody01:
Największy problem jest chyba z tym, że po "usunięciu" rekordu wartość w kolumnie z unikalnym indeksem nie jest zwracana do puli wolnych wartości. czekaj, co? przecież ona nie powinna wracać do puli wolnych wartości...
@WeiXiao: No właśnie też tak uważam, a to jest chyba główny argument przeciwko IsDeleted.
Jeśli ta wartość nie powinna być zwracana do puli wolnych wartości, to nie musimy stosować composite index, czyli nie mamy problemu, o którym pisał @.Adam ;)
Delete to delete fizyczne z bazy a nie flaga, możesz użyć pole IsActive do nie pokazywania przestarzałych lub nieaktywnych rekordów, ale z żadnym kasowaniem nie powinno to mieć powiązania.
@kzkzg: nie musisz wszędzie mieć checkow. Możesz robić selekty z widoków (które to odrzuca oflagowane rekordy) w bazie lub jeśli używasz jakiś ORM zastosować globalne filtry.
Tia.. w każdym widoku pamiętać o filtrowaniu według flag, życzę powodzenia....
Albo nie miałeś doczynienia z bardziej rozbudowanymi systemami (w których soft delete to zazwyczaj standard), albo jesteś jakimś fanatykiem-idealistą. Albo jedno i drugie. Powiedz nam proszę, jak Twój pomysł z flagą IsActive rozwiązuje problem? Bo jak dla mnie to dokładnie to samo co soft delete, tylko ubrane w inny płaszczyk.
Delete to fizyczne usunięcie rekordu z bazy danych, a Isactive to inny mechanizm, wtedy gdy nie możemy skasować rekord bo relacje, ale możemy domyślnie nie wyświetlać go używamy Isactive.
@Aventus: Widzisz, nie znasz się. :-|
@._.: no właśnie widzę kurka :(
Co to są dane połączone relacjami?
@._. fk --> pk? :P
A jaka jest domena fk i pk w krotce ? :-|
@kzkzg: ale tutaj chyba nikt nie uwaza fizycznego usuwania rekordow za cos zlego, zakladajac ze nie bedzie to kolidowalo z wymogami systemu/regulacjami prawnymi. Jedynym problemem jest nasz specjalista twierdzacy ze cos takiego jak soft delete nie istnieje (no bo albo usuwasz, albo nie, wszystko jest przeciez binarnie proste...). A jesli to stosujesz to jestes debil i tyle.
Nikogo nie obrażam, zaproponowałem tylko zamiast super pomysłu Soft-delete flagę Isactive i tyle, nie uważam się za specjalistę pomimo dość dużej praktyki w pisaniu kodu produkcyjnego, codziennie uczę się czegoś nowego i nikogo nie obrażam Panie @Aventus!!!
soft delete = isActive lol
Lol, no właśnie, że nie, rozumiesz znaczenie pól?
jaka jest różnica?
W brzmieniu...tylko
No i nie jest to programowe oznaczenie rekordu jako usunięty, a co z jego potomkami, też Soft delete????
@.Adam A ja powtarzam- po raz kolejny- ze Twoja propozycja jest tym samym co soft delete, tylko inaczej to nazywasz. Co innego gdybys chcial przechowywac wartosc jak np. Status- archived, active, suspended, whatever. Ale tu znow wszystko zalezy od wymogow systemu, i potrzebowalo by innego podejscia do tego jak wyciagac takie rekordy z bazy, filtrowac je itp. Zamieniajac IsDeleted na IsActive nic nie zmieniasz, bo logika filtrowania (jakakolwiek by ona nie byla, czy to widoki, czy filtry w kodzie) pozostanie taka sama.
@Aventus Nazwa i znaczenie pola ma istotne znaczenie. Delete programowe a ukrycie poprzez Isactive to dwa różne podejścia, ukrycie rekordu to tylko to i nic więcej a oznaczenie rekordu jako skasowany rodzi pytania co z potomkami, relacjami!!??
I właśnie tu leży problem- to nie dwa różne podejścia, tylko nazwa pola jest inna. Co do drugiego pytania to jest trochę bez sensu, przecież wszystko zależy od problemu. Jeśli mam główną encje (aggregate root) przez którą dostaje się do innych (np. Otwieram zamówienie żeby zobaczyć szczegóły) to wystarczy zrobić soft delete właśnie tego jednego rekordu. Bo nie bede już miał możliwości dostania się do innych. Jeśli z kolei UI pozwala działać w drugą stronę to trzeba to jakoś rozwiązać, i również nie wyklucza to używania soft delete.
Jeśli w systemie należy zastosować usunięcie jakiejś encji bez fizycznego skasowania z bazy danych, to właśnie nazwa IsActive nie ma sensu. Miała by sens gdybym nadal wyświetlał te encje i ich status. Jeśli np. użytkownik kliknął "Delete" to z punktu widzenia klienta nie ma znaczenia co fizycznie stało się z tą encją. Najważniejsze jest to że ma się więcej nie pojawiać, ponieważ została usunięta w świetle wymagań biznesowych danego kontekstu. Tak więc oflagowane IsDeleted jest jak najbardziej na miejscu.
@Aventus To twój przykład i w tym konkretnym przypadku ma sens. Ale załóżmy, że są widoki idące od potomków, to co oznacza, że potomek nie ma flagi skasowany a rodzic skasowany, pokazywać potomka czy nie? Ale idziemy od potomków i dochodzimy do rodzica nieaktywnego, pokazywać potomka czy nie? Skasowany a nieaktywny? W domyśle skasowane powinny być niewidoczne w widokach a nieaktywne, nie jest to już takie pewne.
Nie rozumiem was, po co wam ta wartość IsDeleted.? Lepiej jest zapisać event np. ProductDeleted a potem usunąc rekord Produktu.
A jak co to powinno być IsHidden :-|
Nie poważałem soft delete tylko uważam to za bardzo zły pomysł!
@.Adam: jest pewne jeśli ma się konkretne wymagania. Nie oczekuj ode mnie odpowiedzi na takie pytania bo jej nie mam. Od tego są zespoły które przysiadają do stołu i projektują rozwiązanie problemu zależnie od natury problemu. Czy gdzieś soft delete się nie sprawdzi? Oczywiście! Ale nie zmienia to tego ze coś takiego jak soft delete istnieje, jest stosowane, i nie ma w tym nic debilnego.
@Aventus Masz prawo do własnej opini. Dziękuję za dyskusję. Zawsze to coś ciekawego wnosi.
Pytanie, po co usuwać dane z bazy? Odpowiadam, ano po to aby nie było śmieci?!
A może on ma bazę tylko do odczytu?
Bo lubi sprzątać.
:-|
@.Adam:
Załóżmy, że w tabeli jest unikalny indeks na pola: Nazwa i IsDeleted, po oznaczeniu rekordu z nazwą "Ala" jako skasowany, teoretycznie możemy wpisać drugi rekord z taką nazwą ale jego skasowanie już się nie uda. - to jakiś czelendż? Przynajmniej na dwa sposoby to zrobię...
Zrób i na 10 sposobów , to przykład mistrzu.
@.Adam: tylko że tu nie o moją opinię chodzi, a o Twoją walkę z wiatrakami. Nie mówiąc już o treści Twojego posta która wywołała tą dyskusje. Jeśli będziesz strofował wszystko co jest Ci obce stwierdzeniem że jest debilne, to będziesz wyglądał bardzo nieprofesjonalnie w oczach innych programistów. A tego chyba nie chcesz?
@Aventus Akurat nie jest mi to obce. Może za ostro wyraziłem swoją dezaprobatę do pomysłu. Przepraszam jeśli uraziłem czyjeś ego, chodziło tylko o krytykę rozwiązania s nie osoby.
@Marcin.Miga: Tak z ciekawości, jakbyś to zrobił? ;)
@nobody01: Wysłałem ci PW. Za dużo, by tu pisać...
@Marcin.Miga: Troszkę zeszło z wyjaśnieniami, a skoro tak to i rozwiązanie nie jest proste. Drogi Marcinie jestem ciekaw Twoich rozwiązań i przemyśleń?!
Zeszło, bo nie było mnie w domu... :) A w skrócie, to rozwiązanie, to zastosowanie w idDeleted, że 0 oznacza nieusunięty. Każda inna wartość to usunięty. Np ID. Drugie rozawiązanie polega na zrobieniu indeksu unikalnego w ten sposób:
create unique index users2_ui on users2(nick, (case when deleted=0 then deleted end));
A tak z ciekawości zapytam, bo ja współpracuję przy rozwoju systemu ERP, to norma z programowym flagowaniem rekordów jako usunięte? Interesują mnie tylko informacje od osób robiących podobne rzeczy?
Norma. Pewnych danych (np. finansowych) nie możesz usuwać.
Tak wiem Marcinie, w tematach kadrowo płacowych też nie da się pewnych rzeczy usunąć, ale nie stosujemy flagowanie jako usunięty ale jako nieaktywny lub/i archiwalny!
A jaka to różnica? Usuwasz, bo ... np. RODO, ale nie możesz go usunąć ze względów finansowych, więc zaznaczasz go usunięty/nieaktywny/archiwalny... jak zwał tak zwał. Efekt ważny
No jest różnica, starałem się to trochę wyłuszczyć wcześniej!!!
To też ktoś ci odpowiedział, że danych z bazy się nie kasuje...
A tak z ciekawości zapytam, bo ja współpracuję przy rozwoju systemu ERP, to norma z programowym flagowaniem rekordów jako usunięte? Interesują mnie tylko informacje od osób robiących podobne rzeczy? Tak!. Tam jest dokładnie to samo co w CMS'ie blogowym jedna z normalizowana baza z soft delete, w co niektórej tabeli.
Tak to norma, i tak po raz kolejny zaznaczam że jakkolwiek byś nie nazwał flagi to jest to równoznaczne z soft delete jeśli po stronie klienta taki rekord jest uznany jako usunięty. Zresztą kolega wyżej to samo potwierdził. Mimo wszystko pole DeletedDate jest zazwyczaj lepsze bo mamy przynajmniej również informacje kiedy usunięcie miało miejsce.
Bzdury i tyle...
@Aventus Żartowałem. Dużo zależy od systemu, np. przy magazynach bardziej miałby sens podział na dwie bazy, jedna do odczytu (dla pracowników) a druga trzyma wszystkie transakcje (w tym Deleted, Closed, StusChanged, etc...) Wtedy jak mówi @Adam (chociaż nie wiem, czy o to mu chodzi) w tej do odczytu kolumna Deleted niemiałaby sensu.
No tak, ale przeciez kiedy mowa o soft delete to w przypadku kiedy wlasnie nie stosuje sie dodatkowych mechanizmow. Chociaz scenariusz z dodatkowa baza wydaje sie jakims przeinzenierowaniem. To taki udawany Event Sourcing, wiec czemu po prostu nie stosowac ES? Tylko wtedy uwaga- fizycznie nie usuwa sie absolutnie niczego, wiec Adam moglby dostac zawalu ;)
Ok, tylko przykład słabo trochę podałeś. Bo ta druga baza- czyli event store- jest jedynym "source of truth" i w jakichkolwiek innych bazach można sobie usuwać jak i odtwarzać rekordy do woli. Przy zastosowaniu ES trzeba odwrócić punk widzenia- dodatkowe bazy to tylko read modele i przechowują stan zbudowany z odtwarzania eventow. No ale właśnie, tutaj stosuje się soft delete na potęgę bo "usunięcie" czegokolwiek to po prostu dodatkowy event. Owszem, w takim wypadku zapewne usuniemy rekord z read modeli, ale ogólnie z całego systemu nic nie zginie.
Ładnie to opisałeś. To nie mówcie nic Adamowi o EventStore, niech myśli, że jest tam tylko baza do odczytu i problem rozwiązany. Ciii... bo usłyszy. :-|
Dziękuję za zainteresowanie, troskę o moje samopoczucie i stan zdrowia :). Niestety sezon grillowa już się skończył, w sklepach brak węgla więc proszę nie grillujcie mnie na drewnie bo drewno daje większą temperaturę (empiryczne sprawdzone). Ofiara szybciej wyzionie ducha. ;) ;).
A to nie jest problem ja mam własną kopalnię węgla i uranu, z którego produkuje baterie dla telefonów Samsunga. Nie słyszałeś, że baterie mu wybuchają.?
A to najlepszy chyba taki prasowany wegiel drzewny, jeśli masz las i wypalaczy na własność to jak najbardziej reflektuję na takiego grilla, a co do baterii samsunga, każdemu zdarzają się chwile słabości, ;) ;)
:-| Nie ma się co za dużo wydurniać, w tak poważnym miejscu.
- Rejestracja:prawie 7 lat
- Ostatnio:ponad 6 lat
- Postów:250
1
Prosta strzałka do bazy przez trzy warstwy to jest jakaś architektura?. A jak taka architektura się nazywa.? Interfejsy, które niczemu nie służą. Testy, które nie mają sensu jak zamokowanie bazy i sprawdzenie, czy można coś do niej dodać.
Widać, że autor kierował się jakimiś wyższymi pryncypiami oraz metrykami projektując paczki. Jest w tym coś pięknego.
- Rejestracja:około 17 lat
- Ostatnio:dzień
- Lokalizacja:Wrocław
8
.Adam napisał(a):
IsDeleted pole w bazie, najbardziej debilny pomysł z jakim się spotkałem!
No to chyba konkurs na najbardziej debilny post roku w działach technicznych mamy rozstrzygnięty.
- Rejestracja:ponad 21 lat
- Ostatnio:około 15 godzin
- Lokalizacja:Kraków
- Postów:1114
1
Jeśli dowolny diagram zależności w projekcie przypomina:
- nieuporządkowany chaos
- kłębek wełny
- spaghetti
wiedz że się coś dzieje ;)
Ten gościu ma 6 lat doświadczenia i jest seniorem. Moje teorie spiskowe się potwierdzają.
- Rejestracja:około 7 lat
- Ostatnio:ponad 2 lata
- Lokalizacja:Gdańsk
- Postów:647
0
Nawet ta przykładowa aplikacja: https://github.com/dotnet-architecture/eShopOnWeb, która jest promowana przez Microsoft jako punkt odniesienia przy projektowaniu architektury, zdaje się pokazywać złe praktyki (logika biznesowa w kontrolerach, sterowanie przepływem za pomocą wyjątków i takie tam). Już w nic nie można wierzyć w internecie. ;(
Logiki biznesowej to ja akurat tam w kontrolerach nie widzę.
- Rejestracja:prawie 7 lat
- Ostatnio:ponad 6 lat
- Postów:250
0
public Address ShipToAddress { get; private set; }
// DDD Patterns comment
// Using a private collection field, better for DDD Aggregate's encapsulation
// so OrderItems cannot be added from "outside the AggregateRoot" directly to the collection,
// but only through the method Order.AddOrderItem() which includes behavior.
ale że co?
A to, że ktoś pisze, że odkrył takie coś jak enkapsulacje a to, co powinno być enkapsulowane w DM jest wepchnięte do serwisu aplikacyjnego. W projekcie panuje ogólny syf.
no ale to przecież nie jest w serwisie tylko w agregacie
Jak koś łamie wszystkie możliwe założenia DDD, a potem pisze, że prywatna kolekcja jest zgodna z założeniami DDD, nie jest zabawne? Nie macie za grosz poczucia humoru.
.HasDatajeszcze nie było, bo dodali to w jakiejś późniejszej wersji EF Core. Zresztą ja nigdzie nie pisałem, że robienie inicjalizacji bazy w startupie to złe rozwiązanie.