Modyfikowanie danych w tabelach powiązanych

Na początku bardzo dziękuję wszystkim za udział w dyskusji

Fac napisał(a):

Dodaj sobie w klasie (tablicy, liście, kolekcji, jsonie, xmlu, czy co tam masz pod maską) przechowującej daną pozycję właściwość przechowującą status (puste/I/U/D), (...)

Tak, do tego też wniosku doszliśmy w poprzednich wypowiedziach :). Ale dzięki za potwierdzenie.

cerrato napisał(a):

SQL-em raczej nie chcę sprawdzać co się zmieniło, więc muszę przerzucić to na aplikację (jakiś status każdej pozycji co z nią zrobić Add/Update/Delete/None)

Pytanie - wcześniej pisałeś, że to apka webowa, jakieś API/dżejson. Czy masz możliwość grzebania w endpointach/zmiany czegoś na serwerze, czy jedynie możemy działać w oparciu o front?

Wszystko piszę sam (front i backend, więc mam dowolność

Marcin.Miga napisał(a):

Sprawdzanie przez alikację będzie na pewno dużo wolniejsze, niż po stronie bazy danych. Musisz pobrać stare dane, sprawdzić z nowymi, nadać statusy itd.
Odpisałem ci w komentarzu, jak to szybko, łatwo i przyjemnie zrobić w PostgreSQl, bo ma do tego odpowiednie mechanizmy...
Szybki UPDATE w postgreSQL....

Dzięki wielkie! Później na spokojnie sobie to przeanalizuję, bo to taki bardziej zaawansowany SQL jak dla mnie ;) Na prostym przykładzie wygląda ok, ale zakładając, że tabele mogą mieć ponad 100 kolumn i wiele powiązań to wolałbym stosować rozwiązania, które w pełni rozumiem :)

Pytanie również w jakim kontekście szybsze? Chodzi Ci o czas napisania kodu czy samo jego wykonanie?
Pytam, bo jednak mam wrażenie, że statusy będą jednak nieco wygodniejsze (?) - a przynajmniej lepiej rozumiem tą koncepcję :)

No i pytanie czy Twoje rozwiązanie zakłada również DELETE oraz INSERT na powiązanej tabeli? Bo sam UPDATE to zakładając, że liczba pozycji nie ulegnie zmianie jest stosunkowo prosty.

Ale tak jak napisałem wcześniej - później o tym jeszcze poczytam.

Panczo napisał(a):

Mam pytanie do tych którzy chcą tworzyć znaczniki na pozycjach i wykonowyać delete/update/insert dla poszczególnych pozycjach. Dlaczego?

Czysto pragmatycznie, na wejściu dostaje dane które musze umieścić w tabeli 1:1 lub zastąpić, jaki jest cel w pisaniu mechanizmów: od frontu zaznaczanie zmiany usunięcia dodania i obsługiwanie tego na backendzie? Kiedy prosty delete i insert załatwia sprawę. Droga inna a cel identyczny.

Wybacz, ale nie jestem pewny co sugerujesz. Czy piszesz o tym, ze delete pozycji faktury ma się wykonać w momencie, gdy user naciśnie "usuń pozycję"? Jeśli tak to to nie wchodzi w grę, bo user może wejść do faktury -> usunąć wszystkie pozycje a później stwierdzić, że się pomylił i chce zamknąć dokument bez jego zapisywania (bez utrwalania zmian). W jaki sposób miałbym przywrócić to co on usunął w trakcie modyfikacji? Są sytuacje, gdzie operacja na bazie powinna być wykonywana od razu (np. próba usunięcia całej faktury), ale są takie, gdzie trzeba czekać na zatwierdzenie usera.

Miang napisał(a):

@Kofcio podstawowe pytanie - robisz projekt dla siebie , na zaliczenie do szkoły, czy może masz kawałek czegoś do zrobienia w ramach projektu w firmie w której pracujesz?
jak to ostatnie to nie kombinuj sam tylko zadaj na piśmie właściwe pytania przełożonym i uzyskaj odpowiedź też na piśmie bo inaczej to będziesz bohaterem następnego nagrania na jutubie jak to słynne z MF, a nasze forum będzie tam przedstawione jako zły duch programisty dający złe porady;)

Projekt robię w całości dla siebie i pod siebie i dla zabawy :), ale chcę to zrobić dobrze. Jak coś z tego wyjdzie to zobaczymy, ale na razie o tym nie myślę. Z zawodu jestem księgowym dlatego dość dobrze wiem jak to ma działać (z biznesowego punktu widzenia), ale inne rzeczy np. takie techniczne muszę sobie poukładać w głowie ;)

Mr.YaHooo napisał(a):

Sam osobiście wolałbym, mieć kilka metod API jak AddInvoiceItem, UpdateInvoiceItem oraz DeleteInvoiceItem niż jedną wielką UpdateInvoiceWithItems Zaś same zmiany zapisywałbym bezpośrednio po zmianie wykonanej przez użytkownika, a nie całość na raz.

To oczywiście kwestia podejścia, czasami lepiej zapisywać zmiany od razu do bazy danych, ale czasami lepszym rozwiązaniem będzie poczekać na zatwierdzenie usera - po niektórych zmian nie można w prosty sposób cofnąć. Ja wychodzę z założenia, że dodanie i usunięcie całego dokumentu powinno być wykonywane ASAP ale UPDATE powinien być wykonanym w momencie zatwierdzenia usera.

Nie zrozumiałeś mnie. Ja proponuję, że na backund idą pozycję zmodyfikowane przez użytkownika i po sprawdzeniu że można dodać, usunięcie obecnych i dodanie tych otrzymanych.

Kofcio napisał(a):

To oczywiście kwestia podejścia, czasami lepiej zapisywać zmiany od razu do bazy danych, ale czasami lepszym rozwiązaniem będzie poczekać na zatwierdzenie usera - po niektórych zmian nie można w prosty sposób cofnąć. Ja wychodzę z założenia, że dodanie i usunięcie całego dokumentu powinno być wykonywane ASAP ale UPDATE powinien być wykonanym w momencie zatwierdzenia usera.

Niestety jeśli się stosuje twardy delete, to już tego przywrócić się nie da. Z innej strony można zastosować soft delete, gdzie oznaczamy rekord jako usunięty i już. Ewentualnie można jeszcze mieć wersjonowanie rekordów. Czyli każdy rekord ma w innej tabeli wszystkie swoje wersje po kolei. Wtedy dałoby się cofnąć każdą zmianę nawet po natychmiastowym zrobieniu delete na rekordzie.

Nie mniej jednak racja. Wszystko zależy od tego jakie mamy założenia. Ja u siebie stosuję natychmiastowy zapis do bazy, bo tak wymagają klienci.

Panczo napisał(a):

Nie zrozumiałeś mnie. Ja proponuję, że na backund idą pozycję zmodyfikowane przez użytkownika i po sprawdzeniu że można dodać, usunięcie obecnych i dodanie tych otrzymanych.

No tak, ale bez znaczników z frontu na backendzie będzie mi ciężko ustalić co zostało dodane/usunięte a co tylko zmienione. Oczywiście można to sprawdzić, ale łatwiej przejść po wszystkich pozycjach i sprawdzić znacznik, który przyszedł z frontu.
Pomijam teraz rozwiązania, które zaproponował @Marcin.Miga.

@Kofcio nadal nie rozumiesz założenia, front zwraca wszystkie pozycje jakie mają być w fakturze po edycji użytkownika. Backend kasuje pozycję w bazie danych i dodaje przekazane pozycję z frontu. Nie ma potrzeby żadnego wskaźnika.na pozycji.

Panczo napisał(a):

@Kofcio nadal nie rozumiesz założenia, front zwraca wszystkie pozycje jakie mają być w fakturze po edycji użytkownika. Backend kasuje pozycję w bazie danych i dodaje przekazane pozycję z frontu. Nie ma potrzeby żadnego wskaźnika.na pozycji.

Okey, czyli Ty mówisz o pierwszym podejściu przeze mnie opisanym w pierwszym poście? :-)
W sumie teraz jak się nad tym zastanawiam to takie rozwiązanie rozwiązuje jeden problem o którym wcześniej nie pomyślałem: istnieje ryzyko, że dwie osoby będą modyfikować ten sam dokument i jedna osoba doda jakąś pozycję i zapisze zmiany. Druga osoba nie będzie miała tej nowej pozycji (bo pobrała obiekt przed tą zmianą) więc prześle na serwer swoje modyfikacje ze statusami, ale bez uwzględnienia tej nowej pozycji wprowadzonej przez pierwszego usera. Ostatecznie, po zapisaniu danych przez drugiego użytkownika dokument będzie miał jedną pozycję więcej...

W sumie to można się przed tym zabezpieczyć - Każda faktura będzie miała swój GUID i po każdej zmianie będzie on zmieniany. Jak user będzie próbował modyfikować fakturę z innym GUID to wywali mu błąd.

Jeżeli przyjmujesz że można edytować dokument jednocześnie przez kilku użytkowników, to ja w takiej sytuacji przyjmuje założenie, że ostatni wygrywa.

Panczo napisał(a):

Jeżeli przyjmujesz że można edytować dokument jednocześnie przez kilku użytkowników, to ja w takiej sytuacji przyjmuje założenie, że ostatni wygrywa.

Tak, zgadzam się, ale pisałem o troszkę innym problemie :)

Panczo napisał(a):

Jeżeli przyjmujesz że można edytować dokument jednocześnie przez kilku użytkowników, to ja w takiej sytuacji przyjmuje założenie, że ostatni wygrywa.

Jeśli kilku userów może JEDNOCZEŚNIE współtworzyć dokument, to ja przyjąłbym, że mogą chcieć to robić po to, by zrobić to szybciej (np. dzielą się pracą i każdy z nich wprowadza po 50 pozycji). W takim układzie proponowane rozwiązanie typu "wywal wszystko, dodaj od nowa" rozsypie pracę jednego z nich. A wówczas po co w ogóle dopuszczać współtworzenie jednoczesne dokumentu?

Jeśli chcemy, aby użytkownik "lokalnie" edytował dokument, a na koniec zapisywał całość i miał pewność, że nikt mu nic nie zmieni w międzyczasie, to na czas edycji dokument powinien być blokowany / oznaczany jako "tylko do odczytu" dla innych userów. Inaczej taka praca będzie rodzić frustrację i prowadzić do niezgodności ze stanem faktycznym.

Żeby nie było - problem, o którym rozmawiamy (współtworzenie dokumentu), nie jest trywialny. W wielu systemach jest on różnie rozwiązywany, a wiele ze stosowanych rozwiązań nastręcza trudności użytkownikom i projektantom softu.

Nie, nie, mogą jednocześnie edytować <> współtworzyć. Ostatni wygrywa. Można dodadać mechanizm blokowania dokumentu edytowanego, kwestia rozwiązania jakie się przyjmie.

Panczo napisał(a):

Nie, nie, mogą jednocześnie edytować <> współtworzyć. Ostatni wygrywa. Można dodadać mechanizm blokowania dokumentu edytowanego, kwestia rozwiązania jakie się przyjmie.

Ale wiesz, że są systemy, które umożliwiają jednoczesną edycję dokumentów w określonym zakresie (na ten przykład jednoczesne dodawanie różnych pozycji do jednego dokumentu przez kilku użytkowników)? I nic tam nie ginie, nikt tam nie "wygrywa". Ja dodaję / edytuję swoje pozycje, Ty swoje, a w efekcie w dokumencie są wszystkie.

Są też klienci, którzy wymagają tej funkcjonalności od systemu, który zamierzają kupić (bo tak mają zorganizowaną pracę w swoim zakładzie).

Wiem, ale cały wątek jest o zapisaniu zmienionego dokumentu, a nie jego współtworzeniu.