Organizacja tabel dobre praktyki

Question

Zastanawiam się nad tym jak organizować dane i czy moje podejście jest dobre.

Mam tabele "user", która zawiera dosyć sporo kolumn i moim zdaniem niektóre wypadałoby umieścić w osobnych tabelach. Przykładowo dane takie jak dane kontaktowe (adres, nr telefonu) oraz dane osobowe(rok urodzenia, imie, nazwisko itd.) wrzuciłbym do oddzielnych tabel, a w tabeli user zostawił jedynie kolumny takie jak login, e-mail i dane ogólne związane z kontem.

I tu pojawia się moje pytanie - czy takie podejście jest ok, czy może zbytnio kombinuje i wszystko powinno zostać w jednej tabeli?

Comments

A o czymś takim jak relacyjna baza danych, to kolega słyszał?

---

Nie rozumiem co to ma do rzeczy? Pytam o organizację danych w RELACYJNEJ bazie...

---

Jedna tabela to jaka ona tam relacyjna

---

No to może kolega, jednak zamiast głupio komentować, to może sobie doczyta- i jednak pozna lepiej model relacyjny 
Bo często spotykana jest realcja tabeli z samą sobą, nawet ma to swoje zastosowanie :) 

a przy okazji z teorii : 
 

Relację ρ ⊂ A × A, nazywamy relacją równoważności, jeśli ρ jest relacją zwrotną, symetryczną i przechodnią. Relację równoważności oznaczamy symbolem ≈.

Relację ρ ⊂ A × A, nazywamy relacją równoważności, jeśli:
- aρa dla każdego a ∈ A,
- aρb ⇒ bρa   dla każdego a, b∈A,
- (aρb ∧ bρc) ⇒ aρc  dla każdego a, b, c ∈

---

Bo często spotykana jest realcja tabeli z samą sobą

Też musisz doczytać :P Za normalną terminologią, to sama tabela już jest "relacją". Zależności między tabelami to wyższy koncept.

This model organizes data into one or more tables (or "relations") of columns and rows

---

ale ja wiem, że sama tabela jest relacją, bo to jest okreslone już z góry przez sam fakt 
Teorii relacyjnej, która narzuca nam nawet pewną terminologię np. występowania krotek, atrybutów etc.
Ale tutaj nie miałem na celu robić wywód w tej sprawie, bo nie jest to tematem pytania.  

Baza bez tabel może mieć relacje też, jak i samo występowanie modelu E-R. 
Ja już miałem na myśli czynną relację tabeli samej z sobą przy projekcji. 

---

Rozumiem i wiem, że na jedną tabelę można łączyć w relacje, ale to nie oznacza, że tabela "user" to relacyjna baza danych.

Chciałem zwrócić uwagę, żeby autor tematu się temu przyjrzał, bo jest to ważne już na samym początku projektowania BD.

Answer 1

Twoje podejście jest jak najbardziej słuszne. Głównie ze względu na bezpieczeństwo: każdej tabeli przypiszesz innych użytkowników z innymi uprawnieniami. No i ergonomia - łatwiej operować na mniejszej tabeli. Relacja 1-1 załatwia sprawę połączenia tabel.

Comments

Kwestia kontekstu.

---

Możesz szerzej, najlepiej z przykładem.

---

Rozbijanie wszystkie na mniejsze tabele nie ma sensu przy prostych CRUDach. Dodatkowe obciążenie bazy łączeniami jest zbędne. Z kwestii czysto teoretycznej spoko, przy gigantycznych bazach nie zawsze ma to sens. Oczywiście dochodzi typ bazy, jej budowa, implementacja warstwy pośredniczącej. Po prostu autor podał za mało danych, by jednoznacznie stwierdzić, co będzie najlepsze, przynajmniej według mnie, stąd komentarz, że to zależy.

Answer 2

Z jednej strony jest to okej, z drugiej no nie do końca.

Zauważ, że na tak małych danych faktycznie staje się to lepsze, ale robi się nam struktura gałęzi, idąc tym tokiem myślenia, pomyśl że kolejne tworzone tabele, nagle "wymagać zaczną" kolejnych relacji do innych i tak w koło.
Problem pojawia się przy może "nie " niewielkich danych ale przy większych jeśli chodzi o usuwanie np.
Musisz mieć na uwadze, pamiętać o tym, że jeśli pozbywasz się z tabeli A jakiegoś elementu , a on jest w relacji z B,C... itd, to należy o tym pamiętać tak samo idąc w głąb kolejnych wiązań

To samo jeśli struktura tabeli ulega zmianie, lub poszczególne krotki