Czy dobrą praktyką jest trzymanie dużej ilości danych w jednej tabeli?

0

Zrobiłem małą bazę danych i umieściłem w niej następującą tabelę.
Teraz mam mały dylemat, dobrym pomysłem jest trzymanie wszystkiego w jednej tabeli czy może rozbić to na kilka innych?

Driver: (tabela z informacjami związanymi z kierowcą)
• Driver_id (liczba przypisana do kierowcy, klucz główny)
• Driver_name (imię kierowcy)
• Lastname (nazwisko kierowcy )
• Phone_number (numer telefonu)
• Email (adres e-mail)
• Company (firma w której zarejestrowany jest jako pracownik)
• Address (adres zamieszkania)
• City (miasto)
• Zip (kod pocztowy)
• Country (kraj )
• Languages (języki jakimi włada)
• Bank_name (nazwa banku)
• IBAN (numer konta)
• BIC (identyfikator banku)
• Tax_identification_number (numer identyfikacji podatkowej)
• Health_insurance_number (numer ubezpieczenia zdrowotnego)
• Additional_information (dodatkowe informacje)
• Photo (zdjęcie)

0

Ja bym wydzielił:

  1. Tabelę dla Banku - jak bank zmieni nazwę bo go przejmie jakis inny to nie będzie problemu ze zmianami w bazie. A wyobraź sobie że np "bank śląski" masz wpisany w bazie z dużych liter, z małych, z polskimi znakami, bez itd a teraz trzeba wszystkie przerobić nagle na "ING". Poza tym może kiedyś będzie trzeba dorzucic jakieś informacje specyficzne dla banku? ;)
  2. Tabelę słownikową na języki - jw, żeby uniknąć zabawy z szukaniem wszystkich którzy mówią po słowacku poprzez wpisywanie "slowacki", "słowacki", "Słowacki" itd
  3. Pomyślałbym też nad słownikiem dla krajów i miast z podobnych względów.

Poza tym podzieliłbym resztę względem tego z których danych korzystasz często a z których nie. Np. może nie zawsze potrzebne ci zdjęcie więc można je wydzielić do osobnej tabeli 1:1.

1

Dobra praktyka jest raczej trzymanie danych w wielu tabelach - poczytaj sobie o postaciach normalnych.

Dodam, ze nalezy sie kierowac bardziej zdrowym rozsadkiem niz tymi wszystkimi zasadami. Jak sie okaze, ze trzymanie danych w jednej tabeli zamiast w dwoch bedzie bardziej wydajne i beda to dane czesto przetwarzane to nalezy rozwazyc takie wlasnie rozwiazanie (o ile wydajnosc to istotne kryterium).

0

Co do miast miałem plan rozsadzić je na pojedyncze tabele, ale nie wpadłem na to z językami i bankami.
Działam dalej.

Konkretna odpowiedź, dziękuję Ci serdecznie! :)

0
tk napisał(a):

Dobra praktyka jest raczej trzymanie danych w wielu tabelach - poczytaj sobie o postaciach normalnych.
A co jeśli po sprowadzeniu do postaci normalnej i tak masz 40 czy 50 pól? Bo wiadomo, że jak się pisze rozbudowany system i masz np. kartotekę towarową czy kontrahentów to wtedy tych pól opisowych może być bardzo dużo? Ja bym jednak zostawił te 40-50 pól w tabeli.

0

@Mr.YaHooo Jezeli baza danych ma odpowiednia strukture to liczba kolumn bym sie az tak bardzo nie przejmowal. Rowniez zostawilbym 40-50 kolumn w tabeli.

0

Odseparowałbym jeszcze adres zamieszkania i uzależnił z data zmiany wpisu - powód prosty - masz dokumenty, które generujesz na tej podstawie, jeśli ktos zmieni adres, ale będziesz potrzebować wystawić jakiś dokument (np wtórnik) ze starymi danymi - wtedy proste zapytanie chroni Cie przed Tym.

Ktos juz zauważył, że języki lepiej by mieć słownik i powiązanie przez tabelę pośrednicząca, wtedy łatwiej filtrować choćby to kto jakie języki zna i mamy powiązanie wielu do wielu.

0

Podstawowe pytanie, tworzysz bazę danych z wykorzystaniem relacyjnego systemu typu MySQL? Może już sam znalazłeś odpowiedź ;)

0
kaczus napisał(a):

Odseparowałbym jeszcze adres zamieszkania i uzależnił z data zmiany wpisu - powód prosty - masz dokumenty, które generujesz na tej podstawie, jeśli ktos zmieni adres, ale będziesz potrzebować wystawić jakiś dokument (np wtórnik) ze starymi danymi - wtedy proste zapytanie chroni Cie przed Tym.
Ja widziałem z kolei podobne rozwiązanie, z tym, że każda edycja danych np. a kartoteki kontrahentów czy odbiorców powodowała zapis nowego rekordu. Natomiast inne tabele odnosiły się do konkretnej wersji rekordu. Zatem jeśli dane edytowaliśmy 10 razy, to zmiany są dokładnie widoczne.

Takie rozwiązanie ma również swoje minusy. Bo wtedy jak po wpisaniu np nazwy kontrahenta z błędem i wstawieniu go do dokumentu nie było możliwości poprawy literówki w prosty sposób. Zatem trzeba uważać ;)

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