Кога да се разделят моделите на множество таблици на база данни? [затворено]

Работя с Ruby on Rails, но този въпрос мисля, че е по-широк от това и се отнася за дизайна на бази данни като цяло.

Кога е добра идея да разделите един модел на няколко таблици? Да приемем например, че имам потребителски модел и броят на полетата в модела наистина започва да се увеличава. Например, потребителят може да въведе своя уебсайт, своя рожден ден, своята часова зона, своя и т.н.

Има ли някакво предимство или недостатък на разделянето на модела, така че може би таблицата User има само основна информация като вход и имейл, а след това има друга таблица, която всеки потребител има, която е нещо като UserInfo, и друга, която е UserPermissions, и друг, който е UserPrivacySettings или нещо подобно?

Редактиране: За да добавите допълнителен гланц на това, повечето от полетата са рядко достъпни, освен на страници, специфични за тях. Например неща като рожден ден са достъпни само ако някой кликне до потребителския профил. Освен това, някои от полетата (които са рядко достъпни) имат потенциала да бъдат изключително големи. Повечето от полетата имат потенциал да бъдат празни или нула.


database database-design models
person William Jones    schedule 16.02.2010    source източник
comment
За колко полета всъщност говорим в таблицата User?   -  person brettkelly    schedule 16.02.2010

Отговори (3)


arrow_upward
9
arrow_downward

Като цяло е добра идея да поставите неща, които имат връзка едно към едно, в една и съща таблица. Освен ако вашата потребителска база не включва кралицата или мечката Падингтън, потребителят има само един рожден ден, така че това трябва да е атрибут на таблицата ПОТРЕБИТЕЛИ. Нещата, които имат връзка "един към много", трябва да бъдат в отделни таблици. Така че, ако потребителят може да има множество настройки за поверителност, по всякакъв начин ги разделете.

Разделянето на една таблица на няколко таблици може да направи заявките по-сложни или по-бавни, ако искаме да извлечем цялата информация на потребителя наведнъж. От друга страна, ако имаме набор от атрибути, които винаги се запитват или актуализират по отделен начин, тогава наличието на отделна таблица, която да съхранява тези данни, е добра идея.

person APC    schedule 16.02.2010

arrow_upward
3
arrow_downward

Това ще бъде ситуация за анализ.

Когато откриете, че много от полетата в такава таблица са NULL и могат да бъдат групирани заедно (напр. UserContactInfo), е време да разгледате извличането на информацията в собствената таблица.

Искате да избегнете наличието на таблица с десетки/стотици полета само с оскъдно въведени данни.

По-скоро се опитайте да групирате данните логически и създайте основната таблица, съдържаща полетата, които са почти всички попълнени. След това можете да създадете подгрупи от данни, почти както бихте ги представили в потребителския интерфейс (Информация за контакт, личен интерес, информация, свързана с работата и т.н.) в отделни таблици.

person Adriaan Stander    schedule 16.02.2010
comment
Какви са недостатъците, свързани с таблица с оскъдно въведени данни? - person William Jones; 16.02.2010

arrow_upward
3
arrow_downward

Извличането на ред е по-скъпо, ако има много колони, особено ако обикновено се нуждаете само от някои от полетата. Също така, хостинг неща като компоненти на адрес в отделен клас е случай на DRY. От друга страна, ако имате нужда от всички полета на даден обект, изпълнението на съставна заявка отнема повече време.

Обикновено не бих си правил труда да разпределям класове в няколко таблици, само за да направя кода по-четлив (т.е. без части за многократна употреба като адреси).

person Kilian Foth    schedule 16.02.2010
comment
Освен това по-скъпо ли е да извлечете ред с много колони, когато избирате само колоните, които са необходими? Или това ще се изпълни за същото време, както ако имаше по-малко колони. - person Steven Ryssaert; 22.04.2015