MVC, EF, Procedura w bazie

Witajcie

jeśli zły dział to proszę o przesunięcie wątku.

Mam prośbę o Waszą opinię, mam tabelę w bazie:

Kategoria_Id Nazwa_Kategorii Pozycja_Menu
1 jeden 1
2 dwa 2
3 trzy 3
4 cztery 4
5 pięć 5

powyższy przykład dotyczy dynamicznego menu, kolumna "Pozycja_Menu" określa kolejność wyświetlania kategorii na stronie. Teraz chcę usunąć jeden z wierszy dla przykładu 3 i w kolumnie "Pozycja_Menu" powstanie dziura i pytanie jak to zrobić

1. w kontrolerze MVC usuwam wybrany wiersz plus aktualizuję kolumnę "Pozycja_Menu"
2. piszę procedurę w bazie, która usuwa wiersz i aktualizuję kolumnę
3. inne, jak?

Dzięki

Zamiast Pozycja_Menu powinieneś mieć kolumnę oznaczającą priorytet - i zamiast wartości 1,2,3,4... wrzucić 10,20,30,40 - dzięki temu w przyszłości możesz wstawić w środek bez konieczności zmiany pozostałych wartości. Przy budowaniu menu po prostu sortuj po tej wartości, skąd pomysł, że pozycje muszą być ponumerowane od 1 wzwyż bez żadnych przerw?

Hrypa napisał(a):

Zamiast Pozycja_Menu powinieneś mieć kolumnę oznaczającą priorytet - i zamiast wartości 1,2,3,4... wrzucić 10,20,30,40 - dzięki temu w przyszłości możesz wstawić w środek bez konieczności zmiany pozostałych wartości. Przy budowaniu menu po prostu sortuj po tej wartości, skąd pomysł, że pozycje muszą być ponumerowane od 1 wzwyż bez żadnych przerw?

zapomniałem jedną rzecz napisać, dość istotną a mianowicie chcę dodać możliwość przesuwania pozycji menu w górę, w dół
numerowanie od 1 wzwyż ma ułatwić sprawę, z dziesiątkami może być ciężko po kilku dodawaniach, usuwaniach, przesuwaniach

A jakie to ma znaczenie? Przeciez zeby zamienic dwie pozycje miejscami nie musisz wcale dodawac i odejmowac 1. Wystarczy zamienic ich wartosci w kolumnie z kolejnoscia - co za roznica czy zamieniasz 2<->3 czy 20<->30?

anonymous13 napisał(a):

A jakie to ma znaczenie? Przeciez zeby zamienic dwie pozycje miejscami nie musisz wcale dodawac i odejmowac 1. Wystarczy zamienic ich wartosci w kolumnie z kolejnoscia - co za roznica czy zamieniasz 2<->3 czy 20<->30?

mam pozycje 10, 20, 30, 40
w międzyczasie chcę dodać pozycję, która ma być pierwsza wg @Hrypa czyli np 5, 10, 20, 30, 40
nie ruszyłem struktury pozycji
teraz chcę mieć poz 20 zamiast 5 i 40 zamiast 10, manipulacja za pomocą formularza owszem skrypt można napisać, ale jak zaczniemy dodawać kolejne pozycje które będą numerowane 21, 26, itd. bo nagle między 20 a 30 chcemy mieć dodatkowe pozycje. Nieważne.

Bardziej zależy mi na odpowiedzi na moje pytania.

No dobrze, skoro tak koniecznie chcesz... Wybrałbym opcję 1. Tyle że oczywiście nie robisz tego bezpośrednio w kontrolerze - tam wywołujesz tylko metodę serwisu, który korzystając z odpowiedniego repozytorium wykonuje zmianę na bazie.

dzięki @Hrypa

Jak duża będzie ta lista(rząd wielkości)?
Czy pozycje można przesuwać tylko o jedno miejsce w górę/dół, czy dowolnie, np. z 6 na 2?
Lista jedno/dwukierunkowa pozwala na zmianę kolejności, przy zmianie max 3/5 elementów.
Dodanie nowej pozycji na końcu to 1 insert i zmiana 1 elementu(ostatniego).
Dodanie w dowolnym punkcie do 1 insert i zmiana max 1/2 elementów.
Usunięcie to zmiana 1/2 elementów i 1 delete.

Czy [10, 20, 30, ...] albo [100, 200, 300, ...], to nie jest tylko odsunięcie problemu o kolejne rzędy wielkości? Wstawienie elementu między 4 a 5, to dokładnie taki sam problem jak wstawienie między 21 a 22, albo 221 a 222. Co jeśli w dodatku już istnieje 23, 24, 25 albo 223, 224 i 225?
1 insert/1 update to wartości dla najbardziej optymistycznych przypadków, a te będą tym rzadsze, im więcej będziemy mieć danych.
Lista nie ma pola oznaczającego kolejność - te (jeśli konieczne) jest wyliczane na podstawie jej aktualnego stanu.

moim zamierzeniem jest stworzenie dynamicznego menu np. do e-sklepu, za pomocą formularza wprowadzam kategorię, mam następny formularz do edycji tego menu np.

• kasuję kategorię
• dodaję nowe kategorie ( w dodawaniu dla kolumny "Pozycja_Menu" jest stworzony wyzwalacz w bazie, który z automatu wstawia max liczbę)
• zmieniam nazwy kategorii
• przesuwam kategorie w górę lub w dół (za pomocą przycisków), czyli zapewne będzie to o 1 "piętro"

numeracja "pozycji_menu" jest dla mnie nieistotna (to nie jest kosmiczne wymaganie), tylko aby działało po dłuższym manipulowaniu (dodawaniu, kasowaniu kategorii) danymi menu i po jakimś czasie jak będę chciał rozszerzyć menu o subkategorie.

Procedura w bazie idealnie załatwia sprawę, nawet z numerowaniem od 1 do wzwyż. Tylko czy tak można robić?

to nie lepiej tak: http://en.wikipedia.org/wiki/Nested_set_model

Panowie jeszcze raz wielkie dzięki nad sposobem numeracji. Popatrzę, poczytam.
Ważniejsza teraz jest dla mnie kwestia rozwiązania problemu, w którym to usuwam jakiś rekord z bazy i zarazem muszę aktualizować inny lub inne rekordy. I co jest efektywniejsze, lepsze, poprawniejsze EF (cały kod w MVC) czy procedura w bazie i wywołanie procedury przez EF?

Kiedy usuwasz rekord z bazy to wcale nie musisz sie przejmowac aktualizowaniem innych pozycji bo dziury w numeracji w niczym nie przeszkadzaja co rozni ludzie starali sie wytlumaczyc przez cala pierwsza strone tego watku. Jesli bedziesz dodawal nowe elementy zawsze na koncu menu i przesuwal je zawsze o jedna pozycje w gore/dol to rowniez nie musisz przejmowac sie dziurami. Jedynie kiedy bedziesz chcial wstawiac nowy element pomiedzy dwa inne (lub przesunac istniejacy elelement o wiele pozycji na raz) musisz uwazac na dziury i aktualizowac wiecej niz maksymalnie 2 elementy.

Odpowiadajac na twoje pytanie - to ktore rozwiazanie jest lepsze/efektywniejsze zalezy od tego jakie ograniczenia nakladasz na architekture swojej aplikacji. Obecnie dosc popularne jest podejscie, w ktorym baze danych traktuje sie tylko i wylacznie jako kontener na dane natomiast cala logika manipulacji tymi danymi jest zawarta w kodzie aplikacji. Przy takim podejsciu jedyne slusze rozwiazanie to zrobienie tego w kodzie aplikacji (w twoim przypadku EF/MVC). Pozwala to na dosc latwe testowanie aplikacji i oddzielenie warstwy logiki od warstwy dostepu do danych. Z drugiej strony procedura skladowana na pewno bedzie lepsza pod wzgledem wydajnosci (np. brak narzutu na przeslanie danych db<->C#) ale trudniej ja przetestowac i masz rozrzucona logike w roznych miejscach.

To ktore podejscie wybierzesz zalezy tylko i wylacznie od Ciebie i od tego co jest dla Ciebie wazniejsze.

a już zwątpiłem, że ktokolwiek udzieli mi takiej odpowiedzi. O taką odpowiedź mi chodziło.
Co do dziur to nie będę się już upierał, potestuję, zobaczę i jeśli wszystko będzie działać to zostawię.