Схема схемы системы обмена сообщениями в стиле Facebook

Я ищу, чтобы внедрить систему сообщений в стиле facebook (потоковые сообщения) в мой сайт.Схема схемы системы обмена сообщениями в стиле Facebook

Считаете ли вы, что эта схема разметки выглядит нормально?

alt text

Учение schema.yml:

UserMessage: 
    tableName: user_message 
    actAs: [Timestampable] 
    columns: 
    id: { type: integer(10), primary: true, autoincrement: true } 
    sender_id : { type: integer(10), notnull: true } 
    sender_read: { type: boolean, default: 1 } 
    subject: { type: string(255), notnull: true } 
    message: { type: string(1000), notnull: true } 
    hash: { type: string(32), notnull: true } 
    relations: 
    UserMessageRecipient as Recipient: 
     type: many 
     local: id 
     foreign: message_id 
    UserMessageReply as Reply: 
     type: many 
     local: id 
     foreign: message_id 
UserMessageReply: 
    tableName: user_message_reply 
    columns: 
    id: { type: integer(10), primary: true, autoincrement: true } 
    user_message_id as message_id: { type: integer(10), notnull: true } 
    message: { type: string(1000), notnull: true } 
    sender_id: { type: integer(10), notnull: true } 
    relations: 
    UserMessage as Message: 
     local: message_id 
     foreign: id 
     type: one 
UserMessageRecipient: 
    tableName: user_message_recipient 
    actAs: [Timestampable] 
    columns: 
    id: { type: integer(10), primary: true, autoincrement: true } 
    user_message_id as message_id: { type: integer(10), notnull: true } 
    recipient_id: { type: integer(10), notnull: true } 
    recipient_read: { type: boolean, default: 0 }

Когда новый ответ сделал, я буду убеждаться логическое значение для «recipient_read» для каждого получателя устанавливается в ложь, и, конечно я уверен, что sender_read тоже установлен на false.

Я использую хэш для URL: http://example.com/user/messages/aadeb18f8bdaea49882ec4d2a8a3c062

(как идентификатор будет начиная с 1, я не хочу иметь http://example.com/user/messages/1 Да, я мог бы начать приращение от большего числа, но. я бы предпочел начать с 1.)

Это хороший способ обойти это? Ваши мысли и предложения были бы чрезвычайно оценены.

Спасибо, ребята!

источник

2011-01-10 Flukey

UserMessage и UserMessageReply оба представляют один класс - сообщение. Я хотел бы создать один класс и связать его с самим собой полем reply_id. Читайте здесь о взаимоотношениях гнезд: http://www.doctrine-project.org/projects/orm/1.2/docs/manual/defining-models/zh#relationships:join-table-associations:self-referencing-nest-relations – Dziamid

Ах, интересно. Огромное спасибо. – Flukey

Вы с этим? Это было сделано в рельсах 3? – Angela

В чем разница между user_message.created_at и user_message_recipient.created_at?

Тот же вопрос для updated_at. (Позже: я предполагаю, что user_message_recipient.updated_at может быть временем, когда получатель прочитал сообщение. Если это так, я бы предпочел более значимое имя.)

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

Когда новый ответ сделал, я буду убеждаться логическое значение для «recipient_read» для каждого получателя устанавливается в ложь, и, конечно, я позабочусь sender_read установлен в ложь тоже.

Надеюсь, это означает, что dbms проверит правильность этих булевых языков.

источник

2011-01-11 01:45:19

Привет, Майк, спасибо за ваш ответ. created_at, updated_at. Это поведение плагина ORM. Каждая запись имеет поле created_at. ANd, когда обновляется запись, обновляется соответствующее поле updated_at. Мне нравится иметь такое поведение. О, и да, dbms проверит это, но есть ли у вас лучшая идея? Я мог бы иметь таблицу потоков, как было предложено в приведенном выше комментарии, и иметь parent_id, child_id. Благодарю. – Flukey

Я думал по строкам тех булевых, которые были объявлены в базе данных как «NOT NULL» и «DEFAULT FALSE». Это гарантирует, что они начнутся с правильных значений. –

Я также пытался создать систему сообщений с использованием базы данных, наиболее распространенная ошибка заключается в том, что каждый пользователь имеет разное состояние чтения-непрочитанного сообщения. я вряд ли показываю в схеме базы данных, но вкратце вы должны подумать о создании флага, такого как isread для каждого пользователя для каждого user_message и user_message_reply, поэтому каждый пользователь просто видит непрочитанное сообщение.

источник

2011-01-12 06:34:55 ikhsan

Что относительно этой модели?

MESSAGES    USER_MESSAGES 
========    ============= 
id     id 
content    message_id 
reply_message_id  recipent_id 
         read 
         trash 
         hide

источник

2012-02-29 20:21:32 rkleine15

Схема схемы системы обмена сообщениями в стиле Facebook

ответ

Смежные вопросы