Когда таблицу БД следует разделить на две отдельные? - PullRequest
0 голосов
/ 08 февраля 2012

У меня есть таблица пользователей, в которой используется наследование одной таблицы, поэтому у меня могут быть и консультанты, и клиенты, и внутренние пользователи в одной таблице. Я хочу создать таблицу для «заметок», чтобы внутренние пользователи могли делать заметки о клиентах и ​​консультантах. Я не уверен, что мне следует создать таблицу consultants_notes и client_notes или просто создать одну таблицу примечаний? Какие факторы я должен учитывать?

Ответы [ 4 ]

2 голосов
/ 08 февраля 2012

Я бы начал с одной таблицы:

  • У вас уже есть только одна таблица для любого пользователя.
  • Нет смысла создавать три одинаковых артефакта (и утроитькод для использования 3 таблиц).

Однако, если каждый вид заметки будет сильно отличаться от других, вы можете рассмотреть, что лучше для вас: * Больше таблиц с конкретными столбцами для каждого вида заметки.* Одна универсальная таблица с некоторыми дополнительными столбцами, которые не всегда используются.

Учитывайте:

  • Сколько примечаний будет храниться в таблице.
  • Какие данные будут сохраненыдля каждого вида заметки.

Узнайте, как создавать индексы для доступа к определенным видам заметок, и решите, что лучше для вас.

2 голосов
/ 08 февраля 2012

У вас есть одна таблица для трех типов пользователей, так зачем иметь три таблицы для своих заметок?

Проблема с тремя таблицами для заметок заключается в том, что вам придется выборочно просматривать одну из этих таблиц при поиске заметок определенного пользователя.Вы закончите жестким кодированием этой логики в своем PHP-коде, используя операторы if-else - или - вы оставите в своих запросах три таблицы.

А что, если вы решите использовать четыре типа пользователей.

1 голос
/ 08 февраля 2012

Вы сказали в комментарии:

Я пока не совсем уверен, насколько заметки будут отличаться для каждого типа пользователя, поэтому я хотел бы иметь возможность сохранять его гибкость, если это возможно

Я думаю, что оба пути (одна или две таблицы) будут достаточно гибкими. Тем не менее, вы также должны учитывать нормализация . Если затем вы поймете, что консультанту требуется Дата примечания, а клиентам это поле не нужно, то вы начнете получать множество пустых значений в вашей таблице ( пробел , как будто немного стоит что много в эти дни: P и отсутствие нормализация ).

Так что может показаться, что решение за одним столом является недостатком. Однако решение с одной таблицей упростит ваши запросы ( удобочитаемость ), а также повысит производительность ( скорость ), поскольку вам не нужно будет объединять каждую таблицу примечаний.

Преимущества и недостатки двухстолового решения на самом деле противоположны тем, которые лежат за одним столом. Итак, каковы ваши основные ограничения? Если это скорость, вы выберете решение за одним столом. По моему мнению, я бы выбрал решение для двух таблиц, потому что не могу иметь ненужных значений в таблице. Кроме того, имея строгий дизайн, то есть тот, который не позволит вам добавить значение примечания клиента к значению примечания консультанта, гораздо безопаснее, чем тот, который позволяет вам сделать это с помощью простого ОБНОВЛЕНИЯ. Хотя вы можете добавить ограничения к значениям столбцов, чтобы обойти это, это не то же самое.

Ну, это мое скромное мнение. Надеюсь, это поможет, или, по крайней мере, заставит вас дважды подумать, прежде чем выбрать свой дизайн:)

PS: факторы, которые следует учитывать, выделены жирным шрифтом

0 голосов
/ 08 февраля 2012

Я вижу, что вы пометили php, поэтому, если вы не используете две разные страницы для чтения / записи заметок для разных типов пользователей, я бы выбрал одну таблицу, потому что вам не нужны два отдельных запроса. Если вы не планируете иметь в таблице тысячи заметок, в этом случае отдельные таблицы могут быть более эффективными.

Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...