![]() ![]() |
Post
#1
|
|
|
Grupa: Zarejestrowani Postów: 3 Pomógł: 0 Dołączył: 20.12.2013 Ostrzeżenie: (0%)
|
Witam,
Mam stworzyć bazę danych o temecie F1. Zaprojektowałem taki schemat i chciałem się dowieczieć czy jest ona dobry bo zaczynam dopieor tworzyć bazy i nie wiem czy dobrze to zrobiłem http://fotoo.pl/show.php?img=677404_bezantytua-u.jpg.html |
|
|
|
Post
#2
|
|
|
Grupa: Zarejestrowani Postów: 341 Pomógł: 40 Dołączył: 23.06.2009 Ostrzeżenie: (0%)
|
nie trzymasz sie zadnej konwencji, DuZeMaLeLiTEry do tego literowki,
słowem miszmasz, sprawia ze struktura jest nieczytelna. czy funkcjonalna...? nie wiem... ... bo nie wiem, co chcesz zrobić... J. |
|
|
|
Post
#3
|
|
|
Grupa: Zarejestrowani Postów: 3 Pomógł: 0 Dołączył: 20.12.2013 Ostrzeżenie: (0%)
|
jest to jedna z mich pierwszych baz i nie wiem jek je jeszcze towrzyć.
muszę stworzyć bazę a potem zrobić do niej zapytania : Tworzący widoki (co najmniej 3-5) oraz sekwencje (dla każdego klucza głównego). Usuwający wszystkie widoki oraz sekwencje. Usuwający wszystkie wiersze ze wszystkich tabel. Zawierający co najmniej 5-10 poleceń INSERT dla każdej tabeli. Zawierający po jednej instrukcji INSERT naruszającej każdy z typów ograniczeń (np. UNIQUE, NOT NULL, CHECK, klucza głównego, klucza obcego, itp) dla dowolnej tabeli. Modyfikujący dowolnie wybraną tabelę: • dodający kolumnę (np. test VARCHAR2(20)), • dodający ograniczenia do dodanej kolumny (np. NOT NULL), • usuwający ograniczenia dotyczące dodanej kolumny, • usuwający dodaną kolumnę. Zawierający co najmniej 10 – 15 zaawansowanych instrukcji SELECT wykorzystujących np.: • MIN, MAX, SUM, AVG, COUNT, • GROUP BY, • HAVING, • ORDER BY, • UNION, INTERSECT, MINUS, • EXISTS, IN, ALL, ANY, • CASE, • złączenie, • podzapytania, • funkcje np. do obsługi dat, testów, liczb, itd., • zapytania Tworzący co najmniej 7 - 10 procedur oraz funkcji zapewniających pełną obsługę bazy danych. Usuwający procedury oraz funkcje. Tworzący co najmniej 5-10 wyzwalaczy. Usuwający wyzwalacze. |
|
|
|
Post
#4
|
|
|
Grupa: Zarejestrowani Postów: 1 421 Pomógł: 310 Dołączył: 18.04.2012 Ostrzeżenie: (0%)
|
Na MySQL-u INTERSECT, MINUS, CHECK?
Zapomnij. |
|
|
|
Post
#5
|
|
|
Grupa: Zarejestrowani Postów: 341 Pomógł: 40 Dołączył: 23.06.2009 Ostrzeżenie: (0%)
|
przy projektowaniu najlepiej się trzymać jednej konwencji
są rożne, i tak naprawdę nie ma większego znaczenia którą wybierzesz, poza pustym dyskursem... wybierając jednak jedną metodę - trzeba się jej dość sztywno trzymać ja np. wszystkie nazwy piszę z małych liter, camel_case nazywanie indeksów tu też będziesz miał przynajmniej dwa wiodące nurty, np tabela 'samochody' to indeks do niej można odpowiednio z prefiksami: id_samochod id_samochody pk_samochod pk_samochody to samo, tylko z sufiksami samochod_id samochody_id samochod_pk samochody_pk lub tez bez prefiksów i sufiksów czyli samochod lub samochody osobiście, ostatnio piszę id_samochod niezaleznie czy to pk czy fk, dla mnie upraszcza zapytania, ale jest mniej czytelne być może. o ile dla nazw tabel w większości stosowana jest liczba mnoga, tak już dla indeksu są liczne dyskusje, w liczbie mnogiej ma być czy też nie. znam argumenty za i przeciw większością z tych konwencji. jaką byś nie wybrał, trzymając się jej ściśle - sprawiasz ze pisanie zapytań staje się prostsze (wystarczy znać nazwę tabeli, a resztę sobie dośpiewasz) ty tutaj - piszesz jak ci się uda... np.: Cytat Kierowca_has_WYSCIG Kierowca_Team_ID_team Kierowca_ID_kierowca WYSCIG_idWYSCIG brak jakiejkolwiek konsekwencji jest widoczny z daleka... (IMG:style_emoticons/default/questionmark.gif) nie wspominam już o tym ze złe relacje są tutaj zrobione. ja osobiście tą tabelę zrobił w ten deseń Cytat kierowcy_has_wyscigi id_kierowca id_wyscig dodawanie id_team jest w tej relacji bez sensu. z tego co piszesz- to czeka Cie duuuzo pisania kodu, i warto jest ułatwić sobie pracę... ** część z tego co napisałeś nie jest dostępne bezpośrednio w mysql, ale chyba wszystko da się rozpisać w zastępczy sposób |
|
|
|
Post
#6
|
|
|
Grupa: Zarejestrowani Postów: 341 Pomógł: 40 Dołączył: 23.06.2009 Ostrzeżenie: (0%)
|
eh,
w pierwszym rzucie popraw ortografy w bazie, jesli to praca zaliczeniowa - to dosc kiepsko bedzie wygladac. czy kierowca może być tylko w jednym zespole? można tak założyć tylko dla uproszczenia, często po sezonie kierowca zmienia team. ja bym zmienił na relację n:n samochod, co ma sie kryc pod polami 'opony' i 'silnik'? sponsor... budrzet (IMG:style_emoticons/default/thumbsdownsmileyanim.gif) pomijając, tutaj nie rozumiem pola id_team zwłaszcza ze dalej masz relacje n:n ..? mechanik nie jestem przekonany co do specjalnosci - tutaj wychodzi ze mechanik może mieć tylko jedna... a tak raczej nie jest.. nie za bardzo łapię jak chcesz zapisywać tabele przebieg, nie wydaje mi sie to tutaj za bardzo przemyślane. no i nie mam pojęcia o tabeli student... Ten post edytował alegorn 30.12.2013, 11:17:52 |
|
|
|
Post
#7
|
|
|
Grupa: Zarejestrowani Postów: 3 Pomógł: 0 Dołączył: 20.12.2013 Ostrzeżenie: (0%)
|
|
|
|
|
Post
#8
|
|
|
Grupa: Zarejestrowani Postów: 341 Pomógł: 40 Dołączył: 23.06.2009 Ostrzeżenie: (0%)
|
stajnia samochod - tutaj cos mi nie gra z ta relacja..
poza tym na pierwsz rzut oka wydaje sie w miare ok... to juz zalezy od projektu.. pozdrawiam, J |
|
|
|
![]() ![]() |
|
Aktualny czas: 24.12.2025 - 19:48 |