Schemat bazy danych do oceny

Cześć wszystkim na forum,

Pracuję właśnie nad swoim "pet projectem", którym ma być aplikacja webowa obsługująca wypożyczalnię samochodu napisana w .NET Core.
Zrobiłem bazę danych (a w zasadzie część tej bazy która jest niezbędna do podstawowych funkcjonalności), wiedzę czerpałem z ksiażki Viescas, Hernandez "Zapytania w SQL. Przyjazny przewodnik" (choć o samym projektowaniu wiele nie było) i internetu.

Już po stworzeniu bazy i napisaniu w C# metod odczytujących potrzebne mi dane zacząłem się zastanawiać czy nie za bardzo rozbudowałem tę bazę. Moje wątpliwości budzą tabele "FuelTypes", "Transmissions", "AirConditionings" (czy nie lepiej by było po prostu zrobić takie kolumny w tabeli "CarVersions", i w dalszej kolejności "Brands", "CarSegments", "CarTypes" ?
Czy takie rozdrabnianie danych na wiele małych tabel, gdzie z góry wiemy że liczba rekordów będzie mała (no bo ile może być marek samochodów? 50? 100?) ma jakikolwiek sens?

Nie będę ukrywał, że wzorowałem się na takim schemacie (znalazłem namiar do tej stronki na StackOverflow) i tam autor wydziela te mini-tabele.
http://www.databaseanswers.org/data_models/car_hire/index.htm

Ma to sens ponieważ możesz sobie to używać jako słowników. Niweluje to problemy z różnymi nazwami itp. według mnie pozwala też potem na lepszą analitykę .

Ogólnie schemat rozsądnie wygląda :-)

Po co robisz oddzielna tabele na rodzaj paliwa, klimatyzację, skrzynię biegów, markę itp. (sam masz wątpliwości) ? Są to wartości przypisane do konkretnego pojazdu tak jak numer VIN i jedynie należy je wprowadzać słownikowo.

Niepotrzebnie robisz oddzielne tabele dla np. rodzaju paliwa, określ to jako TINYINT i będzie po sprawie, a nie jako odnośnik do odrębnej tabeli, gdzie i tak masz wszystko jak INTEGER rozpisane, szkoda to rozwalać na dodatkowe tablice, bo będziesz potem marnował czas na JOINy. Rozdziel sobie to jedynie w przypadku, gdy np. tabela z rodzaje paliwa zawierałaby jeszcze jakieś dodatkowe dane.

A tak z własnego doświadczenia brakuje Ci dat, kiedy rekordy były dodane lub zaktualizowane. Daty się zawsze przydają, prędzej czy później ;)

Dziękuję wszystkim za uwagi. Ale zdania jak widać podzielone. Tak też podpatrywałem u innych - niektórzy wydzielali te dwukolumnowe tabele, inni nie.
Moglibyście jeszcze pokrótce napisać o co chodzi z tym zapisywaniem słownikowo? Tzn. poczytałem w necie i z samym zapisem/odczytem do słownika nie powinienem mieć problemu, ale nie wiem kiedy taki słownik mógłby mi się przydać.

Słowniki przykład tabela Country. Masz tam zapisane dane odnośnie krajów na świecie. Przykładowo jakiś kraj sobie zmienia nazwę i teraz nie będzie nazywany oficjalnie Holland tylko The Netherlands. Robisz update na tabeli slownikowej 1 rekordu a nie gdzieś gdzie są transakcje itp.

Jak wszystko w życiu zależy od projektu do będzie lepsze :-)