Хранение данных профиля пользователя из нескольких справочных таблиц. как?

Question

У меня есть пользовательская таблица, в которой содержится около 50 штук данных.Некоторые из них - это Религия, политическая партия, этническая принадлежность, город, любимые фильмы и т. Д. Каждый из этих элементов - это значения поиска из: их собственной таблицы поиска ИЛИ У меня есть общая таблица поиска для небольших элементов, таких как пол, половые предпочтения и т. Д.Даже любимый фильм взят из таблицы поиска фильмов.

Вопрос в том, что я предполагаю, что в таблице участников все они будут храниться как идентификаторы, а не как текст?Итак, сначала Q:
1) Должны ли они или не должны иметь FK для таблиц поиска?
2) Если мы сохраним идентификаторы, то получим фактический текст ответа, такой как Id 6, в таблице city = new york, Id 10в таблице национальности = американец и т. д. для фактического вывода на странице, как это будет сделано?Нужно ли выбирать из каждой таблицы поиска в режиме чтения, чтобы вывести текстовое значение?Это пугает меня, потому что из 50 фрагментов данных около 40 из них основаны на поиске, так что это означает 40 различных вариантов выбора из 40 таблиц в режиме чтения страницы и снова в режиме редактирования, чтобы пользователь мог редактировать значения.

Как это реализовано на реальных сайтах с подробными профилями пользователей?(У меня есть поиск и аналитика по каждому значению, поэтому мне нужно идентифицировать их)

Answer 1

То, что вы описали, - это большой компромисс между нормализованным дизайном БД и скорее дизайном плоских таблиц: запросы намного сложнее с нормализованным дизайном, который звучит так, как у вас.

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

Answer 2

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