социальная сеть - вопрос схемы дизайна профиля пользователя

0

Я создаю профили пользователей на своем сайте и теряю информацию о том, как это сделать: Есть много полей, некоторые из них 1:1, например, город проживания, день рождения и т.д. Но есть более 50 полей, которые составляют 1: или многие из многих?), как любимые фильмы, спортивные команды, предпочтения в отношении знакомств, имена экранов, номера телефонов, адреса электронной почты и т.д. Это становится более сложным, когда у нас работают предыдущие компании, предыдущие школы и т.д. Человек может принадлежать многим компаниям и в этой группе есть много полей, таких как Дата работы, отдел, название компании, название отрасли и т.д.

Итак, вопрос в том, как хранить все это? Если мы нормализуем все эти поля профиля, будет собрано много многих таблиц. Насколько я читаю, для социальных сетей люди рекомендуют денормализованный подход. Но в любом случае я сохраняю все данные пользователя и данные профиля в главной пользовательской таблице, поэтому каждая строка является уникальным пользователем. Если мне нужно сохранить все эти множественные предпочтения, esp, как любимые фильмы, может идти в сотни, а прошлые компании имеют целую группу полей, поэтому в таблице пользователя будет много дубликатов.

Каким подходом занимаются социальные сети?

Теги:
database
schema
social-networking

2 ответа

3

Вопросы хранения данных в социальных сетях на самом деле не отличаются от вопросов хранения данных в целом... нормализованные и связанные данные - лучший способ эффективно хранить эти данные. RDBMS создана для обработки этих отношений - отношения PK-FK и JOINS являются ГЛАВНЫМ пунктом реляционных БД... поэтому, даже если вы "видите" присоединиться к join join и т.д., БД (должна быть) эффективна при обработке этих объединений.

С точки зрения USAGE получения соответствующих данных - убедитесь, что ваши индексы точны и оптимизированы - и используйте VIEWS для "сглаживания" данных, которые вам нужны для показа...

Таким образом, любой сервер приложений, который вы используете для получения данных, вызывается VIEW, который будет "отображаться" вам, разработчику, как "более плоское" представление данных, делая взаимодействие с пользователем и APP-серьером более чистым и более эффективным (как в ресурсах, так и в кодировании),

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

Я думаю, вы могли бы подумать о SN как о более OLAP, чем OLTP. В этом случае "некоторые" де-нормированные хранилища данных являются общими - и приемлемыми - действительно, вы должны решить, как нормализовать то, что вы хотите... Например, в ваших примерах, истории занятости и кино, в спорте. Я бы подумал, что простой 1: многие, позволяющие дублировать записи на таких элементах, будут точными и, вероятно, легче поддерживать...

Надеюсь, что это было полезно,

Поделиться
  • 0
    Но почему люди тогда идут денормализованным путем для социальных сетей? Или это просто потому, что большие парни, такие как Facebook и Google, делают это, чтобы мир их копировал?
  • 0
    Я так хочу сказать "Да, довольно много". Но это может привести к пламенной войне. Я просто одобряю ответ вместо этого.
0

Вы должны придерживаться стратегии нормализации создания вашей схемы. Запрос может быть болью, с которой вам следует обращаться с особой осторожностью, особенно при работе с объединениями. Если вы разработчик точек, я полагаю, что LINQ будет обрабатывать d боль для you.I считаю, что ваша RDMS достаточно умна, чтобы обрабатывать ваши запросы с большой производительностью. Одна вещь, которую нужно обратить внимание, это структура запроса. Запишите запросы на основе производительности. Как я уже сказал, LINQ должен делать это лучше всего. Улыбки

Поделиться

Ещё вопросы

Сообщество Overcoder
Наверх
Меню