viamarimar
23.12.2014, 18:55:44
Poki co uzywam bazy "zapchanej" delkiatnie mowiac czyli wszystko w jednym. Stwierdzam jednak ze chce zaczac uzywac zlaczec i chce jak najbardziej porozbijac tabele w bazie i spytac czy na przykladowej strukturze ktora stworzylem jest wszystko maksymalnie rozbite czy da sie rozbic jeszcze bardziej( wiem ze takie rozbijanie ma swoja nazwe ale zapomnialem). Nikt nie jest idealny.
Wiec tak:
Ces_x -tabela
y -zawartosc x
y -zawartosc x




przepraszam za taka forme nie umialem inaczej tego dodac, pisalem w notatkach w telefonie a potem nie chcialo sie na kompa przezucic ;/
Nie wiem jak rozbijac takie tabeli jak news, powaidomienia, link bo schamat jest jeden?
Czy np daty osobno? i znow zlaczenie?
Co powinno byc osobno?
cisu
31.12.2014, 13:38:33
Nie wiem po co przenosisz np. hasła do osobnej tabeli. Jak jest relacja "1 do 1", to bardzo często - jak i w tym przypadku - nie robi się osobnej tabeli, bo to nadmiarowość danych.
Idea wydzielania danych do osobnych tabel polega (przeważnie) na wielokrotnym wykorzystaniu wydzielonych danych. W ten sposób usuwa się nadmiarowość danych w tabeli.
Relacje, które porobiłeś tutaj, powodują, że w relacji 1 do 1 zapisujemy dane w osobnej tabeli, powodując nadmiarowość danych w postaci powtarzającego się np. ID_LOGIN. Może nie są to ogromne ilości danych (chociaż to pojęcie względne, zależne od wielkości aplikacji), ale po prostu powinno się tego unikać.
Rozpisz sobie to wszystko na KARTCE (nie w telefonie), popatrz, co będzie się powtarzać i to powydzielaj do osobnych tabel. Potem znowu popatrz i popraw kolejne błędy i tak do skutku. Na kartce robi się to łatwiej, niż poprawiając już napisany fragment aplikacji (i o wiele szybciej).
Przykład
Popatrz na tabelę z ogłoszeniami. Masz tam pola TYP i KATEGORIA. Jak masz zamiar zapisywać tam kategorię i typ w postaci ich nazwy, to to jest błąd; to jest właśnie część do wydzielenia do osobnej tabeli.
Zrób osobną tabelę na kategorie (z polami ID i NAZWA) i osobną tabelę na typy (z polami ID i NAZWA) i tabeli z ogłoszeniami przechowuj jedynie ID typu i ID kategorii.
Po co? Powodów jest kilka (na przykładzie kategorii):
- powtarzalną częścią przechowywaną w tabeli z ogłoszeniami będzie ID kategorii, to z kolei eliminuje nadmiarowość danych, bo jej nazwę przechowujesz w jednym tylko miejscu
- jak będziesz chciał zmienić nazwę kategorii, to zmienisz nazwę w jednej tabeli i z automatu masz zmienioną wszędzie
- jak będziesz dodawał jakieś ogłoszenie to możesz być pewny, że będziesz popełniał literówki w nazwie kategorii - literówek natomiast nie będzie, gdy taką nazwę będziesz wybierał z rozwijanej listy zawierającej wszystkie kategorie
- jak będziesz chciał przenieść ogłoszenie z jednej kategorii do drugiej, to zmieniasz mu ID kategorii (wybierając z listy, więc nie będzie literówki) na inne, zamiast zmieniać ręcznie nazwę kategorii w ogłoszenie (wpisując ręcznie, więc literówka bardzo możliwa)
- z uwagi na możliwe błędy w nazwach kategorii przeszukiwanie ogłoszeń po nazwie kategorii jest z góry skazane na niedokładność - zamiast tego wybierzesz z listy kategorię, z której ogłoszenia chcesz wyświetlać i masz wszystkie pobrane bezbłędnie
- powiedzmy, że chcesz, żeby ogłoszenia z jakiejś kategorii były wyświetlane na stronie głównej jako promowane. I teraz możesz wyszukiwać takie po nazwie kategorii (co będzie niedokładne), ale możesz też dodać w tabeli KATEGORIE pole PROMOWANE i ustawić je na TRUE. Roboty tyle co nic i zrobione.
Czepiam się tych literówek, ale nie bez powodu. O ile ogłoszenia może dodawać tylko właściciel strony i stara się, żeby takich błędów nie było, to aplikacja może względnie dobrze działać. Ale nie masz co liczyć, że jak pozwolisz dodawać ogłoszenia innym użytkownikom internetu, to będą równie dokładni i staranni. Po prostu tak nie będzie. Dlatego należy udostępnić narzędzie, które możliwości popełniania przez użytkowników błędów redukuje do minimum.
Poza tym wszystkim jedną z ważniejszych rzeczy jest konsekwentność w nazewnictwie. Nie pisz na przemian "Nazwakodowa" i "Kodowa nazwa". To może i tylko projekt schematu, ale jak takie coś robi się źle, to reszta zazwyczaj wychodzi gorzej.
Powodów jest więcej, to są najważniejsze. Jak projektujesz aplikację czy bazę danych, to pomyśl, że kiedyś będziesz ją rozbudowywał i że powinieneś zrobić aplikację tak, żeby jak najłatwiej było ją rozbudować.
Można by tak długo, bo to temat rzeka, ale mam nadzieję, że streściłem te najważniejsze rzeczy. Jak będziesz potrzebował pomocy to pisz na PW.