социальная сеть - вопрос схемы дизайна профиля пользователя - PullRequest
0 голосов
/ 02 декабря 2010

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

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

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

Ответы [ 2 ]

3 голосов
/ 02 декабря 2010

Вопросы хранения данных в социальных сетях на самом деле ничем не отличаются от вопросов хранения данных в целом ... Нормализованные и связанные данные - лучший способ для эффективного хранения этих данных.СУБД создана для обработки этих отношений - отношения PK-FK и JOINS являются ОСНОВНОЙ точкой реляционных БД ... поэтому, даже несмотря на то, что ВЫ "видите" соединение и т. Д. Соединение, БД (должна быть) эффективна в обработке этих соединений.

С точки зрения ИСПОЛЬЗОВАНИЯ доступа к соответствующим данным - убедитесь, что ваши индексы точны и оптимизированы - и используйте VIEWS, чтобы «сгладить» данные, необходимые для отображения ...

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

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

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

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

0 голосов
/ 16 мая 2012

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

...