ngodb
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [ngodb] Co teraz robić?


From: Radoslaw Janeczko
Subject: Re: [ngodb] Co teraz robić?
Date: Wed, 23 Feb 2005 10:14:45 +0100
User-agent: Mozilla Thunderbird 1.0 (X11/20041227)

By the day 02/23/2005 09:10 AM, fellow named Piotr Szmigielski wrote:
Osobiście nie mam nic przeciwko temu, by wybrać najlepsze narzędzie
do rozwiązania danego problemu, jednak mam pytanie: 1. cóż ta aplikacja miałaby robić?? 2. jakie danye mają być przechowywane?

Skoro ma to być coś bardziej uniwersalnego, to znaczy, że
organizacja / struktura bazy danych ulegnie zmianie

Musimy spojrzeć na problem w 2 płaszczyznach. Jedna z nich, to swego rodzaju fizyczna struktura aplikacji, czyli np. modułowa architektura, oddzielone GUI od logiki itp. Druga płaszczyzna, to logiczna struktura aplikacji, czyli coś, co będzie się zmieniać w zależności od potrzeb danej organizacji - struktura bazy danych, dostępne funkcje itp.

Opracujmy na początek swego rodzaju framework, szkielet aplikacji, który dostarczy funkcji potrzebnych w każdym z przypadków. Mam tutaj na myśli elementy umożliwiające autoryzację, połączenie z bazą danych, zarządzanie modułami, monitorowanie aktywności użytkowników.

Kolejnym krokiem może być przygotowanie warstwy logicznej, wspólnej dla większości zainteresowanych odbiorców. Może by to np. moduł do zarządzania danymi osobowymi.

Jeśli uda nam się wykonać powyższe, będzie to już wielki krok naprzód. Otrzymamy coś w rodzaju źródłowego systemu, na którym można się oprzeć budując aplikację wyspecjalizowaną dla konkretnych użytkowników.

W naszym przypadku będzie to TPBA. Dodamy moduły obsługujące placówki i koła, informacje o pobycie i płatnościach.

Jeśli inna organizacja będzie zainteresowana naszym systeme, będzie mogła łatwo dostosować do swoich potrzeb istniejące już moduły lub dodać nowe.


3. Jak ma wyglądać uaktualnianie / synchronizacja danych pomiędzy
węzłami (trzeba się nad tym ostro zastanowic, gdyż przyjęty
mechanizm może mieć duży wpływ na strukturę bazy danych)

To jest odrębna sprawa. Synchronizacja powinna być odrębnym procesem, opartym o zawnętrzne narzędzia lub dodatkowe moduły aplikacji. W tym momencie zostawmy ją na później.


Postulat oddzielenia logiki programu od GUI jest bardzo istotny.

Jednak ja tu widzę jeszcze konieczność podziału na moduły samej bazy
danych.
Skoro nie do końca wiemy, jakie będą potrzeby użytkownika końcowego
bazę trzeba tak zaprojektowac by łatwo było dołożyć / usunąć
możliwość przechowywania pewnych informacji.

Z tego co widzę na pewno przechowywać będziemy informacje o
1. użytkownikach bazy danych (czy te informacje będą propagowane w
systemie??)
2. osobie tzn: imie, nazwisko, adres, dokumenty,

pozostałe dane, tzn te, które dotyczą placówki, koła (w przypadku
TPBA) są danymi specyficznymi dla TPBA i stanowią oddzielny moduł
bazy danych...

Moduł generalnie powinien składać się z następujących elementów:
1. Logika aplikacji, realizująca odpowiednie funkcje
2. Elementy bazodanowe, wymagane do realizowania funkcji logiki
3. Interfejs użytkownika, umożliwiający skorzystanie z dostępnych funkcji

W tej chwili przychodzą mi na myśl takie moduły, jak:

-- uniwersalne --
1. Zarządzenie użytkownikami
2. Dane osobowe, w tym dokumenty tożsamości itp.
    - tabele: osoba, zawod*, wykształcenie, stan_cywilny,
              dokument_tozsamosci*, grupa_inwalidzka, zameldowanie
3. Adresy
    - tabele: adres, miasto, powiat, wojewodztwo

-- TPBA --
4. Koła i placówki
    - tabele: placowka[rodzaj|typ], kolo
5. Pobyt
    - tabele: pobyt
6. Płatności
    - tabele: platnosc, placowka_koszt
7. Poszerzenie danych osobowych (pokrewieństwo, osoby kontaktowe, zasiłki)
    - tabele: pokrewienstwo*, kontakt, zasilek*

pozdrawiam
--
Radoslaw Janeczko
Software Developer, GTS Polska
e-mail: address@hidden





reply via email to

[Prev in Thread] Current Thread [Next in Thread]