Forum PHP.pl > [MySQL][PHP] pomoc w zaprojektowaniu bazy

Pomoc - Szukaj - Użytkownicy - Kalendarz

Pełna wersja: [MySQL][PHP] pomoc w zaprojektowaniu bazy

skubi23t

16.10.2012, 11:24:01

Witam,
Na wstępie zaznaczę tylko, że jestem mocno początkującym i wczytuje się w temat struktury baz danych i php.

Za zadanie mam stworzyć prostą witrynę opartą na bazie danych i php, na której to student po zalogowaniu się będzie miał dostęp do SWOICH wyników z kolokwiów/egzaminów z trwającego semestru akademickiego.

Ustaliłem sobie, że studenci będą dodawani przez wykładowcę / administratora, a ich loginem będzie numer albumu ( jest unikalny dla każdego ).
Hasłem będzie powiedzmy 5 ostatnich cyfr numeru pesel (z późniejszą możliwością zmiany).
Dodatkowe pola to jeszcze Imię i nazwisko, więcej raczej nie potrzebuje (?)

Nauczyciele/wykładowcy będą logowali się swoimi ustalonymi loginami i hasłem.
Mają oni mieć możliwość dodawania przedmiotów , a następnie przypisywania do tych przedmiotów swoich studentów.
Następnie mieliby możliwość dodania np. kolokwium 7.10 i wpisania wyników dla wszystkich studentów których ma zapisanych na dany przedmiot.

I tutaj mam problem jak to rozgryźć... rozumiem, że będę potrzebował 2 tabeli jednej dla studenta drugiej dla nauczyciela.
Trzecią tabelę trzeba by utworzyć dla listy przedmiotów jak rozumiem, do której nauczyciele będą dopisywali swoje przedmioty?

Ogólnie wszystko jest w fazie pomysłu, a jako, że jestem mocno początkujący piszę bo pewnie wielu z was ma więcej / lepsze pomysły jak to zorganizować..

Dochodzi jeszcze problem studentów dziennych / zaocznych , dalej ich specjalizacji... mix mam w głowie trochę liczę na wasze rady i pomoc...

Pozdrawiam

csharp

16.10.2012, 11:42:11

zrób sobie tabele studentów, gdzie będziesz trzymać wszystkie info o nich (ranga, numer albumu, imię, nazwisko, hasło, mail, etc.)
zrób tabele uprawnienia i tam stwórz kilka. Całość połącz relacją np. tabela studencji->ranga = uprawnienia->id

i na podstawie tego rozpoznawaj czy osoba zalogowana może dodawać userów czy nie..

dalej zrób sobie tabele przedmioty i tam je wszystkie wyszczególnij.

następnie kolejna tabela przedmioty połączone z userem i też relacja

gdzie będziesz trzymał id przedmiotu i id usera.

itd, itd.. całość oparta na relacjach najlepiej.

frantic09

16.10.2012, 11:44:06

Hej!

Przemyśl sobie wszystko po kolei, czego potrzebujesz. Z tego co widziałem to pewnie będą Ci potrzebne tabele dla
- studentów
- nauczycieli (adminów) - chociaż to można ewentualnie zrobić z tabelą studentów i wtedy wspólną tabele nazwac USERS, a rozdzielać studentów od nauczycieli poprzez np pole admin (0 lub 1, jeśli 1 to będzie nauczyciel)
- przedmiotów
- kolosów i egzaminów
- ocen studentów

Przyda się jeszcze tabela łącząca studentów z przedmiotami
- student2przedmiot

AD. Problem studentów dziennych i zaocznych. Wg mnie wystarczy pole w tabeli studentów o nazwie np TRYB o typie ENUM('d','z')

Poza tym trochę mało danych podajesz. Musisz rozważyć wszystkie połączenia między tabelami w bazie. Wiadomo, że np nauczyciel może założyć n przedmiotów, że może wpisać n kolosów. Wiemy też, że student może dostac tylko jedną ocenę z kolosa (tak/nie?). Poza tym wielu studentów może być przypisanych do wielu przedmiotów równocześnie.

Własnie powyżej masz przykłady połączeń/relacji tabel o typach odpowiednio 1:n, 1:1, n:n. Przemyśl to sobie, jakbyś chciał żeby to wyglądało (dokładnie przemyśl!). Później zastanowisz się jakie dane chcesz / musisz przechowywać w poszczególnych tabelach.

skubi23t

16.10.2012, 12:02:28

Dzięki za szybką odpowiedź...

Jakoś bezpieczniejszym wydaje mi się utworzenie osobnej tabeli dla nauczycieli i tak mam w planie zrobić.

Odnośnie toku studiów to faktycznie można zastosować ENUM d,z dzięki za radę...

Dalej...

Tabele przedmiotów faktycznie jestem w stanie wygenerować, ale tutaj pojawia się problem, bowiem jedne i te same labolatoria mogą być prowadzone dla 2 grup przez różnych nauczycieli i nie bardzo wiem co z tym fantem zrobić?

Druga sprawa 1 ocena za 1 koło/egzamin ale nie jestem w stanie przewidzieć ile faktycznie będzie tych kół / egzaminów / poprawek.. ( nie będzie to duża ilość, ale może to być 0 a może być 5 ). W przypadku poprawki nauczyciel wpisuje kolejną ocenę jako poprawa powiedzmy..

Sprawa trzecia o której pisał frantic - jeden student będzie przypisany do kilku/kilkunastu przedmiotów. Po zalogowaniu ma po prostu wgląd do wszystkich, które ma w planie danego semestru i nie ważne czy były tam jakieś kolokwia czy nie...

Trochu na głęboką wodę się rzuciłem wiem..

bostaf

16.10.2012, 13:47:14

Cytat(skubi23t @ 16.10.2012, 13:02:28 )

Jakoś bezpieczniejszym wydaje mi się utworzenie osobnej tabeli dla nauczycieli i tak mam w planie zrobić.

To nie jest ani bezpieczniejsze ani mądrzejsze. Wręcz przeciwnie - to pierwszy krok w stronę bezkresnych i jałowych pól oznaczonych tabliczką "Naprawdę duże problemy". To odwracanie się plecami do najlepszych standardów opracowanych przez najmądrzejszych tego świata. Myślisz, że ludzkość wymyśliła postacie normalne, klasy, hermetyzację, dziedziczenie i relacje po to, żeby Tobie się coś wydawało?

Bardzo dobrze zasugerował Ci frantic09: jedna tabela o nazwie "users". Bo oba podzbiory, o których mowa: studenci i nauczyciele, należą do jednego zbioru userów/ludzi. Różnią się tylko funkcją spełnianą w danej organizacji - kolejnym zbiorze nie mającym części wspólnej ze zbiorem userów/ludzi. Oba zbiory (klasy) łączy relacja pośrednia: user->funkcja->organizacja, organizacja->funkcja->user. Jeden user może mieć jedną lub więcej funkcji w organizacji (bo co za problem, żeby wykładowca był równocześnie studentem?).
Jeśli jesteś 100% pewien, że jeden człowiek może pełnić tylko i wyłącznie jedną funkcję, wtedy możesz zrobić tak jak zaproponował frantic09 - funkcję przechowywać w dodatkowej kolumnie, ale nie o nazwie "admin" (po co tak bałaganić?), tylko po prostu "funkcja" - niech to będzie semantyczne, czytelne: funkcja usera to student lub nauczyciel, i wszystko jasne na pierwszy rzut oka.

Cytat(skubi23t @ 16.10.2012, 13:02:28 )

Tabele przedmiotów faktycznie jestem w stanie wygenerować, ale tutaj pojawia się problem, bowiem jedne i te same labolatoria mogą być prowadzone dla 2 grup przez różnych nauczycieli i nie bardzo wiem co z tym fantem zrobić?

Myśl obiektowo. Odpowiedź jest w pytaniu. To pytanie to piękny przepis na elegancką strukturę danych.

skubi23t

9.11.2012, 11:41:16

Posiedziałem , poczytałem i wyszło mi coś takiego jak w pliku niżej.
http://www.sendspace.pl/file/685834d2e26cf3f73236617

Mam teraz pytanie - czy mogę użyć jakiegoś gotowego CMS typu joomla ( ewentualnie którego najlepiej ) i to wkomponować czy muszę samemu pisać system logowania itd? Co łatwiejsze?

nospor

9.11.2012, 11:47:16

ACTIVE INT NOT NULL DEFAULT 0 -- 0-AKTYWNY, 10-NIEAKWTYWNY
yyy.... czemu 10 to nie aktywny? Jakaś logika czy tak strzał na chybił trafił?

Skoro pole nazywa się ACTIVE to nazwa zobowiązuje do raczej czegoś takiego:
1 - aktywny
0 - nie aktywny
i typ nie INT a TINYINT. Oszczędzaj jak nie musisz walić bajtami na lewo i prawo

PASSWORD VARCHAR(100) NOT NULL, -- Haslo, jednak promonowal bym zrobic kolumne hashujšca np md5 i przy logowanie bedzie odszyfrowywal i sprawdzal
Skoro zamierzasz dawać hash to hash ma np. 32 znaki więc też nie musisz udeżać w 100. Pozaty hasha się nie odszyfrowuje tylko porównuje z innym hashem

"Przy logowaniu zapisze sobie np w cookies USERID, Firstname,LastName, Permition ktore sie przydadza np przy wyswietlaniu danych, edycji i dodawaniu nowego rekordow"
Takie rzeczy trzyma się w SESJI a nie w ciachu.

skubi23t

9.11.2012, 11:51:56

Cenne uwagi - właśnie po to wrzuciłem tą bazę. Już się biorę za zmianę tych pól. Odnośnie tego md5 to właśnie nie wiem jak to zrobić... no i nie wiem czy muszę wszystko pisać sam czy jest szansa na wykorzystanie do tego celu jakiegoś cms typu joomla..

nospor

9.11.2012, 12:03:55

W bazie masz trzymać hash hasła (powiedzmy te md5) a potem podczas logowania hashujesz to co user wprowadził do forma a następnie ten hash porównujesz z hashem z bazy. Jak się zgadzają, znaczy ze ok. No i oczywiście musisz jeszcze login sprawdzic

Masz bardzo dziwny system nazewnictwa... np, tu:
PERMITION INT NOT NULL, -- Uprawnienia, 0 - Admin, 10 - Rektor, 11 - Rektor moze tylko dodawac,12 - Rektor moze tylko edytowac, 13 - tylko podglad, 20 - wykladowca, 21 - tylko dodawanie, 22-tylko edycja, 23 - tylko podglad, 30 - Dziekanat,31 - Mozna dodawać, 32 - mozna edytowac,33 - tylko podglad, 40 - Student, 41-moze tylko dodawać, 42-moze tylko edytować 43 - tylko podglad
0 to admin. zazwyczaj 0 kojarzy się z niczym, czyli prawo 0 powinno oznaczać że nie może nic.
Pozatym nawaliłeś tutaj na każde prawo numerek a w takim systemie nie da się tych praw łączyć ze sobą. Proponowałbym ci zrobić tutaj to na maskach bitowych przez co byś ustalił parę podstawowych praw a potem mógł je łączyć jak dusza zapragnie
http://nospor.pl/opcje-dwuwartosciowe-przechowywanie.html

Skoro masz takie rozdziały jak:
10 - Rektor, 11 - Rektor moze tylko dodawac,12 - Rektor moze tylko edytowac
to proponowałbym ci zrobić tak:
pole TYPE (student, rektor, dziekanat, admin)
pole RIGHTS - i tutaj maska bitowa o której ci wspomniałem.
Wówczas byś miał typy userów a mimo to byś mógł im dawać takie prawa jak uważasz. Jeden rektor by mógł dodawać, a drugi już nie.
Tylko wówczas nie byłoby już prawa 11 - Rektor moze tylko dodawac,12 - Rektor moze tylko edytowac a byłoby poprostu:
edycja, dodawania, kasowanie, podgląd

skubi23t

9.11.2012, 14:49:41

Faktycznie najlepiej byłoby dodać 4 opcje jak wyżej i tylko dodawać je lub nie dla użytkownika...

Kurcze czytam o tych maskach i nie bardzo wiem jak to przełożyć z tego mojego dzikiego systemu... może ktoś mnie pokierować co powinienem zmienić?

nospor

9.11.2012, 15:06:16

No ale przecież masz tam podany działający przykład. Nic tylko skopiować i wsadzić do siebie.

skubi23t

9.11.2012, 15:08:12

To musi być utworzone w nowej tabeli czy może zostać w tym PERMITION?

nospor

9.11.2012, 15:55:11

Nie w oddzielnej tabeli. Pole PERMITION co masz teraz masz zamienić na te maski.

skubi23t

9.11.2012, 16:01:51

Logowanie w najprostszej postaci już mam , hasło w bazie zapisywane jako MD5 i porównywane jak pisałeś.

Teraz muszę uporać się z tym PERMITION, a następnie do mojego logowania dodać sesję w której to będą zapisywane odpowiednie dane mi potrzebne. Dobrze myślę?

nospor

9.11.2012, 16:05:05

Skoro już jesteśmy przy haśle i md5 to zapoznaj się z tym:
http://forum.php.pl/index.php?showtopic=44...t=0&start=0
a dowiesz sie czemu już teraz md5 nie jest bezpieczny

I tak, po zalogowaniu się do sesji wrzucasz niezbędne dane zalogowanego usera: ID, imie, nazwisko.

skubi23t

9.11.2012, 17:00:22

Cytat(nospor @ 9.11.2012, 12:03:55 )

Skoro masz takie rozdziały jak:
10 - Rektor, 11 - Rektor moze tylko dodawac,12 - Rektor moze tylko edytowac
to proponowałbym ci zrobić tak:
pole TYPE (student, rektor, dziekanat, admin)
pole RIGHTS - i tutaj maska bitowa o której ci wspomniałem.
Wówczas byś miał typy userów a mimo to byś mógł im dawać takie prawa jak uważasz. Jeden rektor by mógł dodawać, a drugi już nie.
Tylko wówczas nie byłoby już prawa 11 - Rektor moze tylko dodawac,12 - Rektor moze tylko edytowac a byłoby poprostu:
edycja, dodawania, kasowanie, podgląd

W sumie to mam już coś jak TYPE - jest to pole USERTYPEID z opcjami: Administrator, Dziekanat, Pracownik naukowy, Student

Pole RIGHTS jak rozumiem mam dodać do tej samej tabeli co USERTYPEID czyli DICTIONARIES?

I teraz jak zaprogramować te pole?

Chyba się już dziś poddam i wychodzę stąd bo bania zamieszana z tego wszystkiego...

nospor

9.11.2012, 17:09:34

Napisałem ci przecież ze RIGHTS to twoje PERMITION czyli ma to być w tabeli USERS a nie w żadnym słowniku.
RIGHTS to pole typu INT. Na dobrą sprawę to pole PERMITION co masz teraz to może być tym polem RIGHTS tylko masz tam wkładać wartości tak jak podałem w arcie.

1 - dodawanie
2 - edycja
4 - usuwanie
8 - podglad
To są podstawowe wartosci. Łącząc je bitowo tak jak pisałem w arcie będziesz miał dane prawa. Przeanalizuj ten przykład który dołączyłem, on jest działąjącym skryptem który zapisuje i wyszukuje.

skubi23t

9.11.2012, 20:23:39

1 - dodawanie
2 - edycja
4 - usuwanie
8 - podglad

15 - Administrator / Dziekanat / Pracownik Naukowy - komplet uprawnień
8 - Student - podgląd

Najpierw sprawdzamy po USERTYPEID kim jest zalogowany ( Administrator / Dziekanat / Pracownik Naukowy / Student ) i np. dla pliku rejestracji nowego użytkownika zezwalamy na to tylko Administratorowi i Dziekanatowi więc sprawdzamy zarejestrowanego pod tym kątem + sprawdzamy PERMITION , czyli uprawnienia jakie posiada dany typ - czy aby na pewno w tym przypadku jest to 15 tj komplet uprawnień...

Dobrze to zrozumiałem?

Tak na prawdę, to jedynie Student ma mieć podgląd do swoich danych, Dziekanat ma mieć możliwość dodawania nowych użytkowników ( w tym Pracowników naukowych ), Pracownicy naukowi mogą przypisywać sobie przedmioty + studentów + wystawiać oceny tudzież je edytować/kasować, no i Admin ma być wszechmogący.

nospor

10.11.2012, 09:23:48

Musisz się zdecydować czy ty prawa rozpoznajesz po typach czy po PERMITION. Bo jeśli po typach, to PERMITION ci do niczego nie jest potrzebne. A jeśli jednak prawa masz zamiar rozpoznawać po PERMITION, to nie ma sensu byś sprawdzał jeszczy typ usera. Albo jedno albo drugie. NIe komplikuj sobie życia.

skubi23t

12.11.2012, 23:22:15

Zacząłem tworzyć proces logowania i rejestracji użytkownika... taki oto formularz mi wyszedł:

Kod

<form action="register.php" method="POST">
    <ul>
        <li>
            Typ użytkownika:<br>
                <select name="USERTYPEID">
                    <option value='4'>Student</option>
                    <option value='3'>Pracownik naukowy</option>
                </select>
        </li>
        <li>
            Tytuł:<br>
                <select name="TITLEID">
                    <option value='100'>brak</option>
                    <option value='101'>inż.</option>
                    <option value='102'>mgr</option>
                    <option value='103'>mgr inż.</option>
                    <option value='104'>dr</option>
                    <option value='105'>dr inż.</option>
                    <option value='106'>dr hab.</option>
                    <option value='107'>dr hab. inż.</option>
                    <option value='108'>prof. dr hab.</option>
                    <option value='109'>prof. dr hab. inż.</option>
                    <option value='110'>prof. zw. dr hab. inż.</option>
                </select>
        </li>
        <li>
            Numer Indeksu*:<br>
            <input type="text" name="INDEXNUMBER">
        </li>
        <li>
            Hasło*:<br>
            <input type="password" name="PASSWORD">
        </li>
        <li>
            Powtórz hasło*:<br>
            <input type="password" name="PASSWORD_AGAIN">
        </li>
        <li>
            Imię*:<br>
            <input type="text" name="FIRSTNAME">
        </li>
        <li>
            Nazwisko*:<br>
            <input type="text" name="LASTNAME">
        </li>
        <li>
            Uprawnienia*:<br>
            <input type="checkbox" name="PERMITION[]" value="1" checked="checked" />Podgląd
            <input type="checkbox" name="PERMITION[]" value="2" />Dodawanie
            <input type="checkbox" name="PERMITION[]" value="4" />Edycja
            <input type="checkbox" name="PERMITION[]" value="8" />Usuwanie
        </li>
        <li>
            Konto:<br>
            <input type="radio" name="ACTIVE" value="1" checked="checked" />Aktywne
            <input type="radio" name="ACTIVE" value="0" />Nieaktywne
        </li>
        <li>
            Adres e-mail:<br>
            <input type="text" name="EMAIL">
        </li>
        <li>
            <input type="submit" value="Rejestruj">
        </li>
    </ul>
</form>

I jest problem z tym permition bo dane wychodzące z niego są tablicą...

Warning: mysql_real_escape_string() expects parameter 1 to be string, array given in C:\wamp\www\projekt\core\functions\general.php on line 3

Jak w takim razie powinienem zabezpieczyć dane?

d3ut3r

12.11.2012, 23:27:29

Coś słabo czytałeś to co @Nospor napisał

jeżeli robisz usertype to odpuść sobie permition bo się powtarzasz ... jeżeli chcesz zostać przy permition to przeczytaj jeszcze raz artykuł nospora o maskach bitowych i złóż 1 bajt z wartości które masz w tablicy permition i ten bajt zapisz do bazy danych.

skubi23t

12.11.2012, 23:31:17

Jeżeli zostawię samo USERTYPE to nie mam możliwości indywidualnego ustawienia dla każdego użytkownika z osobna. Dlatego też chcę zrobić PERMITION, a ten typ użytkownika przyda się tak czy siak w innym miejscu.

Bajt sobie zapisuje, ale problem chyba mam inny?

d3ut3r

12.11.2012, 23:41:08

Napisałeś:

Cytat

I jest problem z tym permition bo dane wychodzące z niego są tablicą...

Dlatego Ci odpisałem, że do bazy nie masz wrzucać tablicy a masz wrzucić liczbę całkowitą.

[PHP] pobierz, plaintext 
 
 
if (is_array($_POST['PERMITION'])){
 
  $mask=0;
 
  foreach ($_POST['PERMITION'] as $perm){
     $mask|= (int)$perm;
  }
 
} 
 
[PHP] pobierz, plaintext

nospor

13.11.2012, 06:59:41

Cytat

jest problem z tym permition bo dane wychodzące z niego są tablicą...

Ty w ogóle nie przeczytałeś tego co ci podałem. Przecież dokładnie masz tam wyjasnione że właśnie dane na wyjściu są tablicą. Masz dokładnie wyjaśnione jak je masz odbierać i jak masz z nich zrobić liczbę.... Marnujesz i swój i nasz czas.

skubi23t

19.11.2012, 17:19:01

Trochę mnie nie było, ale uporałem się z "problemem" i rejestracja użytkowników działa - dziękuje d3ut3r. Zabezpieczyłem w prawdzie już dostęp przed niezalogowanymi ale domyślnie dostęp do niej mają mieć tylko użytkownicy o USERTYPEID = 1 lub 2 - cała reszta nie. I nie wiem jak to zrobić.. Jakaś wskazówka? Pod $user_data['USERTYPEID'] mam zapisane ile wynosi właśnie ta wartość aktualnie zalogowanego użytkownika..

d3ut3r

19.11.2012, 18:26:40

zrób po prostu warunek

[PHP] pobierz, plaintext 
 
if ($user_data['USERTYPEID'] != 1 && $user_data['USERTYPEID'] !=2){
 
  //przekierowanie na stronę typu "nie masz wystarczających uprawnień"
 
}
 
// tutaj dalszy kod
 
[PHP] pobierz, plaintext

skubi23t

25.11.2012, 16:26:20

Dzięki - źle formowałem tego if'a stąd pewnie nie do końca to działało jak powinno. Teraz jest już ok.

Ustawiłem autowylogowanie po 15min , jednak chyba nie do końca to przemyślane rozwiązanie, bo jak nauczyciel zacznie coś dodawać a minie mu 15min to co wpisal przepadnie...
Wiem, że można to jakoś jeszcze inaczej zrobić - by wylogowało jedynie użytkowników którzy są nieaktywni ( nie poruszają się po stronie ), tylko nie bardzo wiem jak to zrobić.
Pewnie trzeba by dodać jakieś pole w users typu time i jakoś to sprawdzać?

Druga sprawa - zastanawiam się jak powinien wyglądać panel dodawania ocen dla nauczyciela... nie bardzo wiem jak go rozwiązać , nie mam wyobrażenia jak powinien on wyglądać... W koncu nie kazdy student się pojawia na każdym terminie koła np. i w ogóle dużo się nad tym zastanawiałem, ale nie wyobraziłem sobie czegoś do czego powinienem dążyć stąd piszę z poradą do was jak waszym zdaniem powinno to być skonstruowane

To jest wersja lo-fi głównej zawartości. Aby zobaczyć pełną wersję z większą zawartością, obrazkami i formatowaniem proszę kliknij tutaj.