Wpis z mikrobloga

Mircy spod tagu #programowanie, mam pytanie/prośbę. Szukam kogoś ogarniającego dobrze budowę baz danych.

Uczę się trochę C# i wykombinowałem że sobie walnę na własny użytek program do fakturowania. A jako że serwis komputerów wykonuję, dodałbym od razu możliwość generowania protokołu przyjęcia sprzętu na serwis. O ile to nic skomplikowanego, to pasowałoby porządnie przemyśleć budowę bazy danych (MSSQL express). Pomysł w sam raz żeby poćwiczyć Linq, okienka w WPFie, palce lizać ( ͡° ͜ʖ ͡°)

Byłby mi ktoś w stanie taką zaprojektować/pomóc/podpowiedzieć? Jakich narzędzi użyć do zaprojektowania bazy?(wystukać ręcznie tabele w SQL management studio?)

Z grubsza tak bym to widział:
Osobne tabele na :SERWIS (sprzety przyjęte), TOWARY (sprzedawany towar - czyli usługa), KONTRAHENCI, ADRESY, KONTAKTY i... co dalej?:)
  • 8
@Coreq: Entity Framework to wykorzystam do połączenia się z bazą. Ja chcę database first - czyli najpierw poprawną, dobrze przemyślaną bazę utworzyć. Dlatego proszę o podpowiedzi.
@T34v2: Weź długopis i kartkę, albo jakiś program w necie i zrób sobie najpierw diagram związków encji(ERD). Potem wymyśl sobie zapytania SQL, których będziesz używał i zobacz czy ci się wszystko zgadza. SQL Server management studio może wygenerować taki diagram ze stworzonych już tabel więc możesz i tak, a później edytować to co ci sie nie będzie zgadzało.
@Introoz:
Rozumiem. Właśnie grzebę w SQL Server Management Studio. Efekt, jaki pewnie chciałbym uzyskać to pewnie coś takiego:
http://www.wiedzanaplus.pl/bazy-danych/20-mysql/7-projekt-bazy-danych-baza-serwisowa-sprzetu-rtv.html

Pytanie tylko po co w tym konkretnym przykładzie, tabele "Kategorie" i "Producenci" są wcześniej połączone tabelę "kategorieproducenci"? Jaki jest sens takiego zabiegu? Tabela wygląda na wciśniętą na siłę.
Tak samo z Tabelami "adresy", "kontakty", "kontakty
klientowserwisu" i "adresyklientow_serwisu". Ja bym to wszystko władował w tylko dwie tabele, czyli "kontakty"
@T34v2:
"Relacja wiele-do-wielu oznacza, że kilka rekordów z pierwszej tabeli odpowiada wielu rekordom z tabeli drugiej. W praktyce stosowanie tejże relacji jest wielce niewskazane ze względu na redundancję danych, zatem rozwiązaniem tego problemu będzie utworzenie tzw. tabeli łącznikowej, scalającej obie tabele relacją jeden-do-wielu. Przykładowa relacja wiele-do-wielu została zaprezentowana na rysunku 8, natomiast prawidłowa prezentacja – za pomocą tabeli łącznikowej na rysunku 9."

https://msdn.microsoft.com/pl-pl/library/projektowanie-baz-danych--diagramy-erd-relacje-miedzy-tabelami-zwiazki-rekordy.aspx

W drugim przypadku masz rację, te tabele są
@T34v2: Nie masz co specjalnie nad tym główkować. Struktura bazy danych będzie zmieniała się w trakcie rozwoju aplikacji, kiedy różne koncepcję zaczną mieć docelowy kształt. Póki nie trzymasz jeszcze produkcyjnych danych, możesz eksperymentować do woli. A później właściwie niezbędne staje się używanie czegoś do migracji/wersjonowania bazy danych