Моделирование пользователей, групп, портфелей и носителей с использованием MVC-подхода

Question

Я создаю простой проект для сайта социальной сети с использованием парадигмы MVC (в CakePHP) для проекта, У меня есть таблица под названием «Пользователи», которая хранит все Сведения о пользователе. У меня есть таблица групп, в которой хранятся все данные Группы, связь между этими двумя моделями имеет и принадлежит многим, тогда у меня есть таблица group_portfolios, в которой хранятся все портфели, принадлежащие группе, и таблица user_portfolio, в которой хранится весь портфель информацию, связанную с пользователем. Пользователя может иметь несколько портфелей группа может иметь несколько портфелей Пользователя может иметь много средств массовой информации группы может иметь много носителей

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

1) Я правильно думаю о моделировании приложения MVC?
2) Поскольку я отделяю функциональность для пользователей и групп, я заканчиваю двумя таблицами для всей информации, относящейся к ним, например, для средств массовой информации и для портфеля. Из-за этого возникают проблемы с резервированием и эффективностью, особенно при поиске портфеля и т. Д.?
3) Будет ли это иметь возможность масштабирования, когда я хочу добавить дополнительные функции позже?
4) Есть ли лучший способ моделирования системы?

Спасибо

Answer 1

Вы можете использовать один носитель и одну таблицу портфелей. Добавьте дополнительное поле, в котором указывается, принадлежит ли он пользователю или группе. Затем не добавляйте атрибут $ attributeTo к вашей модели, но используйте метод bindModel для динамического прикрепления правильной модели.

В качестве альтернативы вы также можете использовать UUID (mysql: varchar 36) вместо целых чисел для ваших идентификаторов. UUID никогда не сталкиваются. Таким образом, вы можете сделать группу Portfolio и Media для группы пользователей и, используя одно и то же поле. Это работает, потому что никогда не будет пользователя, который имеет тот же ID, что и группа, когда вы используете UUID.Пример:

class Media { 
    $belongsTo = array(
     'User' => array('foreignKey' => 'parent_id'), 
     'Group' => array('foreignKey' => 'parent_id'), 
    ); 
} 

Первый технически более правильный. Последнее проще реализовать, и вам могут не нравиться более длинные URL-адреса, которые создают длинные UUID.

Редактировать: Чтобы отправить комментарий о уникальности, UUID разработаны для того, чтобы быть глобально уникальными. То есть не только у вас не будет дубликатов внутри вашей собственной базы данных, но не должно быть никаких дубликатов в мире. В любом месте.

См. this Wikipedia article о вероятности дублирования с использованием UUID. Краткая история: после генерации 70 000 миллиардов UUID вероятность иметь ровно один дубликат составляет 4 из 10 миллиардов. У вас есть больше шансов получить удар молнии дважды в тот же день :-)

Answer 2

Я использовал RoR и замок, не CakePHP, так что я буду говорить в общих чертах.

1: То, что вы делаете и что вы должны продолжать делать это называется «Domain Modeling» - MVC отлично подходит для этого, как ваши модели представления объектов модели домена

2: Вы может изменить портфолио и модели мультимедиа вместо ссылки на идентификатор его родителя, у вас есть ObjectId и ObjectType. ObjectId - это идентификатор родителя, а тип ObjectType - это тип. Вы не сможете автоматического провода в отношениях, но вместо этого можно сделать с помощью специального кода, так, чтобы все средства массовой информации для пользователя становится

select * from Media where ObjectId = [userid] and ObjectType = 'User' 

вместо

select * from UserMedia where UserId = [userid] 

3: да , это масштабируемый дизайн. не забудьте нажимать столько моделей для самих моделей (или хранилищ), чтобы они «просто работали»

4: Возможно, но вы никогда не получите «идеальную» систему. MVC великолепна, и ваш дизайн кажется прочным для простой социальной сети. Вы, несомненно, добавите такие вещи, как сообщения/комментарии и т. Д.

Answer 3

В соответствии с тем, что сказал Сандер Маречал о GUID, вы можете рассмотреть PolymorphicBehavior для вашей модели мультимедиа. Это ускорит ваше приложение, и вам не придется беспокоиться о нарушениях отношений в любое время.

О вашем вопросе дизайна .. мы действительно не знаем ваше приложение и не можем предоставить подробные ответы. Нет, это ложь: Я не хочу давать потенциально неправильный ответ.

Однако я могу дать вам несколько советов. :) Вы должны сесть и нарисовать свои модельные отношения и подумать, как они будут использоваться в реальной жизни. Затем посмотрите, нет ли чего-то, или, может быть, слишком много чего-то. Оптимизация и минимизация данных, возвращаемых из вашей базы данных. Важнейшей концепцией является простота. Если это не так просто, то это неправильно.

Если вы идете на полпути и понимаете, что сделали ошибку дизайна - признаете, что вы сделали ошибку дизайна и исправите ее! Иногда вы не можете предсказать все, и в нем нет стыда (ну, пока вы что-то узнаете ...).