Jest to typowa dyskusja w wąskiej tabeli (oparta na atrybutach) w porównaniu z dyskusją w szerokiej tabeli. Problem z podejściem nr 2 polega na tym, że prawdopodobnie będziesz musiał przestawić dane, aby uzyskać formę, z którą użytkownik może pracować (z powrotem do formatu szerokiego widoku). Może to być bardzo zasobochłonne w miarę wzrostu liczby wierszy i liczby atrybutów. Trudno też spojrzeć na tabelę w widoku surowym i zobaczyć, co się dzieje.
Wielokrotnie prowadziliśmy tę dyskusję w naszej firmie. Mamy kilka tabel, które bardzo dobrze pasują do schematu typu atrybutu. Zawsze rezygnowaliśmy z tego ze względu na konieczność obracania danych i niemożność przeglądania danych i sprawienia, aby miało to sens (ale to jest dla nas leasingodawca dwóch problemów - po prostu nie chcemy obracać milionami wierszy danych).
BTW, nie zapisałbym wieku jako liczby. Przechowałbym datę urodzenia, jeśli ją masz. Poza tym nie wiem, do czego odnosi się „Język ojczysty”, ale jeśli jest to język, którym posługuje się matka, zapisałbym to jako FK do tabeli języków głównych. Jest bardziej wydajny i zmniejsza problem złych danych z powodu błędnie napisanego języka.
