Sprawdzenie poprawności schematu bazy danych

0

Witam,

Proszę o sprawdzenie poprawności schematu bazy danych:
http://i57.tinypic.com/21b3axx.jpg

edit:
Sorry, za to że zapomniałem o opisie. Tworze serwis internetowy na zaliczenie, będzie to księgarnia internetowa. Jeśli chodzi o admina który jest varcharem w login_details będzie tam zapis dotyczacy panelu do którego będzie przekierowany na admin lub user. Book_price zmieniłem. Tak wygląda po poprawce:
http://i59.tinypic.com/2nle5go.png

3

I rozumiem że wg ciebie nie warto napisać co to za baza danych? Bo na oko to jest jakiś WTF... Anyway na moje oko niewiele tam jest dobrze.

  • login details, co to za "admin" będący varcharem?
  • orders, co to za varchar id books (gdzie ta tabela w ogóle z books nie jest powiązana...)
  • books, book price jako varchar? o_O
0

Na początek proponuję ujednolicić nazywanie pól ID w tabelach.

0

Ale to nadal nie ma sensu.

  1. Nie rozumiem po co ci ten book type powiązany 1:1 z book. Tylko po to żeby było 1:1 gdzieś? o_O
  2. Nazywaj te tabele po ludzku! Co to jest "orders_pom"? Już abstrahuje nawet że zapewne chodzi o tabelę "pomocniczą" więc mieszasz 2 języki (ang i pl)... Nazwij tą tabelę jakoś sensownie.
  3. Jedno zamówienie może być powiązane z wieloma loginami? W jaki sposób to miałoby działać? To jest aukcja jakaś gdzie wielu użytkowników licytuje to samo na raz?
  4. Czemu to User (login details) jest powiązany z książką a nie Order? Jak dla mnie to w Order spodziewałbym się informacji o tym co kupuje.
  5. Mogę zamówić na raz tylko jedną książkę?

Weź ty może rzuć okiem na jakiegoś Northwinda, bo póki co to wygląda na jakieś tworzenie bazy metodą Monte-Carlo.

0

Patrzyłem na tego Nothwinda i zrobiłem coś takiego czy teraz to lepiej wygląda?
Dane do customer będę podawał z formularza który będzie na stronie, tylko zastanawiam się czy login_details jest dobrze połączone.
http://i61.tinypic.com/245kpyc.png

0

Prawie. Teraz nie rozumiem czemu login details wiąże się z orderem a nie z customerem.

0

Właśnie nie wiedziałem do czego to połączyć. Czyli jak połączę login_details z customerem 1:1 będzie git?

0

No ale po co ci tam 1:1? Takie powiązanie musi mieć sens praktyczny! Na przykład często korzystasz tylko z pewnego podzbioru danych. Albo część danych jest duża (np. dane binarne, zdjęcie czy coś) a są rzadko używane.

0

ok zmieniłem na 1:n. Thx za pomoc

1

Ty tak poważnie? A jaki to teraz ma sens? Jeden klient ma wiele loginów czy też jeden login przydzielasz wielu klientom? Ewidentnie robisz to metodą Monte-Carlo...

0

to w jaki sposób to powiązać?

0

Skoro dane są 1:1 to złącz je w jedną tabelę !

0

Pomyśl od początku. CO trzeba zrobić aby serwis działał poprawnie.

1) Mamy księgarnię internetową. Na pewno więc potrzebujemy książki.

Tworzymy tabelę książki (id, autor, tytuł, wydawnictwo).

2) Ok, co dalej? Przeanalizujmy. Jest to księgarnia, więc książki sprzedajemy.

Tworzymy więc tabele Zamówienie (id zamówienia, id książki) oraz modyfikujemy tabele książki dodając kolumnę cena.

3) Przydałoby się jednak komuś tą książkę sprzedać.

Tworzymy tabelę Użytkownik (id, login, email, adres), modyfikujemy tabele zamówienie o pole id użytkownika.

Na ta chwile tabele powinny wyglądać tak:

Ksiazki (id, autor, tytul, wydawnictwo, cena), zamowienie(id_zamowienia, id_ksiazki, id_uzytkownika) oraz uzytkownik (id, login, email, adres).
Relacje zas to uzytkownik (jeden do wielu) zamowienie, zamowienie (jeden do jeden) ksiazki.

To nie jest gotowe rozwiązanie! :)

Cena danej książki może się zmieniać (promocje, przeceny itp), nikt tez nie chce kupować tylko jednej książki naraz, użytkownik może być również administratorem, wiec tez przydałoby się wykryć czy dana osoba ma odpowiednie uprawnienia. Myśląc w ten sposób spokojnie rozbudujesz sobie w miarę sensownie strukturę bazy danych (pamiętaj, że relacje wraz z rozbudową mogą się zmieniać).

1 użytkowników online, w tym zalogowanych: 0, gości: 1