Cześć,
Chciałbym nauczyć się poprawnie projektować relacyjne bazy danych. Chciałbym poznać jak powinno się dobrze modelować tabele oraz relacje między nimi tak aby w przyszłości nie pojawiły się jakieś problemy konstrukcyjne, które będą miały wpływ na wydłużenie się czasu tworzenia nowych funkcjonalności. Fajną było by też opcją, gdyby były pokazane jakieś częste problemy jakie mogą pojawić się podczas projektu, wraz z proponowanymi rozwiązaniami.
Macie jakieś materiały lub książki które poruszają te tematy?
0
2
To jak jest to połączone, jakie są relacje itd. wynika z tego jaki masz problem do rozwiązania. Baza danych służy tylko do przechowywania danych i od niej nie powinno się tworzyć systemów informatycznych.
Myślę, że zaczynasz od d**y strony.
0
@.andy: Chodzi mi bardziej o to np. Klient powie jaki chce mieć system i moim zadaniem było by zaproponowanie struktury magazynu danych dla tych wymagań. Chciałbym poznać właśnie takie zasady i dobre praktyki, którymi mam się kierować.
Przykładowo spotkam się z problemem (jeśli jest słabym przykładem to przepraszam za naiwność):
"Chcemy w systemie zarządzać piłkarzami, którzy mogą grać na różnych pozycjach."
I jak wtedy podejść? Oddzielna tabela na każdą pozycję? A może jedna tabela "Piłkarz" i w nim atrybut "Pozycja" typu enum?
Zapewne to zależy od innych założeń.
Chciałbym właśnie poznać od czego to zależy. Jak w takich sytuacjach się zachować.
2
"Chcemy w systemie zarządzać piłkarzami, którzy mogą grać na różnych pozycjach."
I jak wtedy podejść?
Oddzielna tabela na każdą pozycję?
Przestań myśleć tabelkami. Jak już pisałem nie zaczynaj od bazy danych.
W tym przypadku zrobiłbym sobie jakiś obiekt Footballer, przypisał mu jakieś cechy.
Atrybut fieldPosition możę być kolejnym obiektem albo enumem, albo intem ;) Wszystko zależy jak to coś wygląda w świecie rzeczywistym. Tutaj może enum by się sprawdził najlepiej.
Tak jak pisałem to problem architektoniczny i trzeba zacząć od architektury aplikacji, od próby zarysowania GUI do jej obsługi. To jak to na końcu będzie się zapisywało wyniknie z tego.
NA twoim miejscu zacząłbym od rozpisywania biznesowych przypadków użycia, zrobił analizę a potem siadł do bawienia się w architekturę. Dopiero na końcu okaże się czy do tego lepiej jest mieć relacyjną bazkę, czy nie.