|
Стоит ли разбить таблицы на несколько?
|
||
|---|---|---|
Участник
Откуда: Зеленоград, Москва, Россия
Сообщения: 20 644 |
||
| 27.01.2017, 07:57 |
|
|
Этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
Политика конфиденциальности
|
|
|
Стоит ли разбить таблицы на несколько?
|
|||
|---|---|---|---|
|
#18+
Здравствуйте! Есть таблица User . Каждый юзер может быть либо школьником , либо учителем , либо клиентом , либо админом , либо суперадмином . Проблема вот в чем: каждый вид юзера имеет множество полей, которые относятся только к данному типу пользователя. Стало быть, если юзер является школьником, то все его поля, которые относятся к другим типам юзеров, будут пусты. И так вся таблица будет всегда на 2/3 пустой. Будет ли это бить по производительности? Есть ли какие-то минусы в этом? Всего в таблице около 50 столбцов. Главный вопрос: стоит ли разделять таблицу на несколько? Например одну главную таблицу user и связанные с ней pupil , teacher , customer , admin , superadmin ? Я просто владею недостаточным количеством информации, поэтому не знаю всех плюсов и минусов. Спасибо всем за любую информацию ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 22:57 |
|
||
|
Стоит ли разбить таблицы на несколько?
|
|||
|---|---|---|---|
|
#18+
murtukov, Судя по тому, что в одну кучу замешаны школьники и клиенты, это учебная задача? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 23:00 |
|
||
|
Стоит ли разбить таблицы на несколько?
|
|||
|---|---|---|---|
|
#18+
miksoft, это вымышленные названия, а задача реальная ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.01.2017, 23:19 |
|
||
|
Стоит ли разбить таблицы на несколько?
|
|||
|---|---|---|---|
|
#18+
murtukovэто вымышленные названияПравильность проектирования зависит от предметной области, в т.ч. от тех операций, которые предполагается производить с данными. Не зная ни того, ни другого нельзя посоветовать что-то определенное. Начните с одной широкой таблицы, в которой есть все поля для всех подтипов записей. В будущем, возможно, пригодятся и кажущиеся ненужными поля. А когда подразберетесь получше - сможете перепроектировать БД, если будет такая необходимость. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2017, 00:01 |
|
||
|
Стоит ли разбить таблицы на несколько?
|
|||
|---|---|---|---|
|
#18+
Решений три. Самое плохое - это отдельная таблица для каждого типа. Получше - EAV. Впрочем, иногда оно может оказаться оптимальным. Ещё лучше - одна таблица, пусть и разреженная. К сожалению, в двух последних вариантах возникнут сложности с контролем полноты заполнения. Проще всего их решить, если всю логику изменения данных реализовывать в формате ХП. murtukovБудет ли это бить по производительности? Почти наверняка вряд ли. Особенно при правильной индексации. murtukovВсего в таблице около 50 столбцов.Это немного. Если, конечно, они все не LONGBINARY... murtukovГлавный вопрос: стоит ли разделять таблицу на несколько?99% за то, что нет. Остальное - за "фиг знает". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2017, 07:57 |
|
||
|
Стоит ли разбить таблицы на несколько?
|
|||
|---|---|---|---|
|
#18+
Вариант: одна общая таблица и к ней 1-к-1 подключены детальные таблицы (как описал ТС). Достоинства: - детальная таблица имеет специфичный набор полей. - разные детальные таблицы могут иметь свои подчиненные таблицы. При этом нет необходимости делать внешний ключ на общую таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 27.01.2017, 15:34 |
|
||
|
|
start [/forum/topic.php?fid=47&msg=39392649&tid=1830965]: |
0ms |
get settings: |
10ms |
get forum list: |
15ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
39ms |
get topic data: |
13ms |
get forum data: |
3ms |
get page messages: |
54ms |
get tp. blocked users: |
2ms |
| others: | 15ms |
| total: | 159ms |
| 0 / 0 |
