Bazy danych / Motel C#+MySQL system :: Forum programisty php

2011-01-26 11:14:46 Post #1 gość_Bob

O dobry pomysł Robert - na pewno mase ludzi szuka takie aplikacji, a nie mam nic przeciwko, żeby ktoś tam z niej korzystał/uczył się.

Tylko ja będę robił ten projekt w VS C# +MySQL, ale domyslam się, że coś tam masz wspólnego z nim też, mam rację? Siedziałeś kiedys w C#?

Jak coś to ja będę pisał/tłumaczył od strony aplikacji to nie jest trudne.

Zabieramy się ?

2011-01-26 11:28:34 Post #2 nospor

Dawaj

2011-01-26 13:07:50 Post #3 bob

Ok, więc wklejam to co do tej pory udało się zrobić i kolejne założenia:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

CREATE TABLE `klienci` (
  `klient_id` int(11) NOT NULL AUTO_INCREMENT,
  `nazwisko` varchar(25) NOT NULL,
  `imie` varchar(25),
  `pesel` varchar(40),
  PRIMARY KEY (`klient_id`),
  KEY `klient_id` (`klient_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;

CREATE TABLE `pokoje` (
  `pokoj_id` int(11) NOT NULL AUTO_INCREMENT,
  `nr_pokoju` int(11) NOT NULL,
  PRIMARY KEY (`pokoj_id`),
  KEY `pokoj_id` (`pokoj_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;;

CREATE TABLE `rel_klient_pokoje` (
  `rel_klient_pokoje_id` int(11) NOT NULL AUTO_INCREMENT,
  `klienci_klient_id` int(11) NOT NULL,
  `pokoje_pokoj_id` int(11) NOT NULL,
  PRIMARY KEY (`rel_klient_pokoje_id`),
  KEY `klienci_klient_id` (`klient_id`)
  KEY `pokoje_pokoj_id` (`pokoj_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;

następnie tworzymy potrzebne relacje:

1
2

CONSTRAINT `jakasnazwa` FOREIGN KEY (`pokoje_pokoj_id`) REFERENCES `pokoje` (`pokoj_id`) ON DELETE cascade

1
2

CONSTRAINT `jakasnazwa2` FOREIGN KEY (`klienci_klient_id`) REFERENCES `klienci` (`klient_id`) ON DELETE cascade

W pola jakasnazwa i jakasnazwa2 wpisujemy dowolny string ....

2011-01-26 13:13:31 Post #4 bob

Teraz trzeba jeszcze w bazie dodać daty od do - chciałbym ją wpisywać razem z rejestracją, czyli pewnie powinienem dodać dwa pola do tabeli klient.

Jednak sprawa jest bardziej skomplikowana, gdyż muszę też wykonać taki jakby grafik np w jakieś tabeli, który będzie pobierał informacje od kiedy do kiedy ktoś jest zaznaczał to kolorem, kolorował te dni i wypisywał na tym kolorze ile osób jest w tym pokoju - a ilosc osob pobieral z jakiegos tam pola wypelnionego przy rejestracji (proste).

Czyli trzeba dołożyć pola od do - daty w jakieś formie np 01-10-2010

Grafik ma być o tyle specyficzny, że ma to być tak:

jest tabelka na dany miesiac i teraz np kowalski jest od 5 do 12 stycznia i sa dwie osoby w pokoju1 to:
(koloruje ten kawalek wiersza np na czerwono i wpisuje 2)

adam laskowski jest w pokoju 4 od 10 do 12 i sa z nim 3 osoby to na zielony

1
2
3
4
5
6
7
8
9

1 | 2 | 3 | 4 | 5 | 6 | 7 | 8 | 9 | 10 | 11 | 12 | 13 | 14 | 15 | 16 | 17 | 18 | 19 | 20 | 21 | 22 | 23 | 24 | 25 | 26 | 27 | 28 | 29 | 30 | 31 |
pokoj1 pokoloroweany kawalek wiersza
pokoj2
pokoj3
pokoj4 pokolorowany
......
pokoj 303
......

Masz jakieś pomysły?

2011-01-26 13:23:02 Post #5 nospor

1) Mówiłem ci, że klucz autoincrement dla tabeli wiążacej jest zbędny
2) INT(11) te 11 też są zbęde
3) Daty od do przecież dotyczą wizyty klienta. Nie możesz więc ich dodać do tabeli klient, tylko masz je dodać do tabeli zamówienia, której notabene nie masz

Od biedy tą tabelą może być tabela: rel_klient_pokoje i w niej masz dodac daty. Jeśli tą tabelę zrobisz tabelą zamówienia to wowczas punkt 1 mojej wypowiedzi znika.
4) A grafik to już rysowanie
5) Od kiedy pesel ma 40 znaków? Poza tym pesel jest stały więc char a nie varchar
6) nr_pokoju to INT? Będziesz miał kilka miliardów pokoi?
7) do kluczy głównych dawaj UNSIGNED - przecież nie będą ujemne. Numer pokoju zresztą też
8) Przy kasowaniu pokoju daj RESTRICT a nie CASCADE - chyba nie chcesz by po zamowieniu pokoju przez klienta przez omylke skasowac to zamowienie przy kasowaniu pokoju. Jesli jest zamowienie na dany pokoj to baza nie powinna pozwolic na skasowanie tego pokoju

2011-01-26 15:07:22 Post #6 bob

ok Robercie poprawię jak wrócę do domu mam awarię w serwerowni (będę około 17-20 max) i odpiszę.

2011-01-26 22:47:46 Post #7 bob

1) Wydaję mi się, że nie jest zbędny, gdyż póżniej jak będę chciał jakoś się dobrać do jakiegos powiązania, czy jakoś zaoperować na danym powiązaniu/powiązaniach to przyda się id/'s tych powiązań bo tak mogą w kolumnach będą się często duplikowały numery i ciężko bedzie się odnieść - moim daniem zostawić lepiej, a przecież nie zaszkodzi...
2) poprawiłem w różnych miejscach - do sprawdzenia
3) Daty od do przecież dotyczą wizyty klienta. Nie możesz więc ich dodać do tabeli klient, tylko masz je dodać do tabeli zamówienia, której notabene nie masz
Od biedy tą tabelą może być tabela: rel_klient_pokoje i w niej masz dodac daty. Jeśli tą tabelę zrobisz tabelą zamówienia to wowczas punkt 1 mojej wypowiedzi znika.
4) A grafik to już rysowanie
5) Poprawione
6) jak w punkcie 2 - do sprawdzenia
7) poprawione - do sprawdzenia
8) poprawione

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25

CREATE TABLE `klienci` (
  `klient_id` unsigned int(11) NOT NULL AUTO_INCREMENT,
  `nazwisko` varchar(25) NOT NULL,
  `imie` varchar(25),
  `pesel` char(11),
  PRIMARY KEY (`klient_id`),
  KEY `klient_id` (`klient_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;

CREATE TABLE `pokoje` (
  `pokoj_id` unsigned smallint(6) NOT NULL AUTO_INCREMENT,
  `nr_pokoju` unsigned smallint(6) NOT NULL,
  PRIMARY KEY (`pokoj_id`),
  KEY `pokoj_id` (`pokoj_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;;

CREATE TABLE `rel_klient_pokoje` (
  `rel_klient_pokoje_id` unsigned int(11) NOT NULL AUTO_INCREMENT,
  `klienci_klient_id` unsigned int(11) NOT NULL,
  `pokoje_pokoj_id` unsigned int(11) NOT NULL,
  PRIMARY KEY (`rel_klient_pokoje_id`),
  KEY `klienci_klient_id` (`klient_id`)
  KEY `pokoje_pokoj_id` (`pokoj_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;

i powiązania:

1
2
3
4

CONSTRAINT `jakasnazwa` FOREIGN KEY (`pokoje_pokoj_id`) REFERENCES `pokoje` (`pokoj_id`) ON DELETE restrict

CONSTRAINT `jakasnazwa` FOREIGN KEY (`klienci_klient_id`) REFERENCES `klienci` (`klient_id`) ON DELETE cascade

Robercie przepraszam, że nie zjawiłem się do 20. Godzinke temu wróciłem i zacząłem siedzieć nad naszym projektem.

A, więc przedstawiam założenie :

I ETAP:

-> Musimy zarejestrować danego klienta

(tutaj załóżmy, że wpisujemy dane takie jak:

-> imie
-> nazwisko
-> telefon
-> jaki pokój/pokoje w jakim domu
-> ilosc osob
-> rodzaj wczasow
-> data od -do
-> 1 rata
-> 2 rata
-> 3 rata
-> nr faktury/paragonu
-> razem wpłaty

wymagane pola przy rejestracji (gdyz klient składa rejestrację np telefonicznie)

-> imie
-> nazwisko
-> telefon
-> pokój/pokoje w jakim domu
-> ilosc osob

reszta moze byc wpisana pozniej

klienta (osobe rezerwujaca - możemy dodac np do dwoch domow i konkretnych pokojów, gdyż np zamawia dla dwóch rodzin

ilosc osób potrzebna jest po to, aby na kolorowym pasku wyświetliło też te liczby

DANE:
Załóżmy, że mamy 4 domy, a wnich pokoje:

załóżmy nazwijmy je:
-> dom1b (pokoj1/pokoj2/pokoj3/pokoj4/pokoj5)
-> dom2m (pokoj1/pokoj2/pokoj3/pokoj4/pokoj5/pokoj6)
-> dom3m (pokoj1/pokoj2/pokoj3/pokoj4/pokoj5/pokoj6/pokoj7)
-> dom4p (pokoj1/pokoj2/pokoj3/pokoj4/pokoj5/pokoj6/pokoj7/pokoj8)
-> dom5z (pokoj1/pokoj2/pokoj3/pokoj4/pokoj5/pokoj6/pokoj7/pokoj8/pokoj9)

GRAFIK:

kolor paska zalezy od rodzaju wczasow przyjmijmy:

- zolty - to indywidualne
- zielony - rehabilitacyjne
- niebieski - spa

-> Musimy ustalić datę od - do pobytu osoby rezerwującej (i według tej daty bedzie się wypełniaj układ graficzny)

Teraz chyba najtrudniejsze:

Dla każdego domu jest osobny grafik, czyli dla:
-> dom1b, dom2m, dom3m, dom4p, dom5z

i tak jak "narysowałem"

wyżej mięsieczny period

BILANS:

Listujący
-> listę faktur (numery, kwoty netto/brutto z podziałem np na VAT 23% ,8 %, nazwisko, imie na kogo bylo + ogolem kwota)
-> listę paragonów (numery, kwoty netto/brutto z podziałem np na VAT 23% ,8 %, nazwisko, imie na kogo bylo + ogolem kwota)
-> ogółem kwota neeto bruton faktur ogólnie i w różnych podziałach VAT jak wyżej i paragonów

te dane bedzie jakos musial pobrac z tabeli i wyliczyc

============================================================
PODSUMOWANIE

Mam nadzieję,Robiercie, że dobrze zrozumiałeś to co napisałem - jeśli coś niejasno napisałem prosze napisz.

Myslę, że najpierw trzeba by zacząć od stworzenia bazy danych MySQL, żeby łatwo było operować danymi.

Chciałbym, abyś się narazie wypowiedział na temat tego co napisałem jak to widzisz, co proponujesz etc...

Czy posiadasz wogóle pakiet Visual Studio, i czy ewentualnie mógłbyś doinstalować wraz z dodatkiem MySQL - w instalacji i konfiguracji mogę pomóc nie ma problemu.

serdecznie pozdrawiam liczę na dalszą współprace i niecierpliwie czekam na odpowiedz,
Robert

2011-01-27 09:31:59 Post #8 nospor

Nie wiem czemu napisales, że poprawiłeś te liczby przy INTach skoro jak były tak są.

Skoro pokoje będą w domach, to dobrze by było stworzyć jeszcze tabelkę dla domu a w tabeli pokoju relacje do domu
Skoro klient ma miec telefon i takie tam to dodaj te pola do tabeli.
Do tabeli pokoju dodaj liczbę miejsc (później program musi sprawdzic czy nie przekroczono liczby miejsc)
Do tabeli zamowienia (pokoj_klient) masz dodac daty, juz ci mowiłem.
Do pokoju zapewne też musisz dodać ceny

Nie rozumiem jednej rzeczy. Czy w pokoju mogą naraz mieszkać róźni klienci? Bo do tej pory wychodzi mi, że tak, ale to jest totalnie bez sensu. Ja osobiscie jadąc na wakacje to nie chciałbym mieszkać z kims obcym w pokoju

Visual Studio nie mam najmniejszego zamiaru instalować, bo:
1) Nie mam windows
2) Bo tak

2011-01-27 10:21:41 Post #9 bob

AD1] Tzn mam przy pokojach, klientach zostawić samo "int"- ok, ale relacji już będzie dużo, więc jaką wartość zostawić w int?

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26

CREATE TABLE `klienci` (
  `klient_id` unsigned int() NOT NULL AUTO_INCREMENT,
  `nazwisko` varchar(25) NOT NULL,
  `imie` varchar(25),
  `pesel` char(11),
  PRIMARY KEY (`klient_id`),
  KEY `klient_id` (`klient_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;

CREATE TABLE `pokoje` (
  `pokoj_id` unsigned smallint(6) NOT NULL AUTO_INCREMENT,
  `nr_pokoju` unsigned smallint(6) NOT NULL,
  PRIMARY KEY (`pokoj_id`),
  KEY `pokoj_id` (`pokoj_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;;

CREATE TABLE `rel_klient_pokoje` (
  `rel_klient_pokoje_id` unsigned int() NOT NULL AUTO_INCREMENT,
  `klienci_klient_id` unsigned int() NOT NULL,
  `pokoje_pokoj_id` unsigned int() NOT NULL,
  PRIMARY KEY (`rel_klient_pokoje_id`),
  KEY `klienci_klient_id` (`klient_id`)
  KEY `pokoje_pokoj_id` (`pokoj_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;

AD2] a)Masz na myśli, jeżeli mamy nasze 5 domów, a w każdym z nich pokoje tzn, że dla każdego domu, który posiada swoje pokoje trzeba stworzyć oddzielne tabelki?
b)Nie wiem jak miałaby wyglądać ta relacja "w tabeli pokoju relacje do domu "
AD3]

Skoro klient ma miec telefon i takie tam to dodaj te pola do tabeli.

Dane w tabeli klient uzupełnione
AD4]

Do tabeli pokoju dodaj liczbę miejsc (później program musi sprawdzic czy nie przekroczono liczby miejsc)

Tylko nie wiem, czy ma to sens, bo z liczbą miejsc chodzi o to Robercie, że ta liczba powinna być pobrana do układu graficznego w tych paskach i tyle.
Nie potrzebujemy definiować ile osób może być w pokoju, gdyż osoba, która będzie rejestrowała zgłoszenie rezerwacyjne rozmawiając z klientem dowie się ile osób przyjedzie i rozdysponuje ich do pokojów i tyle
A, więc liczba miejsc jest nam tylko potrzebna do wyświetlenia na kolorwym pasku.
Dobrze by było, aby można było zawrzeć, gdzieś informację ile w tym jest osób starszych, a ile dzieci, tak, żeby póżniej można było to sobie, gdzieś w bilansie policzyć
Liczba miejsc jest jedną z wymaganych danych od razu przy rejestracji

AD5]

Do tabeli zamowienia (pokoj_klient) masz dodac daty, juz ci mowiłem.

Tutaj bym się zastanowił Robert, dlatego, że cały czas myślę o póżniejszym wyciąganiu danych w sensie jakis podliczeń, bilansów etc...
Czy jestes zatem pewien, że umieszczenie daty w tabeli rel_klient_pokoje będzie dobre na przyszłe dodawanie jakis bilansów, podliczeń etc, czy może jakoś lepiej to wydzielić?

AD6]

Do pokoju zapewne też musisz dodać ceny

Teraz tak z cenami wygląda to tak, że powinno być mozliwość wbicia wpłat przez klienta, np pola rata I, rataII, rata III i ogółem wpłat

Te dane będą wbijane póżniej w sensie klient może zapłacić od razu z góry, albo w 2 ratach, czy 3 a ogółem to miejsce, gdzie będzie z automata liczona suma obecnych wpłat pobierana z wierszy rat...
Więc, tak jakby ceny nie musimy wbijać na dany dom/pokoj sztywno, wystarcza miejsca na wbijanie tych danych

Dlatego zastanawiam się, czy nie lepiej wydzielić tego do osobnej tabeli - w celu jak zawsze myślę w pózniejszym wyciąganiu, sumowaniu, procentowaniu jakiś bilansów i podsumowań (mam nadzieję, że rozumiesz o co mi chodzi)

AD7]

Nie rozumiem jednej rzeczy. Czy w pokoju mogą naraz mieszkać róźni klienci? Bo do tej pory wychodzi mi, że tak, ale to jest totalnie bez sensu. Ja osobiscie jadąc na wakacje to nie chciałbym mieszkać z kims obcym w pokoju

Oczywiście, że nie Robercie

Chociaż faktycznie tak to napisałem ..

Dzwoni ktoś rezerwuje np w domu1m pokoj 2 pokojowy, i w dom4p pokoj 3 -pokojowy

2011-01-27 10:43:20 Post #10 nospor

AD1)
Zadnej wartosci masz nie wstawiac
NIe INT(11)
NIe INT()
a:INT

to samo dotyczy smallintow i kazdych innych intow. te liczby niczemu nie sluzą, chyba ze uzywasz zerofill a nie uzywasz.

ad2) No tak, musi byc tabela dom. Przecież klient wybiera po domach, potem po pokojach. Musi wiedziec ktory pokoj w jakim domu lezy.

ad2b) No do tabeli z pokojem masz dodac pole id_domu i zalozyc na to relację on delete cascade

ad3) Nigdzie nie widzę tego

ad4) Gdy jechałem na wakacje to widziałem czy pokój jest dwu osoby czy trzy osobowy czy 5-cio osobowy. A to, czy ja się później ugadałem z wlascicielem i do pokoju dwu osobowego wlazlem z zoną i dwojką dzieci to już inna bajka.

ad5) No a gdzie ty te daty chcesz trzymac jak nie w powiązaniu klienta z pokojem?

ad6) mówię o cenie za pokój a nie o ratach jakie klient wplacil. Jak jade na wczasy to interesuje mnie cena pokoju a nie brak tej ceny

2011-01-27 11:28:29 Post #11 bob

AD1) Poprawione

AD2) (Zamieńmy może nazwę dom na "budynek")
Ok tabela budynki - i w niej budynki, czy każdy budynek osobno ma swoją oddzielną tabelę?

AD2b) Ok - dodałem pole : budynek_id i założyłem referencję: (dosprawdzenia)

dodatkowo: zmieniłem w tabeli pokoje: nr_pokoju na nazwa_pokoju, gdyż może to być numer 303, a może np 1b...

AD3) Telefonu nie będzie w ogóle

AD4) Robercie, ale to jest program dla pracowniczki, która wbija do programu dane, klient mówi, że chce 3 pokojowy - to ona już wie jaki pokój mu przydzielić.

AD5) Ok daty dodałem do tabeli rel_klient_pokoje - do sprawdzenia
(ewentualnie może dać defaultowe wartości, żeby pokazywąło prawidłowy format wprowadzania takiej daty?)

AD6) To cenę za pokój będziesz miał na stronie internetowej, a w naszym programie pracownik zna te ceny i wbija tylko wpłacone wpłaty.
[quote]

A, więc tak wygląda nasz dotychczasowy projekt (narazie baza) -do sprawdzenia przez nospor:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42

CREATE TABLE `klienci` (
  `klient_id` unsigned int NOT NULL AUTO_INCREMENT,
  `nazwisko` varchar(25) NOT NULL,
  `imie` varchar(25),
  `pesel` char(11),
  PRIMARY KEY (`klient_id`),
  KEY `klient_id` (`klient_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;

CONSTRAINT `jakasnazwa` FOREIGN KEY (`klienci_klient_id`) REFERENCES `klienci` (`klient_id`) ON DELETE cascade

CREATE TABLE `pokoje` (
  `pokoj_id` unsigned smallint NOT NULL AUTO_INCREMENT,
  `nazwa_pokoju` varchar(20) NOT NULL,
  `budynek_id` unsigned smallint NOT NULL,
  PRIMARY KEY (`pokoj_id`),
  KEY `pokoj_id` (`pokoj_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;

CONSTRAINT `jakasnazwa` FOREIGN KEY (`budynek_id`) REFERENCES `budynki` (`budynek_id`) ON DELETE cascade

CREATE TABLE `budynki` (
`budynek_id` unsigned smallint NOT NULL AUTO_INCREMENT,
`nazwa_budynku` varchar(20) NOT NULL,
PRIMARY KEY (`budynek_id`),
    KEY `budynek_id` (`budynek_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;

CREATE TABLE `rel_klient_pokoje` (
  `rel_klient_pokoje_id` unsigned int NOT NULL AUTO_INCREMENT,
  `klienci_klient_id` unsigned int NOT NULL,
  `pokoje_pokoj_id` unsigned int NOT NULL,
  `data_od` date NOT NULL,
  `data_do` date NOT NULL,
  PRIMARY KEY (`rel_klient_pokoje_id`),
  KEY `klienci_klient_id` (`klient_id`)
  KEY `pokoje_pokoj_id` (`pokoj_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;

CONSTRAINT `jakasnazwa` FOREIGN KEY (`pokoje_pokoj_id`) REFERENCES `pokoje` (`pokoj_id`) ON DELETE restrict

Nie wiem również, gdzie najlepiej wrzucić rataI, rataII,rataIII, wpłaty ogółem, z uwzględnieniem do tych póżniejszych bilansów/podliczeń etc..
Jak uporać się z rodzajem wczasów - od których to będzie zależał kolor...

Robert

2011-01-27 11:40:05 Post #12 nospor

ad2)
Nie, tabela budynki a w niej kazdy buden to oddzielny rekord. Tak jak w pokojach, jedna tabela pokoi a w niej rekordy pokoje

ad4) a ona wie na podstawie czego? Chyba gdzies ma miec te dane zapisane, na kartce? To skoro na kartce to na grzyba jej program skoro wszystko ma na kartce... No chyba po to ma miec program by nie szukac po kartkach tylko program jej pomagał

ad5) Co ma default do formatu? nic.

ad6) A jak tam chcesz

Raty gdzieś do tabeli z ratami/oplatami

2011-01-27 12:48:19 Post #13 bob

ad2) Nie, tabela budynki a w niej kazdy budynek to oddzielny rekord. Tak jak w pokojach, jedna tabela pokoi a w niej rekordy pokoje

ad4) Tak, ona będzie wiedziała - wystarczą 3 pola (3 raty) i pole ogółem wpłat, które dodaje wpłacone kwoty z tych pół - załóżmy, że klient ma do zapłaty 600 - wpłacił jedną ratę to w tabeli w polu I rata pokaże się 200 i ogółem też 200.

ad5) w sensie: NOT NULL default '0000-00-00',

ad6) No niech tak zostanie

ad7) Myślę, że pola: rata1,rata2,rata3, ogolem_wplat - do tabeli klienta, później jakoś jak będziemy chcieli jakiś bilans utworzyć wszystkich wpłat to nie będzie problemu z wyłowieniem tych danych. Tak?

===== Sprawdz Robercie, czy to wszystko się na razie trzyma kupy, czy klucze i relacje są dobrze zrobione

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41

CREATE TABLE `klienci` (
  `klient_id` unsigned int NOT NULL AUTO_INCREMENT,
  `nazwisko` varchar(25) NOT NULL,
  `imie` varchar(25),
  `pesel` char(11),
  PRIMARY KEY (`klient_id`),
  KEY `klient_id` (`klient_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;

CONSTRAINT `jakasnazwa` FOREIGN KEY (`klienci_klient_id`) REFERENCES `klienci` (`klient_id`) ON DELETE cascade

CREATE TABLE `pokoje` (
  `pokoj_id` unsigned smallint NOT NULL AUTO_INCREMENT,
  `nazwa_pokoju` varchar(20) NOT NULL,
  `budynek_id` unsigned smallint NOT NULL,
  PRIMARY KEY (`pokoj_id`),
  KEY `pokoj_id` (`pokoj_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;

CONSTRAINT `jakasnazwa` FOREIGN KEY (`budynek_id`) REFERENCES `budynki` (`budynek_id`) ON DELETE cascade

CREATE TABLE `budynki` (
`budynek_id` unsigned smallint NOT NULL AUTO_INCREMENT,
`nazwa_budynku` varchar(20) NOT NULL,
PRIMARY KEY (`budynek_id`),
    KEY `budynek_id` (`budynek_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;

CREATE TABLE `rel_klient_pokoje` (
  `rel_klient_pokoje_id` unsigned int NOT NULL AUTO_INCREMENT,
  `klienci_klient_id` unsigned int NOT NULL,
  `pokoje_pokoj_id` unsigned int NOT NULL,
  `data_od` date NOT NULL,
  `data_do` date NOT NULL,
  PRIMARY KEY (`rel_klient_pokoje_id`),
  KEY `klienci_klient_id` (`klient_id`)
  KEY `pokoje_pokoj_id` (`pokoj_id`)
) ENGINE=InnoDB  DEFAULT CHARSET=utf8 COLLATE=utf8_polish_ci;

CONSTRAINT `jakasnazwa` FOREIGN KEY (`pokoje_pokoj_id`) REFERENCES `pokoje` (`pokoj_id`) ON DELETE restrict

2011-01-27 14:28:06 Post #14 nospor

ad5) Wiem co robi default. Pytam sie Ciebie co ma default do formatowania? Nic nie ma wiec nie widzę sensu go w ogóle dawać. Ale jak chcesz to dodaj. Bomba nie wybuchnie

Co do rat:
a jak klient bedzie mogl zaplacic w 5 ratach? Powie mu Pani, że nie pozwala? A jak zmieni zdanie? Bedziesz musial dorabiac kolejne pola na raty.
Nie prosciej więc z rat zrobić oddzielną tabelę i być przygotowanym na każdą okolicznosc?

2011-01-27 14:58:20 Post #15 bob

ad5)

Wiem co robi default. Pytam się Ciebie co ma default do formatowania?

NIc <zapeszony> hehe

Co do rat:
a jak klient bedzie mogl zaplacic w 5 ratach? Powie mu Pani, że nie pozwala? A jak zmieni zdanie? Bedziesz musial dorabiac kolejne pola na raty.
Nie prosciej więc z rat zrobić oddzielną tabelę i być przygotowanym na każdą okolicznosc?

Racja, a więc osobna tabelka na płatności, jak wróce do domu to przemysle i odpiszę około 18-20

Zostawi mi tylko wiadomośc, czy cały obecny kod (jeśli chodzi o poprawność kodową jest dobry?

pozdrawiam,
Robert

2011-01-27 15:20:16 Post #16 gość_koleś

Dlaczego będziesz robił wszystko na MySql, czemu nie SQL server albo firebird albo postgre?

Nospor w czym programowałeś w c++ tzn jakie miałeś IDE

2011-01-27 15:26:58 Post #17 nospor

Ujdzie w miare

Nospor w czym programowałeś w c++ tzn jakie miałeś IDE

Hehe, gdy ja programowałęm w c++ to jeszcze nie było IDE

2011-01-27 18:36:10 Post #18 bob

Dlaczego będziesz robił wszystko na MySql, czemu nie SQL server albo firebird albo postgre?

Dlatego, że przyjęliśmy z Robertem, że projekt będzie robiony na bardzo dobrej bazie jakiej jest MySQL, co nie znaczy, że nie możemy po tym projekcie zrobić na SQL Server.

(...)A , więc trzeba się teraz zastanowić co robimy z płatnościami.
Na pewno będzie można dodawać fakturę/y lub paragon/y lub tzw KP/y (kasa przyjęła) pod danego klienta. Będzie to wynikało z wpłat przez klienta:

Tzn jeśli klient zapłaci w dwóch wpłatach (ratach) to będą sporządzone dwie faktury lub paragony ..., jeżeli w 3 wpłatach to dostanie 3 faktury itp... Może też być taka sytuacja, że klient otrzyma dwie faktury i kp.

Chcę powiedzieć, że będzie trzeba zrobić możliwość dodania relacji klienta z np dwoma fakturami i paragonem etc..

Numery faktur, czy paragonów, czy kp będą wbijane ręcznie przez pracowników w pola i dodawane do danego klienta jak opisane wyżej.

A, więc sytuacja "podobna" do relacji klient-pokój/e, z tą różnicą, że w relacji klient pokój/e (budynki i pokoje) są wbite na sztywno do bazy.
Natomiast klient - dokumenty tutaj będziemy musieli dodać możliwość tworzenia i wprowadzania numerów faktur, paragonów, kp w zależności od klienta i późniejsze ich powiązania z danym klientem.

Raczej na pewno że przy rejestracji wymaganymi polami będą:

1
2
3
4
5
6
7
8

-nazwisko
-imię
-numer pokoju/ów
-ilość osób
-data od
-data do
-wartość_pobytu (wbita na sztywno przez pracownika)

reszta będzie możliwa również przy rejestracji, lecz nie wymagana od razu przy niej takie jak napisałem wcześniej:

1
2
3
4

nr_faktury/r
nr_paragonu/ów
nr_kp/ów

Dodatkowo pozostaje kwestia rodzajów pobytu np: indywidualny, spa, rehabilitacyjny etc..
Od nich jak było napisane wcześniej zależeć będzie kolor wypełnienia w grafiku.

Do poniedziałku napiszę dokładniej o tych rodzajach pobytów i resztę rzeczy związanych np z sumowaniem kolumny wartość_pobytu (tu prawdopodobnie będzie zwykła suma tej kolumny), ale dodatkowo sumy tej wartość, ale z podziałem dla poszczególnych rodzajów pobytów.

Tak samo będzie pewnie dla wpłat ogółem

Do poniedziałku wieczora max wszystko będę wiedział ostatecznie - wszystko dokładnie jeszcze opiszę i potwierdzę, gdyż będę rozmawiał o tym z pewną osobą i wszystko ładnie tutaj opiszę, aby kwestia zrozumienia działania była jasna, i aby nie trzeba było nic później zmieniać w naszej bazie Motelu.

pozdrawiam wszystkich z wyróżnieniem Roberta

,
Robert

2011-01-27 20:33:11 Post #19 gość_koleś

W takim razie jaki kompilator ci służył GCC?

2011-01-28 08:29:28 Post #20 nospor

Dlatego, że przyjęliśmy z Robertem, że projekt będzie robiony na bardzo dobrej bazie jakiej jest MySQL,

Ale proszę nie wciskać mi słów, których nie używałem. Zaproponowałeś mysql a mi to pasowało i tyle. I na pewno nie padło stwierdzenie "bardzo dobra baza"

W takim razie jaki kompilator ci służył GCC?

To było już tak dawno temu że nie pamiętam. No czymś to musieliśmy kompilować, więc pewnie albo gcc albo coś ala gcc

Brakuje mi tu jednak jeszcze tabeli zamówienia. Do tej pory taką rolę pełniła pokoje_klient, ale przecież klient w jednym zamówieniu może zająć kilka pokoi

Forum » Programowanie » Bazy danych

Motel C#+MySQL system

Ostatnio komentowane

Ostatnio na forum

Skrypty użytkowników

Kategorie

Blogroll

Reklama