Witam, cześć.

Na początku chciałem zaznaczyć, że jestem laikiem (nie mylić z 'lajkiem') jeśli chodzi o bazy, skrypty i całe programowanie.
Potrzebna jest baza, a że na naukę nigdy nie za późno - więc postanowiłem zadziałać ;) Zasiadłem do kompa i... zonk od samego początku xd
Liczę, na waszą pomoc i pokierowanie we właściwym kierunku - bo wiadomo, że jak się idzie w złą stronę, do ciężko dotrzeć do celu. Po kolei:

  1. Wybór bazy
  • Base LO - jest najładniejsza (jeśli chodzi o późniejsze korzystanie - każda tabela w osobnym oknie, ładna gotowa 'szata'), minusem wydaje mi się 'niejasne' dla mnie zarządzanie skryptami (i chyba obsługuje mniej języków?).
  • MySQL - ma pewnie więcej możliwości oraz jest o wiele popularniejsza, a co za tym idzie łatwiej o pomoc - minus to tzw gui (nie wiem czy możliwe jest np. przez Calc LO czy trzeba 'budować' stronę www). Jest jakiś MySQL Workbench, ale nie sprawdzałem tego dokładnie jeszcze. Rozumiem, że tu PHP jest raczej konieczne?
  • PostgreSQL - popularnością goni MyQSL, możliwości chyba podobne - mam wrażenie, że jest troszkę trudniejsza w 'konfiguracji' i obsłudze.
  • Kexi - 'wynalazek' od Calligra - bardzo sympatyczna dla oka, przejrzysta, przez co wydaje się prosta (ma dwa języki skryptowe: qtscript oraz javascript).

Do tego LO i Kexi to plik na dysku. Na teraz to wydaje być się plusem (nie trzeba się 'babrać' z serwerami), jednak w przyszłości może to być duże ograniczenie. Dodatkowo to są 'inne' standardy chyba, więc może być problem z ewentualnymi migracjami do 'większych i zewnętrznych' baz (MySQL i PostgreSQL).

  1. Baza danych
    Udało mi się sklecić 'szkielet' w MySQL (oczywiście sporo brakuje - jakieś indexy, realcje, itd.) żeby pokazać zamysł, bo tłumaczenie laika mogłoby być zbyt niezrozumiałe ;)
    sqlfiddle.com/#!9/94bb2 (nie mogę wkleić linka, więc wklejam adres)
  • zrobiłem 3 tabele kategorii, bo zamysł jest taki, że w późniejszym formularzu (dodawania danych) kateg_3 jest zależna od kateg_2, a ta od kateg_1 - coś ala drzewiasta lista wyboru. Czy da (i czy powinno) się to zrobić w jednej tabeli? Tak samo dzialy są zależne od materialy.
  • podobnie operacje - dla wszystkich działów i materiałów jest jedna tabela - czy lepiej zrobić osobną tabelę dla każdego działu (każdy dział obsługuje tylko jeden material)?
  • dla +/- też jedna kolumna (rozbicie na + i - poprzez sortowanie) - czy może zrobić osobna kolumnę dla + i osobną dla - ?
  • kolumna stan - czy pozwolić bazie za każdym razem wyliczać stan (saldo) żeby potem wstawiać do widoku, czy może stworzyć kolumnę w tabeli, żeby sobie tam siedział (wyliczony podczas wprowadzania danych) i nie męczył bazy?

Do przeglądania bazy ma służyć jeden widok (domyślnie pokazuje wszystkie operacje - działy i materiały - taki trochę misz-masz) i dopiero później sortowanie czy to datami, czy działami, czy materiałami, czy kategoriami. Niestety nie umiem go jeszcze zrobić, więc załączyłem listę jak to miałoby wyglądać (formularze, raporty czy dodatkowe zapytania to oczywiście na później). Nie umiem w phpMyAdmin zrobić relacji (wciąż pyta o jakieś index'y).

Kolumny widoku:

  1. operacje.i_oper,
  2. operacje.data,
  3. dzialy.n_dzia,
  4. operacje.+/- AS minus, - tylko ujemne
  5. operacje.+/- AS plus, - tylko dodatnie
  6. ???.??? AS stan, - ??? tego totalnie nie umiem ugryźć, ta kolumna ma pokazywać stan (saldo) po operacji
  7. materialy.n_mate,
  8. kateg_1.n_kat1,
  9. kateg_2.n_kat2,
  10. kateg_3.n_kat3,
  11. operacje.uwagi,
  12. operacje.sprawdz, - tylko tak/nie
  13. operacje.kzdw

Zapewne nie uniknę 'zgłębiania' jakiegoś języka skryptowego, żeby którakolwiek z tych baz zadziałała. Jak myślicie - która opcja wymagać będzie najmniej kombinacji i rodzajów technologii (nie chcę się rzucać od razu na głęboką wodę, żeby się nie zniechęcić).

I na koniec - do was, którzy się znacie - ile czasu się 'kleci' taką bazę? I ile takie coś może kosztować, w przypadku gdyby mnie to przerosło? A może to wszystko całkiem nie tak kombinuję?

Czekając na wasze opinie i porady - pozdrawiam serdecznie.