Моделирование чата один на один на базе Firebase

Question

Я создаю функцию обмена сообщениями один на один, цель которой заключается в следующем:

Существует уникальный проект, и люди (два или более) могут общаться о проекте, чтобы мы могли думать, что проект В комнате, где я искал различные моделирующие структуры, наиболее распространенным является что-то вроде следующего:

Chats
    - projectId (room)
        - messages
                message
                userId
                name
                profilePicture
                posted (timestamp)

Но я думал в плоской структуре что-то вроде

Messages
    ProjectId
    Message
    userId
    name
    profilePicture
    posted

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 1 Это будет иметь огромное влияние на веб-приложение, которое я создаю, и при этом говорят, что очень важно сделать правильное решение (я уверен, что не всегда есть правильное или неправильное ". но подумайте о цели чата)

Просто некоторые вопросы, которые приходят мне в голову:

• Есть ли какие-либо последствия для производительности при использовании плоской структуры?
• Каковы преимущества использования вложенной структуры, как указано в примере № 1
• , какое решение дешевле? (читает / пишет)

Answer 1

Есть преимущества от обоих предложенных вами решений. Давайте углубимся в них:

• производительность : они очень похожи с этой точки зрения. Фактически, если вы хотите получить чат из Firestore, во втором случае просто сделайте запрос для сообщений определенного чата и проанализируйте необходимую информацию из первого полученного вами документа (так как в каждом сообщении у вас есть идентификатор пользователя, имя , profilePicture, et c ...). При первом подходе эта операция проста, поскольку вы уже запрашиваете документ Chat .
• структура : первое решение, которое я предпочитаю, потому что понятно, что это происходит, и, поскольку Firestore не имеет схемы, он обеспечивает четкий дизайн. При втором подходе вы в основном выравниваете свою БД, но вы также подвергаете свои сообщения проблемам конфиденциальности. На самом деле, настройка правил в первом случае довольно проста, просто предоставьте пользователям доступ только к тем чатам, в которых они участвуют. Но в этом случае все пользователи могут, "возможно" , читать друг друга сообщения, которые не должны быть чем-то, что вы хотите.
• стоимость : это в основном зависит от того, что вы будете делать с этими документами. На самом деле, стоимость Firestore зависит либо от количества документов для чтения / записи , но и от количества хранимых вами данных. Здесь первое решение явно лучше, поскольку вы не добавляете избыточность для таких полей, как profilePicture, name, userID и т. Д. c ... Эти поля логически принадлежат сущности Chat, а не ее сообщениям.

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