пропозиції роботи
Wypowiedzi
-
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy PHP w praktyce...
-
Łukaszu, sorka ze nie odpowiedziałem przez 3 tyg ale złapało mnie zapalenie spojówek...
Przy definicjach PK oznacza Primary Key... Przy pozycjach tabeli dok_rodzaje zaś PK to kod określający paragon - korekta :)
Na tabeli z pozycjami faktur musisz zrobić klucz główny aby mieć pewność, że baza nie przyjmie dwóch tych samych pozycji (tam id = id faktury, lp = pozycja faktury)
W sumie to pierwszy raz słyszę żeby pozycja faktury była wspólna dla kilku faktur. Przecież pozycja 1 fatury X zawsze będzie dotyczyła faktury X a nie jeszcze dodatkowo fv Y oraz Z.
Co do kopiowania obiektu typu produkt / usługa... Po co kopiować cały obiekt do faktury? Do wystawienia fv nie są mi potrzebne np wymiar albo waga czy inne parametry techniczne produktu... Wystarczy tylko nazwa i kwota zakupu (do liczenia rentowności / przychodu dokumentu) bo vat, kwota sprzedaży i cała reszta i tak są podawane na fv... Pamiętać trzeba tylko aby nie słownikować żadnych z tych danych.
Cały obiekt typu produkt moim skromnym zdaniem powinien być kopiowany i przypisywany przy dokumentach magazynowych (np. WZ, PZ, RW, PW) które to z kolei powinny być skorelowane z dokumentami kasowymi (np. FV, FV PF, PAR). Ale rzecz jasna pytanie nie zakładało prowadzenia gospodarki magazynowej więc nie ująłem tego w poprzedniej wypowiedzi :).
Już nie wspominam o logowaniu zmian itp. -
Sposób rozwiązania może i dobry ale wg mnie podejście złe. Zakładam, że jest tworzona jakaś baza danych która ma przechowywać informacje o dokumentach handlowych. Nie zalecam zatem ograniczania się tylko do faktur. Powinieneś raczej pomyśleć o wszystkich dokumentach sprzedaży bo oprócz f-r masz np. jeszcze paragony, noty różnicowe oraz korekty. Dodatkowo należy pamiętać że dokumenty dzielą się na dokumenty zakupu oraz sprzedaży. Te drugie mają numeracje ciągłą ponieważ wystawiamy je my. Te pierwsze zaś mają różną numerację ponieważ są dokumentami kosztowymi. Nie jestem finansistą tak więc mogę się mylić :)
Jeżeli już ustalasz relację to proponuje tabele nazwać: dokumenty / dok_sprzedaz oraz dokumenty_pozycja / dok_sprzedaz_pozycja a następnie tak jak już zostało ustalone.
dok_rodzaje:
id, kod, rodzaj
1, F, Faktura
2, FK, Faktura korekta
3, P, Pragon
4, PK, Paragon korekta
dok_sprzedaz:
id, id_korekta, zakup_sprzedaz, rodzaj_dokumentu, numer, data_wprowadzenia, .... (PK = id) (FK = id_korekta do id oraz rodzaj_dokumentu do dok_rodzaje.id)
dok_sprzedaz_pozycja:
id, lp, jednostka_miarywagi, ilosc, kwota_netto (PK = id, lp; lp dla kazdego id od 1) (FK id do dok_sprzedaz.id)Marcin Mackiewicz edytował(a) ten post dnia 30.08.11 o godzinie 21:11 -
Zdecydowanie polecam PostgreSQL. Niestety aby przeniesc dane potrzeba czasu, czasu i jeszcze raz czasu. Bez relacji oraz gromadzenia danych w konkretnej strukturze przenoszenie bedzie bardzo uciazliwe.
Proponuje:
1. Przeniesc tabele do nowej bazy danych tak jak sa 1:1 (export import via plik tekstowy + jakis skrypy ktory wygeneruje odpowiednie inserty lub copy).
2. Tworzyc pokolei slowniki,ew. sekwencje, widoki, itp.
3. Przeniesc dane do nowej struktury przy pomocy czystego sql.
Plus z tego taki ze baza w access moze byc caly czas uzywana a Ty masz gotowy zestaw skryptow sql ktore w kazdej chwili mozna uzyc (o ile w miedzyczasie nie zostanie zmieniona struktura bazy w access'ie). -
Hmmm, trochę chaotycznie opisane. Z ostatniego zapytania SQL wnioskuję że interfejsem do bazy jest jakiś PHP. Proponuję użyć tak jak radzi "Noidea" zrobić dodatkową tabelkę wiele do wielu ale numery umieścić w kolumnie typu text oddzielone jakimś separatorem (np. kropką). Do tego w interface uzyć funkcji 'expolde()' do czytania numerów oraz 'implode()' do zapisywania.
Wyszukiwanie jest troszkę nieefektywne ze względu na sprawdzanie tekstu ale zwykły like % sobie poradzi (nie wiem o jak dużej bazie jest mowa).
Dodatkowo dodanie pola uwagi jest świetnym pomysłem.
Lepszego rozwiązania raczej nie ma bo i tak gdzieś musisz zapisywać numery ulic i przypisywać je do odpowiedniego pracownika.
Tak na marginesie budynki socjalne czy więzienia także mają swoje adresy (poczta wymaga pełnego adresu). -
Nie bardzo rozumiem jakie dane chcesz uzyskac. Zakladam ze najpierw sumujesz wartosci z kolumny net_pl a nastepnie patrzysz na wynik otrzymanej sumy (w obrebie danego order_id dla danego trader_id).
Dalej chcesz zliczyc wystapienia wszystkich order_id dla danego traider_id i jezeli wynik sumy dla danego order_id jest >= 0 to liczysz na plus a jezeli jest suma jest < 0 to liczysz na minus.
Oznacza to ze po sumowaniu zliczasz wystapienia wg warunku podanego warunku.
Zakladam ze order_id to id zamowienia a trader_id to numer klienta.
Stosowanie klauzuli distinct na kolumnie order_nbr jest bledne poniewaz distinct wezmie do podsumowania tylko jedna (dowolna) wartosc. Jezeli zdazy sie ze w jednym order_nbr raz wystapi net_pl < 0 i raz net_pl > 0 to w zaleznosci od planera raz dostaniesz policzenie na minus a raz na plus.
Rozwiazaniem jest suma po net_pl ze wzgledu na order_nbr a nastepnie wrzucenie do kolumny plus lub minus w zaleznosci od sumy a potem policzenie wystapien w kolumnach.
Dla przykladowej tabeli:
create table t (
trader_id text,
order_nbr int8,
symbol text,
gross_pl float,
net_pl float,
event_date date,
"time" time without time zone
);
Rozwiazanie:
select trader_id, count(net_pl_plus) as net_pl_plus, count(net_pl_minus) as net_pl_minus from
(
select
trader_id,
(case when sum(net_pl) >= 0 then sum(net_pl) else null end) as net_pl_plus,
(case when sum(net_pl) < 0 then sum(net_pl) else null end) as net_pl_minus
from t
group by trader_id, order_nbr
) as wynik
group by trader_id;
Proponuje zrobic z tego funkcje z paramerem gdzie bedzie podawany trader_id a zwracany record.Marcin Mackiewicz edytował(a) ten post dnia 01.08.11 o godzinie 19:15 -
Koledzy... Zakombinowaliście nieco. Pierwsza rzecz to nie wiadomo o jaki model bazy chodzi. Jeżeli pod uwage brany jest mysql z tabelami typu (cyba) myISAM to rozwiazanie z dodaniem usera anonimowego jest jak najbardziej trafne.
Jezeli jednak jest to inna niz MySQL baza to proponuje na tabeli comments stworzyć klucz głowny na dwoch kolumnach (id, id_user) a interface użytkownika zrobic tak ze anonimowe dodawanie komentarza powoduje wpisanie nulla do id_user. Teraz przy wyswietlaniu komentarzy kazdy id_user is null to uzytkownik anonimowy.
Jak widzimy nie trzeba tworzyc dodatkowego uzytkownika...Marcin Mackiewicz edytował(a) ten post dnia 09.02.11 o godzinie 20:23 -
Najszybszy jest podany wcześniej EMS, niestety do użytku w firmie jest płatny co nie jest fajne ;/
Ja radze sobie standardowym PgAdminem ktory w najnowszej wierszji ma jakieś tam podpowiadanie składni ale niestety przy bardzo skomplikowanych relacyjnie bazach sobie nie radzi. -
Heh, czytam i czytam i dopiero jak doczytalem do konca to sie dowiedzialem do czego ma byc stodowna funkcjonalnosc uzywana. Kolega z tego co widze chce miec zestaw danych w posataci tabelarycznej zeby potem uzyc go do jakis celow (np korespondencja seryjna). Tylko nie rozumiem dlaczego akurat do *.doc. Ja bym uzyl exel'a a plik wynikowy to zwykly tekstowy *.csv ktory notabene jest czytany bezproblemowo przez exel'a.
Proponuje uzyc php do zrobienia polaczenia z baza, stworzeniem zapytania a potem zapisania do pliku, a nastepnie wyslania go np mailem na konkretny adres. Plus jest z tego taki ze dane nie lataja np niezaszyfrowanym polaczeniem odbc po necie jak tu koledzy radza tylko calosc jest wykonywana na serwerze.
Doczytalem tez ze kolega uzywa JOOMLA tak wiec moze poprostu wystarczy modul w backend ktory to zrobi?
Proponuje przejrzec samouczek do tworzenia obiektow JOOMLI - jest dosc proste: http://www.wromanek.info/artykuly/16-kurs-pisania-komp...
I mozna robic zapytania do bazy.
Jezeli chodzi o kopiowanie danych to stanowczo odradzam bo potem nie bedzie wiadomo ktora dana jest najbardziej aktualna (przynajmniej przy stanie obecnym) -
Pomysl na elektroniczny dziennik jest naprawde fajny - popieram pomysl. Moje uwagi:
1. Tabela z profilem [profile] (id) jest ok. Proponuje takze zrobic [profile_extra] jako tabele z dynamicznynie dodawanymi polami (cechy dodatkowe jakie sobie wymysli dana szkola
2. Tabela [history], (id PK, lp PK, rok_immatr, rok_szkolny, semestr_w_roku, semestr_kolejny, rok_nauki) gdzie prowadzimy historie danego ucznia (kazdy wpis odpowiada kolejnemu semestrowi nauki). Raz na pol roku (tak jak ida semestry) dokonujemy potem promocji ucznia na nastepny semestr. To pomoze np sprawdzac czy uczen w danym semestrze ma wszystko zaliczone. Proponuje tutaj takze dodac rok immatrykulacyjny ktory pozwoli zidentyfikowac proces dydaktyczny w danym cyklu nauki (rozroznianie powtarzajacych rok).
Tutaj mozna tez wprowadzic statusy na jakich jest uczen (OK, Trwa rozliczanie, Powtarzanie, itp.)
3. Tabela [przedmiot] gdzie przechowujemy informacje o tym jakie przedmioty na danym semestrze ma dany uczen. W tym miejscu zapisujemy rowniez koncowa ocene z danego przedmiotu.
4. Tabela [przedmiot_czastkowe] w ktorej to przechowujemy eventy przeprowadzane w ciagu roku (testy, sprawdziany, kartowki, odpytka, itp.). Pamietane dla ucznia, przedmiotu
5. Tabela [history_zachowanie] powiazana scisle z [history] gdzie wpisujemy informacje o okresowej ocenie postepow studenta
6. Tabela [przedmiot_zachowanie] w ktorej prowadzacy przedmiot moze wystawic opinie, spostrzerzenia, uwagi, itp.
Definiowanie klas:
Klasy w szole to nic innego jak grupa uczniow stworzona dla potrzeb przeprowadzania zajec.
Proponuje wiec stworzyc tabele [groups] oraz [groups_sklad] w ktorej beda trzymane sklady grup. Teraz klasa specjalna (np mat-fiz) to nic innego jak specjalna grupa tak wiec proponuje dodac to tego tabele [groups_cechy] w ktorej beda przechowywane informacje o tym jaka to jest klasa (cechy do grup). Jezeli chodzi o grupy to zakladane powinny byc z kluczem (rok_immatr) poniewaz grupa funkcjonuje tak dlugo jak uczniowie sie ucza (np gminazjum 3 lata) ale pamietac trzeba ze klasa 1A wystepuje co roku czyli po 2 latach mamy klasy 1A(2008) oraz 1A(2009) gdzie data jest rokiem kiedy uczniowie przyszli do szkoly.
Kazda klasa ma wychowawce (opiekun) co nasowa zrobienie slownika [wykladowcy] i przypisywania go bezposrednio do grupy, posrednio do ucznia.
No to mamy szkielet.
W takim wypadku jak teraz problemem jest nadawanie przedmiotow uczniom. Jeden uczen ma ok 15 przedmiotow. W klasie jest ok 30 uczniow co powoduje ze uzytkownik musialby nadac 15*30= 450 wpisow do tasbeli. W tym wypadku warto by pomyslec nad ramowym przebiegiem zajec (kazdy rocznik uczy sie wg jakiegos planu dydaktycznego). Proponuje dodac tabele [ramowka] oraz [ramowka_sklad] gdzie bedzie zdefiniowany standardowy rozklad przedmiotow dla danego roku_immatr, klasy, semestru. Pozwoli to dobudowac funkcje w UI ktora dla danej klasy (grupy studentow) nada w odpowiednim wpisie w historii odpowiednie przedmioty.
No to mamy podsawowy system do zarzadzania uczniami gdzie:
- Kazdy uczen moze uczyc sie indywidualnie (zestaw przedmiotow przy uczniu a nie przy klasie)
- Uczen moze powtarzac rok (kolejny wpis w historii studenta na odpowiedni rok szkolny na odpowiedni semestr nauki)
- Uczen moze zmienic klase (wyrzucenie z jednej grupy i zapisanie do drugiej)
- Przy przedmiotach mozna wpisywac oczeny czastkowe
- Kazdy uczen moze byc oceniony przez opiekuna (oceny semestralne zachowania)
- Kazdy uczen moze zostac zaopiniowany przez prowadzacego przedmiot
Relacji w bazie mysle nie bede opisywal bo nasowaja sie same. Za ortografy i literowki bardzo przepraszam. -
Aby mieć możliwość przeczytania tego posta musisz być członkiem grupy PHP w praktyce...
Dołącz do GoldenLine
Oferty pracy
Sprawdź aktualne oferty pracy
Aplikuj w łatwy sposób
Aplikuj jednym kliknięciem
