2010-07-29 4 views
0

Я создаю веб-приложение, которое (в идеале) позволит пользователям следить за темами обсуждения (которые находятся в Q & Формат, подобный этому сайту), но также следует за другими типами контента, такими как фирм и школ, имеющих профильные страницы. (Сайт предназначен для оказания помощи в поиске работы на профессиональном уровне, поэтому в фокусе есть страница профиля для голых костей для фирм, школ и т. Д.)Структура MySQL для следующих нескольких типов контента

Было бы более эффективно иметь одну таблицу «Follow», имеет поле follow_entity_type, которое будет доступным, а затем перенаправляется на соответствующую таблицу содержимого (Q & A, фирмы и т. д.)? Или мне нужно иметь таблицу «Follow» для каждого типа содержимого, к которому необходимо получить доступ отдельно, когда я пытаюсь скомпилировать фид пользователя? Первое, по-видимому, влечет за собой более сложное кодирование и запросы, в то время как второе затруднит организацию хронологической подачи для всех типов сообщений.

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

ответ

0

Я бы взял поле follow_entity_type чаще всего. На мой взгляд, намного проще интегрировать один дополнительный выбор из списка сущностей, а затем интегрировать новую таблицу соединений во всех экземплярах списка. Это также означало бы, что только 1 вместо 2 таблиц нужно было бы добавить на «тип контента», в котором хранится запись &. Запросы не становятся намного сложнее ИМХО.

+0

Спасибо за совет! Я так же думаю. – tchaymore

1

Подумайте, как вы это сделаете в дизайне OO: у вас будет общий суперкласс или интерфейс для всех типов вещей, которые могут быть выполнены. Назовите это Followable.

interface Followable { } 

class QandA implements Followable { ... } 
class Profiles implements Followable { ... } 

Затем, когда вы представляете коллекцию «followable» объектов, вы убедитесь, что коллекция состоит из объектов, для которых $object instanceof Followable правда.

Вы можете сделать то же самое с таблицами SQL:

CREATE TABLE Followables (follow_id INT AUTO_INCREMENT PRIMARY KEY ...); 

CREATE TABLE QandA (qanda_id INT PRIMARY KEY ... , 
    FOREIGN KEY (qanda_id) REFERENCES Followables(follow_id)); 
CREATE TABLE Profiles (profile_id INT PRIMARY KEY ... , 
    FOREIGN KEY (profile_id) REFERENCES Followables(follow_id)); 

Теперь ваши ссылки на вещи пользователя следует внешнеторговый ключ к Followables:

CREATE TABLE UserFollows (
    user_id INT NOT NULL, 
    follow_id INT NOT NULL, 
    PRIMARY KEY (user_id, follow_id), 
    FOREIGN KEY (user_id) REFERENCES Users(user_id), 
    FOREIGN KEY (follow_id) REFERENCES Followables(follow_id) 
); 

Смотрите также Class Table Inheritance.

+0

Мне нравится настройка, но по какой причине мы не можем сделать так, чтобы пользователь был доступен? – Wrikken

+0

Вы можете сделать что-нибудь доступным, я просто показывал два примера. –

+0

Проверьте, никаких проблем нет, хороший. – Wrikken