Witam,
przymierzam się do napisania systemu elektronicznego obiegu dokumentów w firmie, w której pracuję, ktoś na forum pisał o podobnym projekcie, ale nie mogę go znaleźć. Pytanie moje brzmi:
W jaki sposób zrobić historię zmian w dokumencie? - tzn. czy zapisywać go np. 3 razy w bazie, czy może jest jakaś inna metoda? I czy MySQL do tego wystarczy? czy lepiej bazę zrobić np. w Microsoftowym SQL Serwer?
Będę wdzięczny za wszelkie sugestie
Pozdrawiam
na pewno nie nadaje się do tego wersja darmowa komercyjnej bazy, która ma ograniczenie na rozmiar bazy. Będziesz w bazie składował dokumenty, one trochę jednak ważą, szczególnie, że chcesz mieć historię zmian. MySQL też się tak sobie nadaje do takich rzeczy. Jeśli już to albo rozwiązanie komercyjne (trzeba płacić) albo darmowe ale bez ograniczeń. Może PostgrSQL np.
Co do samego sposobu trzymania różnic to są dwie opcje - albo trzymasz każdą wersję albo całą masz tylko pierwszą i ostatnią (ostatnią, żeby dostęp do niej był szybki) a z wersji pomiędzy trzymasz tylko różnicę - ale to już jest trudniejsze i trzeba to dobrze zrobić bo jak się gdzieś sypniesz to stracisz wersje "pomiędzy"
Jesli chcesz robic obieg dokumentow to zacznij od zaprojektowania tabel.
Ogolnie proces polega na przesylaniu wersji pewnego dokumentu miedzy kolejnymi osobami w firmie np:
do firmy przychodzi faktura, ktos generuje jej wersje elektroniczna i przesyla dalej, pozniej generowane sa np rozrachunki i polecenia ksiegowania i rozsylane do poszczegolnych dzialow.
Ostatecznie dokument moze trafiac do np prezesa.
Czyli masz tutaj kilka problemow:
a) przechowywanie dokumentu
b) sciezka mozliwych przekierowan
c) uprawniena.
ja bym zaczal od tabeli z dokumentem - powinna to byc tabela czysto opisowa (bez danych dokumentu). Typowy opis bytu jakim jest dokument (np nazwa, kto utworzyl, data utworzenia, dodatkowe informacje).
Pozniej tabela przekierowan dokumentu (i wlasnie tutaj trzymalbym wersje - pole typu image).
Wersja dokumentu zmienia sie w momencie przesylania go dalej (np ktos go akceptuje, zatwierdza itp).
Dodatkowo powiniennes zadbac o uprawnienia do podgladu (np prezes moze zobaczyc dokument w kazdym kroku, osoba tworzaca np tylo aktualny status i swoje zmiany)
Co do bazy to polecam MSSQL i najlepiej 2008
Dzięki za wszystkie uwagi. Właśnie próbuję stworzyć sensowny schemat bazy danych.
Crowa faktycznie jeżeli chodzi o dokumenty z zewnątrz to najrozsądniej trzymać je np. jako Image, ale czy dla dokumentów tylko wewnętrznych firmy (zgłoszenia usterek, złożenie zapotrzebowania na materiały elsploatacyjne) nie wystarczy zwykłe pole tekastowe? Wtedy mam ułatwione nanoszenie zmian (poprawek) - bo tak to musiałbym na nowo generować Image dla każdej zmiany i zapisywać do bazy.
Co do przekierowań dokumentu to myślę żeby stworzyć tablę ze wszystkiemi działami w firmie i przy przekazywaniu dokumenty zaciągać z niej do kogo ma być wysłany dokument? i zapisywać to w tabeli z dokumentem (jak radzi Crowa) Potem wyciągać selectem "do kogo" jest adresowany i na podstawie tego wyświetlać go w odpowiednich działach.
Jeszcze raz dzięki za uwagi
Zabieracie sie panowie do tego wszystkiego od d**y strony (przepraszam, jesli ktos sie poczul urazony).
Nie pisze sie systemu od technologii, a od opisania procesow biznesowych.
Zdefiniowania co sie dzieje w firmie, co sie dziac moze (w przyszlosci)
Zdefiniowania uczestnikow procesów (jakie działy, jakie osoby)
Rozpisania powiązań włęzłów procesów i powiązania uczestników w logiczną całość.
Kiedy powstaną punkty - okreslamy jakie dokumenty pojawiają się na każdym z nich i jaki zakres danych wprowadzany jest na poszczegolnych wezlach. Co wchodzi - co wychodzi.
Dokumenty typowo logistyczne (Magazynówka, Zamówienia, Produkcja, itp.) mają to do siebie, ze wynikają z siebie i oddziaływują jedne na drugie.
Zmierzam do tego, ze trzeba zrozumieć jak funkcjonuje firma od strony analogowej, a pozniej zrobic po prostu cyfrowy model, uogulniając tam gdzie się da.
System bazodanowy nie ma tutaj żadnego znaczenia - w przypadku MS SQL - system sprawdzi sie do 5 użytkowników i bazy (albo 1 albo 4 GB - nie pamietam teraz, ale to też się zmienia w zaleznosci czy mowa o 2000, 2005 czy 2008). Ograniczenie to jednak dotyczy jedynie motoru bazy danych, a nie bazy jako takiej - jeżeli użytkowników będzie więcej - kupisz licencje na SQL Server i już.
Co do MySQL - ja swoj system na razie opieram o niego, bo ma sympatyczny dialekt - to znaczy nie wali usera po łbie kiedy chce wykonać dziwną operację z punktu widzenia języka SQL, ale logiczną z punktu widzenia projektanta - np: żaden system poza MySQL nie pozwala pokazac pola, które nie jest ujęte w klauzuli GROUP BY. Owszem - trzeba mieć świadomość, że pokaże przypadkową wartość (pierwszą lub ostatnią z zakresu), ale jednak. Jedkakże - ja właśnie jestem na etapie przenoszenia logiki aplikacji do bazy danych (Aplikacja powoli staje sie tylko cienkim klientem) i coraz bardziej uwierają mnie dziwne ograniczenia MySQLa (nie potrafię teraz przytoczyć ale mialem niedawno jakiś problem i szlag mnie trafial na MySQLa.)
MS SQL ma najbardziej rozbudowany dialekt i przyznaje, że najfajniej pracuje mi sie właśnie z tym motorem i rozszerzeniami zrobionymi przez Microsoft.
Z musu używam PostgreSQL, który ma bardzo restrykcyjny dialekt SQL, ale tez ma rzutowanie typów, któych nie ma w MySQLu. System uprawnien jest tez sensowniej rozwiazany niz w MySQL (w MySQL nigdy do końca nie mam pewności, kto ma jakie uprawnienia do poszczegolnych obiektow). Inna sprawa, ze powoli przekonuje sie sie do postgresa, ale czy oparlbym swoj system o niego ... raczej nie. Za bardzo irytuje mnie restrykcyjnosc dialektu.
Używałem też Firebirda i przyznam, że czuje do niego sentyment ze względu na jedno narzędzie, któego kiedyś używałem, a które pozwalało debuggować procedury wbudowane tak jak sie to robi w Delphi (krok po kroku). Niby Toad dla MySQLa ma tez cos takiego, ale nie udalo mi sie tego odpalic.
Osobiscie, gdybym startował z aktualna wiedza od zera - zdecydowalbym sie na MS SQLa (mimo, ze jest platny).
Okej - ale co do samego systemu.
Jądro systemu powinno się operac o dwie banalne tabele: Nagłówek i szczegoly. Tabele te powinny zawierac zbior odnosnikow do tabel slownikowych - to znaczy. nie wpisujesz bezposrednio danych kontrahenta do tabeli naglowka, tylko identyfikator do tabeli slownika kontrahentow. Tabela szczegolow nie zawiera danych nt opisu towaru, a tylko odnosnik do kartoteki materialowej. Przy wyciaganiu joinujesz sie do odpowiednich tabel i wyciagasz dokaldnie tyle ile ci potrzeba (w zaleznosci od miejsca w syetemie mozesz dla danego dokumentu potrzebowac wyciagnac 9 lub 90 pol)
Co do historii - widzialem rozwiazanie, gdzie tabele glowne zawieraja ostatnia wersje, a tabela pomocnicza _HISTORY zawiera wszystkie poprzednie wersje (historia tworzy sie automatycznie za pomoca triggerow).
Ogolnie temat rzeka i moznaby pisac o najlepszych praktykach. Jednakze - bez zrozumienia jak dziala dany biznes ciezko bedzie zaprojektowac cos, co po roku uzywania nie okaze sie proteza do protezy podpieranej proteza. Miałem taki epizod i sprawia wielkie problemy w utrzymaniu.