Temat: Ograniczenie ilości wprowadzanych danych do tabeli.

Witam,

W skrócie, projektuje sobie małą bazę danych (MySQL) do obsługi pacjentów w klinice. Problem jaki napotkałem jest następujący. Mam dwie tabele, w pierwszej roboczo nazwanej dyżur mam atrybuty id_dyżuru i limit_pacjentów (pomijam resztę atrybutów nie biorących udziału w relacji). W drugiej o nazwie zapis_na_dyżur mam id_dyżuru i id_pacjenta. W tab. dyżur chcę ustalić limit_pacjentów dla danego id_dyżuru np. 10. Chciałbym aby to ograniczenie dotyczyło ilości wystąpień id_dyżurów w tabeli zapis_na_dyżur. Zastanawiam się czy jest możliwe/sensowne robić to na poziomie bazy danych i czy nie lepiej byłoby przerzucić to na warstwę aplikacyjną.

Drugie pytanie, po części związane z tematem. Czy istnieje jakaś instrukcja, która zablokuje możliwość wykonywania INSERT na tabeli. Np. chciałbym mieć BEFORE INSERT TRIGGER, który przy osiągnięciu przez parametr wartości granicznej uniemożliwi wykonanie wcześniej wspomnianej instrukcji?Przemysław Trzaska edytował(a) ten post dnia 28.12.12 o godzinie 13:11

Temat: Ograniczenie ilości wprowadzanych danych do tabeli.

Jeżeli dwie instancje zaczną dodawać w tym samym momencie? Ja bym zrobił lockowanie dyżuru. Jak dużo operacji optymistycznie wypada lepiej, ale wtedy na koniec dodawania może się posypać. Pesymistyczne bardziej będzie obciążać bazę. No i pewnie jakiś timeout warto by obsłużyć.
To jakaś nowa nisza dla stoczni? Tak tylko się czepiam - przepraszam :)Michał Z. edytował(a) ten post dnia 28.12.12 o godzinie 14:21

Temat: Ograniczenie ilości wprowadzanych danych do tabeli.

Michał Z.:
To jakaś nowa nisza dla stoczni? Tak tylko się czepiam - przepraszam :)

Hehe niekoniecznie. Może w przyszłości. Aktualnie jest to projekt na uczelnie.

Temat: Ograniczenie ilości wprowadzanych danych do tabeli.

W sumie to kwestia czy chcesz pozwolić osobie zapisującej się na dyżur dokonać akcji zapisu przed sprawdzeniem czy można czy po. Kwestia wielkości aplikacji. Ja na twoim miejscu sprawdzałbym możliwość zapisu przed wyświetleniem przycisku z akcją zapisu na dyżur. Przycisk wyświetlałbym tylko wtedy kiedy jest możliwość zapisu.

Temat: Ograniczenie ilości wprowadzanych danych do tabeli.

a ja zaproponuję funkcję ( na poziomie samej bazy ) która przed zapisem do bazy sprawdzi czy ilość dostępnych dyzurów jest > 0 . A następnie w if możesz wrzuć inserta. Dodatkowo możesz zrobić z poziomu aplikacji proste zapytanie i sterować wyswietlaniem buttona "dodaj" - czyli to co napisał przedmówca Marcin.
Jak na uczelnię projekt to zabłyśniesz:) tym rozwiązaniem.

Temat: Ograniczenie ilości wprowadzanych danych do tabeli.

Załóżmy, że ten wspaniały system jest zrobiony porządnie - czyli innodb i read-commited. Jeżeli do limitu brakuje 1 pacjenta, a na raz będzie dodawanych np. 2 kolejnych. To ci dwaj nie będą o sobie nawzajem wiedzieć. Nie ma znaczenia kto i jak to będzie sprawdzać. Rozwiązaniem jest blokowanie zasobów. Albo ordynarny lock / select for update, albo blokowanie optymistyczne. W drugim przypadku, jak jeden będzie zmieniać dane, drugi poczeka, bo tak działa baza danych. Istotne jest to, że ten drugi dowie się, że dane się zmieniły w między czasie. I to jest właściwe rozwiązanie - moim skromnym zdaniem, oczywiście.
Jeżeli to jest dirty-read - różnica jest taka, że czas się skraca, ale to nie jest rozwiązanie problemu. Spada prawdopodobieństwo, ale - jak che się błysnąć na zaliczeniu... Prawdopodobieństwo, że zadziała to trochę mało. W realu wychodzą błędy, których znalezienie jest bardzo trudne. Raz na jakiś czas, system działa błędnie... Debug nic nie pokazuje, a błędy są. :(

Temat: Ograniczenie ilości wprowadzanych danych do tabeli.

Marcin Zimoląg edytował(a) ten post dnia 04.01.13 o godzinie 07:18

Temat: Ograniczenie ilości wprowadzanych danych do tabeli.

Marcin Zimoląg:
Funkcję zaczynasz rozpoczęciem transakcji (to zapewni ci dostęp tylko z jednego wątka do procedury a tym samym tabeli, czyli inna instancja Ci nie wrzuci rekordu),

Serio to tak działa?

Temat: Ograniczenie ilości wprowadzanych danych do tabeli.

Szymon G.:

Marcin Zimoląg:
Funkcję zaczynasz rozpoczęciem transakcji (to zapewni ci dostęp tylko z jednego wątka do procedury a tym samym tabeli, czyli inna instancja Ci nie wrzuci rekordu),

Serio to tak działa?

No i się dowiedziałem dlaczego używam Postgresa :D

Z innej beczki. Jak bym był programistą i projektant zaproponowałby rozwiązanie, żeby kilka razy to samo sprawdzać, najlepiej na kilku poziomach... W prostych, żołnierskich słowach wyjaśniłbym, że to zły pomysł.

Trzeci raz, teraz z linkiem http://en.wikipedia.org/wiki/Optimistic_concurrency_co... Jest link do czegoś, co nazywa się ADO.NET Entity Framework... Jak coś ma rozwiązanie, które działa - nie ma co wymyślać. Wystarczy użyć.

Temat: Ograniczenie ilości wprowadzanych danych do tabeli.

Dziękuje wszystkim za cenne porady. Sporo nowej wiedzy, którą muszę ogarnąć i wdrożyć w projekt.

Temat: Ograniczenie ilości wprowadzanych danych do tabeli.

Witam bardzo serdecznie :)

tak poczytałem i się zastanawiam czy nie lepiej by było wprowadzić rozwiązanie którego ja używam w swojej aplikacji... może nie dotyczy ona lekarzy i chorych tylko ślusarzy i usterek ale idea jest chyba podobna...
W moim rozwiązaniu mam 8 miejsc z których może nawet równocześnie spłynąć zgłoszenie awarii... i tylko 2 lub 3 ludzi którzy mogą się zająć tymi awariami w danej chwili. Zasadniczo chyba widać analogię do systemu rejestracji pacjentów na dyżury lekarzy...
Otóż wszystkie zgłoszenia są zapisywane w tabeli zleceń (tak samo jak zlecenia napraw warsztatowych zlecanych przez kierownika) po czym są rozdzielane do konkretnych pracowników przez logikę aplikacji (dodam tylko że tutaj można w profilu danego pracownika umieścić jego umiejętności bądź zakres obowiązków), nie ma żadnego ograniczenia co do liczby przyjętych zgłoszeń (bo to moim zdaniem troszkę bez sensu) natomiast pojawia się ostrzeżenie dla kierownika że występuje tak dużo zleceń że system proponuje przesunięcie jeszcze jednego pracownika do usuwania awarii.
Może takie podejście będzie bardziej pasować do twojego rozwiązania ?

Temat: Ograniczenie ilości wprowadzanych danych do tabeli.

Jest to sensowne rozwiązanie. U mnie to jest kwestia hipotetycznych założeń, niemających odzwierciedlenia w rzeczywistości. Z racji tego, że jest to projekt na uczelnie moje założenia mogą być dowolne. No więc ja przyjąłem, że każdy lekarz będzie określał swoje dyżury z jakimś tam wyprzedzeniem i będzie określał limit pacjentów jakich może przyjąć na danym dyżurze. I całe zamieszanie jest właśnie o kontrolę tego limitu. Po głębszych przemyśleniach jestem przekonany, że warto to przerzucić na warstwę aplikacji.

Temat: Ograniczenie ilości wprowadzanych danych do tabeli.

Tomasz Anciński:
Witam bardzo serdecznie :)

tak poczytałem i się zastanawiam czy nie lepiej by było wprowadzić rozwiązanie którego ja używam w swojej aplikacji... może nie dotyczy ona lekarzy i chorych tylko ślusarzy i usterek ale idea jest chyba podobna...
W moim rozwiązaniu mam 8 miejsc z których może nawet równocześnie spłynąć zgłoszenie awarii... i tylko 2 lub 3 ludzi którzy mogą się zająć tymi awariami w danej chwili. Zasadniczo chyba widać analogię do systemu rejestracji pacjentów na dyżury lekarzy...
Otóż wszystkie zgłoszenia są zapisywane w tabeli zleceń (tak samo jak zlecenia napraw warsztatowych zlecanych przez kierownika) po czym są rozdzielane do konkretnych pracowników przez logikę aplikacji (dodam tylko że tutaj można w profilu danego pracownika umieścić jego umiejętności bądź zakres obowiązków), nie ma żadnego ograniczenia co do liczby przyjętych zgłoszeń (bo to moim zdaniem troszkę bez sensu) natomiast pojawia się ostrzeżenie dla kierownika że występuje tak dużo zleceń że system proponuje przesunięcie jeszcze jednego pracownika do usuwania awarii.
Może takie podejście będzie bardziej pasować do twojego rozwiązania ?

Bardzo fajne rozwiązanie - to z tym przesuwaniem pracownika.
A nie masz jakiegoś limitu na tych zasobach?? Klonowanie pracowników legalne jeszcze nie jest... chyba, że coś przespałem. Z próżnego i Salomon nie naleje (chociaż u mnie w firmie niektóry się wydaje, że to potrafią ;-))

Temat: Ograniczenie ilości wprowadzanych danych do tabeli.

Przemysław Trzaska:
Jest to sensowne rozwiązanie. U mnie to jest kwestia hipotetycznych założeń, niemających odzwierciedlenia w rzeczywistości. Z racji tego, że jest to projekt na uczelnie moje założenia mogą być dowolne. No więc ja przyjąłem, że każdy lekarz będzie określał swoje dyżury z jakimś tam wyprzedzeniem i będzie określał limit pacjentów jakich może przyjąć na danym dyżurze. I całe zamieszanie jest właśnie o kontrolę tego limitu. Po głębszych przemyśleniach jestem przekonany, że warto to przerzucić na warstwę aplikacji.

Przerzuć to tam gdzie jest Ci najłatwiej nad tym zapanować. Jeżeli klient (bezpieka) nie wymaga testowania wartości na wszystkich warstwach lub na określonej - masz to dowolne - nie komplikuj.
Więcej kodu - więcej potencjalnych błędów. Większe wymagania - większe koszty, pamiętaj, że zawsze ktoś to musi utrzymywać - jeżeli klient nie zaplanował, może nie potrzebuje, a jak nie potrzebuje - to na pewno nie będzie chciał zapłacić. Zawsze warto jednak zapytać - od tego jest analiza wymagań - czyli w tym przypadku możesz się prowadzącego przedmiot zapytać - jakie są wymagania na oczekiwaną przez Ciebie ocenę.

Temat: Ograniczenie ilości wprowadzanych danych do tabeli.

Marcin G.:
Klonowanie pracowników legalne jeszcze nie jest... chyba, że coś przespałem. Z próżnego i Salomon nie naleje (chociaż u mnie w firmie niektóry się wydaje, że to potrafią ;-))

U nas robią to codziennie :))

W najbardziej pesymistycznym założeniu... system rozkłada ręce...

Wracając do tematu, to teoria zbiorów mówi że element należy do zbioru wtedy gdy zbiór jest dziedziną elementu. Teoretycznie w matematyce możesz sobie określić że dany typ np.cyfry składa się z określonej ilości składników(0,1,2,3,4,5,6,7,8,9) i wtedy by pasowało bo np.10 ani B nie należy do dziedziny zbioru i tworzymy naturalne ograniczenie.
Tak samo jest ze wszystkimi rodzajami zmiennych jakich używamy w językach programowania (int nie kończy się w nieskończoności tylko troszkę bliżej).
W SQL'u dostajemy w wynikach zbiory... tak więc trzeba by określić nowy typ zmiennej aby coś ponad nie zapisywało się w tablicy...
Ogólnie bez sensu...
Możesz testować wartość licznika krotek przed zapisem nowej ale zaczynają się pojawiać schody związane z możliwością wystąpienia jednoczesnych prób zapisu, trzeba by bawić się w transakcje.
Myślę że nie trzeba sobie aż tak komplikować życia.

Jeżeli przeniesiesz część logiki do aplikacji to po tak prostym zabiegu, jak utworzenie procedury składowej która liczy wiersze i w zależności od wyniku zapisuje bądź zwraca błąd (try catch) możesz w prosty sposób osiągnąć cel.

Jeszcze jedno... jeżeli ograniczysz ilość krotek w tabeli to co, mam rozumieć że dla każdego lekarza nowa tabela czy co ? Co z tabelą po dyżurze ??

Pewnie będziesz wszystkich pacjentów zapisanych na dyżur umieszczał w tabeli i sortował po id lekarza... Czyli całe rozważania są mniej więcej tak samo owocne jak te o wyższości świąt bożego narodzenia nad świętami wielkiej nocy...

Na twoim miejscu w każdym projekcie trzymał bym się realnych założeń, może się później bardzo przydać...

Temat: Ograniczenie ilości wprowadzanych danych do tabeli.

Przemysław Trzaska:
Jest to sensowne rozwiązanie. U mnie to jest kwestia hipotetycznych założeń, niemających odzwierciedlenia w rzeczywistości. Z racji tego, że jest to projekt na uczelnie moje założenia mogą być dowolne. No więc ja przyjąłem, że każdy lekarz będzie określał swoje dyżury

To jest poprawne założenie. Planuje się - tak jak Twój czas pracy też jest zaplanowany z wyprzedzeniem.

z jakimś tam wyprzedzeniem i będzie określał limit pacjentów jakich może przyjąć na danym dyżurze.

Normalnie już Ciebie nie lubię. A moje dziecko z gorączką to będzie czekało aż się zrobi okienko ??
Tak jest teraz, dzwonię we czwartek po południu a pani mi mówi, że mnie na następną środę może dopiero zapisać... a dziecko 39,5.
Teraz wiem czyja to wina :-p
A poważnie, to powinien być jakiś tam limit, ewentualnie przypominajka - ale soft (miękka) jak już...
a nie blokada na inserty (ja bym zrobił procedurą (i zmieniał ewentualnie kolor rekordu, żeby uświadomić doktorowi, pielęgniarce, że przekroczył limit) - zmiana statusu)
Trzeba być elastycznym :-) (procedura może być na bazie ale może to być też kawałek kodu w aplikacji).

I całe zamieszanie jest właśnie o

kontrolę tego limitu. Po głębszych przemyśleniach jestem przekonany, że warto to przerzucić na warstwę aplikacji.

Wybór należy do Ciebie.

Temat: Ograniczenie ilości wprowadzanych danych do tabeli.

Tomasz Anciński:

Marcin G.:
Klonowanie pracowników legalne jeszcze nie jest... chyba, że coś przespałem. Z próżnego i Salomon nie naleje (chociaż u mnie w firmie niektóry się wydaje, że to potrafią ;-))

U nas robią to codziennie :))

W najbardziej pesymistycznym założeniu... system rozkłada ręce...

U nas w takim przypadku dostaje się pisemne polecenie wykonania ;-)

Jeżeli przeniesiesz część logiki do aplikacji to po tak prostym zabiegu, jak utworzenie procedury składowej która liczy wiersze i w zależności od wyniku zapisuje bądź zwraca błąd (try catch) możesz w prosty sposób osiągnąć cel.

try catch nie służy do obsługi logiki... :-p
chociaż jest do tego nagminnie używane :-p

Jeszcze jedno... jeżeli ograniczysz ilość krotek w tabeli

Bo kolega chciał pewnie co innego osiągnąć z ww. wynika, że ograniczenie wpisów na dany dyżur

to co, mam rozumieć że dla każdego lekarza nowa tabela czy co ? Co z tabelą po dyżurze ??

poza tym każdy lekarz może mieć inną liczbę godzin dyżuru w ogóle, inną danego dnia, inaczej dyżur konsumują różne przypadki (wypisanie recepty, badanie, wypisanie skierowania, ww. cały pakiecik łącznie i inne), ktoś może nie przyjść, zjawią się 4 inne osoby z przypadkami wymagającymi zajęcia się, a co jak lekarza nie ma - trzeba pacjentów obsłużyć ??

encja personel (umawia/sprawdza terminy wizyt)
encja pacjenci (zawiera dane podstawowe o pacjentach)
encja lekarze (rozszerza personel, dodaje rozpoznanie, przegląda historię choroby, historię przepisane lekarstwa)
encja dyżury_grafiki (plan dyżurów - pewnie kadry ustalają)
encja dyżury_przyjęcia (co się faktycznie na dyżurach działo)
i tak jeszcze można dużo i dużo... ale z sensem...

Pewnie będziesz wszystkich pacjentów zapisanych na dyżur umieszczał w tabeli i sortował po id lekarza... Czyli całe rozważania są mniej więcej tak samo owocne jak te o wyższości świąt bożego narodzenia nad świętami wielkiej nocy...

rozważania są, ale teoria sobie a życie sobie...
jak chcesz błysnąć... to lepiej pomyśl o szyfrowaniu danych i to sprzedaj jako wartość szczególną...
bo to są wszystko dane wrażliwe (czyli grząski temat)

Na twoim miejscu w każdym projekcie trzymał bym się realnych założeń, może się później bardzo przydać...

popieram, najlepiej wizytę referencyjną sobie zrób jak masz gdzie i popatrz jak to działa od środka oraz jak można tym ludziom życie ułatwić
:-))

Temat: Ograniczenie ilości wprowadzanych danych do tabeli.

Marcin G.:
Normalnie już Ciebie nie lubię. A moje dziecko z gorączką to będzie czekało aż się zrobi okienko ??
Tak jest teraz, dzwonię we czwartek po południu a pani mi mówi, że mnie na następną środę może dopiero zapisać... a dziecko 39,5.
Teraz wiem czyja to wina :-p

Ja tylko staram się możliwie najlepiej odzwierciedlić otaczającą nas rzeczywistość :) . Jakby system, pod który tworzę tę bazę miał mieć wykorzystanie w konkretnych realiach sądzę, że byłby duży nacisk na optymalizacje i rozbudowę procesu rejestracji. Tymczasem ja mogę sobie pozwolić na jego uproszczenie.

A poważnie, to powinien być jakiś tam limit, ewentualnie przypominajka - ale soft (miękka) jak już...
a nie blokada na inserty (ja bym zrobił procedurą (i zmieniał ewentualnie kolor rekordu, żeby uświadomić doktorowi, pielęgniarce, że przekroczył limit) - zmiana statusu)

Dokładnie tak to będzie rozwiązane. W założeniu pacjent ma też możliwość rejestracji online ale wówczas myślę, że też obejdzie się na "wyszarzeniu guzika".