Социальные сети и филиалы

Question

Я нахожусь в процессе планирования базы данных для проекта социальной сети и наткнулся на этот URL, который (грубый) обратный инженерный догадка на Facebook схема:

http://www.flickr.com/photos/ikhnaton2/533233247/

Что меня интересует, так это понятие «Принадлежность», и я пытаюсь полностью понимаю, как они работают, технически говоря. Где я несколько запутался столбец NetworkID в таблицах FacebookGroups "," FacebookEvent "и" Affiliations "(NID в Affiliations). Как связаны эти сетевые присоединения?

В моем собственном проекте у меня есть простая таблица профиля:

CREATE TABLE [dbo].[Profiles](
    [profileid] [int] IDENTITY(1,1) NOT NULL,
    [userid] [uniqueidentifier] NOT NULL,
    [username] [varchar](255) COLLATE Latin1_General_CI_AI NOT NULL,
    [applicationname] [varchar](255) COLLATE Latin1_General_CI_AI NOT NULL,
    [isanonymous] [bit] NULL,
    [lastactivity] [datetime] NULL,
    [lastupdated] [datetime] NULL,
 CONSTRAINT [PK__Profiles__1DB06A4F] PRIMARY KEY CLUSTERED 
(
    [profileid] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY],
 CONSTRAINT [PKProfiles] UNIQUE NONCLUSTERED 
(
    [username] ASC,
    [applicationname] ASC
)WITH (IGNORE_DUP_KEY = OFF) ON [PRIMARY]
) ON [PRIMARY]

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

У меня вопрос , как я должен проектировать свои таблицы присоединения к сети и как они работают в соответствии с моими вышеуказанными требованиями? Грубая схема SQL будет оценена в Ваш ответ.

Заранее спасибо ...

Answer 1

Во-первых, это схема объекта, а не схема базы данных. Во-вторых, это не все, далеко не завершено. Посмотрите на класс школы (не таблица), обратите внимание на отношения, 1 и 2 старших классов и список школ. Видите ли вы свойства в классе Profile для хранения этих «внешних ключей».

На ваш вопрос нельзя ответить точно

Во-вторых, какая разница, как это делает facebook? Третья нормальная форма не чёрное искусство? Там нет знаний о Потерянном и Унесенном Навсегда, к которым вы не причастны.

Хотите ли вы много-много отношений между филиалами и профилями? Или нет? Вы пытаетесь раскрыть взаимозависимости между филиалами?

Почему бы просто не задать нам конкретные вопросы о том, как разработать то, что ВЫ хотите сделать?

EDIT

Один профиль может иметь много филиалов. И одна принадлежность может иметь много профилей.

Это отношение многих ко многим.

В физической базе данных вам нужна таблица сопоставления многие-многие.

В самом простом случае он содержит PK из обеих таблиц, и эти столбцы образуют PK этой таблицы.

Так что теперь просто добавьте столбцы в таблицу сопоставления.

Start_date => дата добавления профиля этой принадлежности

End_Date => по сути логическое удаление

Что еще вы хотите знать об отношениях.

Подумайте об этих объектах 1. Видео 2. Арендатор 3. Магазин

Много-много-много можно охарактеризовать как АРЕНДУ.

VideoID, RenterID, StoreID,

Что еще вы хотите знать о "АРЕНДЕ"

1. Дата (проверено)
2. Дата возврата
3. Срок исполнения
4. Скидка (скажем, за аренду 3 получить 1 бесплатно, и это четвертый или что-то)