Witaj Gościu! ( Zaloguj | Rejestruj )

Forum PHP.pl

 
Reply to this topicStart new topic
> Baza danych F1
pawulon92
post
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
Go to the top of the page
+Quote Post
alegorn
post
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.
Go to the top of the page
+Quote Post
pawulon92
post
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.
Go to the top of the page
+Quote Post
mmmmmmm
post
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.
Go to the top of the page
+Quote Post
alegorn
post
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
Go to the top of the page
+Quote Post
alegorn
post
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
Go to the top of the page
+Quote Post
pawulon92
post
Post #7





Grupa: Zarejestrowani
Postów: 3
Pomógł: 0
Dołączył: 20.12.2013

Ostrzeżenie: (0%)
-----


a coś takiego (IMG:style_emoticons/default/questionmark.gif)
http://fotoo.pl/show.php?img=691187_baza.png.html
Go to the top of the page
+Quote Post
alegorn
post
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
Go to the top of the page
+Quote Post

Reply to this topicStart new topic
2 Użytkowników czyta ten temat (2 Gości i 0 Anonimowych użytkowników)
0 Zarejestrowanych:

 



RSS Aktualny czas: 24.12.2025 - 19:48