2016-10-31 4 views
0

Я работаю над проектом, в котором пользователи могут отправлять сообщения. Но мне интересно, эффективна ли структура базы данных firebase. Ниже приведен пример моей базы данных. У меня есть сообщения, в которых содержится все сообщения, которые будут публиковать пользователи. и каждый пользователь сможет отслеживать свои собственные должности, имея posts ребенка в uid. Есть ли лучший способ структурирования моих данных? или мне хорошо идти? Любой совет будет принят во внимание!Лучший способ структурирования базы данных firebase

{ 
"posts" : { 
    "-KVRT-4z1AUoztWnF-pe" : { 
    "caption" : "", 
    "likes" : 0, 
    "pictureUrl" : "https://firebasestorage.googleapis.com/v0/b/cloub-4fdbd.appspot.com/o/users%2FufTgaqudXeUciW5bGgCSfoTRUw92%2F208222E1-8E20-42A0-9EEF-8AF34F523878.png?alt=media&token=9ec5301e-d913-44ee-81d0-e0ec117017de", 
    "timestamp" : 1477946376629, 
    "writer" : "ufTgaqudXeUciW5bGgCSfoTRUw92" 
    } 
}, 
"users" : { 
    "ufTgaqudXeUciW5bGgCSfoTRUw92" : { 
     "email" : "[email protected]", 
     "posts" : { 
      "-KVRT-4z1AUoztWnF-pe" : { 
       "timestamp" : 1477946376677 
      } 
     }, 
     "profileImageUrl" : "https://firebasestorage.googleapis.com/v0/b/cloub-4fdbd.appspot.com/o/profile_images%2F364DDC66-BDDB-41A4-969E-397A79ECEA3D.png?alt=media&token=c135d337-a139-475c-b7a4-d289555b94ca", 
     "username" : "Test1" 
     } 
    } 
} 
+0

Существует не один лучший способ структурирования ваших данных. Все зависит от того, как вы хотите использовать эти данные в своем приложении. Я рекомендую прочитать эту статью в [Моделировании данных NoSQL] (https://highlyscalable.wordpress.com/2012/03/01/nosql-data-modeling-techniques/). –

ответ

0

Работа с NoSQL данных, ваша потребности заботиться о нескольких вещах: -

  • Избегайте вложение данных Too Deep
  • Flatten вашей структуре данных, как это возможно
  • Предпочтительные словари
  • Правила безопасности [Firebase]

Попробуйте эту структуру: -

users:{ 
    userID1: {..//Users info.. 
      posts:{ 
       postID1: true, 
       postID2: true, 
       postID3: true, 
        } 
       }, 
    userID2: {..//Users info..}, 
    userID3: {..//Users info..}, 
    userID4: {..//Users info..}, 
    }, 
posts: { 
userID1 :{ 
    postID1: {..//POST CONTENT }, 
    postID2: {..//POST CONTENT }, 
    postID3: {..//POST CONTENT }, 
    } 

    } 
0

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

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

Этот процесс выравнивания данных известен как «денормализацию» и этот раздел Firebase Doc делает хорошую работу по обеспечению руководства:

https://firebase.google.com/docs/database/android/structure-data

В вашем примере выше я вижу сообщения метаданных, вложенные под «users», вложенный список, который растет. Каждый раз, когда что-то меняется под «пользователями», слушатель загорается, чтобы обновить клиент, и все эти данные будут переданы в каждом ответе. Вместо этого вы могли бы рассмотреть возможность получения данных сообщений из узла «posts» на основе uuid автора.

+0

Вы имеете в виду, вместо того, чтобы получать почтовые данные по уникальному postId, вы можете получить его с помощью uid? Тогда, что, если пользователи имеют более одного сообщения, как бы вы различали сообщения? –

+0

Вместо того, чтобы другой корень был «сообщениями», вы могли дублировать uuid автора как узел с сообщениями как дочерние. Таким образом, ваш выбор «Получить мне все сообщения для этого пользователя», а не «Получить мне все об этом пользователе, включая все их сообщения». Это упростило бы использование RecyclerView для сообщений. – Lucy

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