Дизайн базы данных, два типа пользователей для сайта

Question

Я делаю обзорный веб-сайт, и я хотел бы, чтобы было 2 типа пользователей. Один был бы большинством, рецензенты, в то время как другой был бы человеком, о котором рецензия. Как, с точки зрения дизайна базы данных, я бы различал два. Должны ли я иметь отдельные таблицы для рецензентов и рецензий или просто назначить разные диапазоны идентификаторов для обоих?

Answer 1

Это классическая ситуация супертипа / подтипа.Пользователи и рецензенты - это люди, а фанатики-реляционисты скажут, что у вас должна быть одна таблица «люди», содержащая все поля общих лиц.После этого вы можете иметь явное взаимное отношение ключа один к одному с таблицей рецензентов, которая содержит поля, относящиеся к рецензенту, и связанные ключи с другими таблицами, относящимися к рецензенту.Вы можете проверить, является ли человек рецензентом, присоединившись к таблице «Рецензенты».

Конечно, вы можете добавить в этот подход других людей с другими данными.Это хороший способ для моделирования вещей для реляционных фанатиков, таких как я, которым нравится избегать пустых полей и необъявленных внешних ключей, которые ссылаются на одну из нескольких таблиц.Жокеи MySQL просто собрали бы все это в одну большую таблицу с множеством нулей, магических чисел и разделенных запятыми списков в полях varchar.

Если вы знаете, что требования не изменятся в будущем (ха!),и нет никакой разницы в схеме между пользователями и рецензентами, просто используйте одно поле person_type и сделайте его простым.

Никогда не используйте «диапазоны клавиш» по любой причине.Это просто хакерство, которое через несколько лет вызовет у вас или кого-то еще огромную болезненную работу по перекодированию.Первичные ключи должны быть без семантики и инварианта.

Answer 2

Учитывая неопределенность вашего вопроса, я бы сказал, что это зависит от вида информации, к которой любая из сторон будет обращаться / вставлять.Насколько я понимаю, структура вашей базы данных должна отражать способ организации ваших данных, а не обязательно отношения между пользователями вашей базы данных.Например, вы могли бы иметь отдельную таблицу с именем «Статус пользователя» с 0-> Reviewer, 1-> Review-ee, а затем перечислить статус пользователя как внешний ключ в вашей таблице пользователей в виде столбца, который указывает, является ли данный пользовательрецензент или рецензент, что исключает необходимость в отдельных пользовательских таблицах.

Answer 3

Я рекомендую вам создать одну таблицу для пользователей и другую для типа пользователя с внешним ключом для пользователей на случай, если впоследствии вам понадобятся пользователи с обоими типами.

Answer 4

Однажды здесь, на ТАКОМ, кто-то сказал: «ВСЕГДА кладите подобные вещи в одну и ту же таблицу».

Это правда, потому что определение «как» ТАК столь неоднозначно, что он всегда может создать определение, которое является правдой.

Так вот, вы должны сделать то же самое здесь. Тот факт, что рецензенты и рецензенты являются «людьми», не имеет значения. Настоящий вопрос в том, может ли кто-нибудь быть и тем, и другим? Если это не так, то у вас не возникнет проблем, и вам следует использовать отдельные таблицы.

Думай об этом так.

Скажем, это правда, что рецензенты никогда не могут быть рецензентами. Где-нибудь у вас будет таблица с Reviewer_ID и Reviewee_ID. Вы построите FK обратно к этим двум таблицам. Эти ограничения ГАРАНТИРУЮТ, что у вас будет один рецензент и один рецензент ... у вас никогда не будет 2 из одного.

Но если они могут, так сказать, «переодеваться», и вы строите две таблицы, вам придется либо поместить одного и того же человека в обе таблицы с разными идентификаторами - это никак (кроме добавления нескольких слоев), чтобы знать, что они то же самое лицо, иначе вам пришлось бы использовать стиль Super-type / sub-type.

Положите похожие вещи в одну таблицу. И то, что как на самом деле означает, является поведенческим. Вещи, которые могут быть рассмотрены, должны помещаться в одну таблицу, даже если они профессора и фильмы. То, как вы обрабатываете их разнородные атрибуты (столбцы Nullable или Supertype / subtype), определяется большим количеством информации, чем вы предоставили).

Answer 5

Если атрибуты, описывающие этих двух разных пользователей, различны, вы можете разделить их. Если они имеют одинаковые атрибуты, такие как firstName, lastName и т. Д., Вы можете сохранить их в одной таблице.

Answer 6

Это довольно сильно зависит от того, какие данные вы храните о каждом из этих типов пользователей. Если очень похоже, одна таблица может быть в порядке, но вам нужно дифференцирующее поле (столбец) вместо назначения диапазона идентификаторов.

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

Answer 7

У вас может быть столбец 'type' со значениями "reviewer" и "reviewee"