Лучше хранить данные базы данных в ключе узла или в виде значения? - PullRequest
0 голосов
/ 28 июня 2019

У меня есть узел временной шкалы, как показано ниже. Сначала я сохраняю uid пользователя, который следует за некоторыми пользователями, которые сделали сообщения. Затем я сохраняю posterUID и postID рядом с ним, разделяя информацию символом «:», чтобы можно было легко получить каждую часть позже. Затем я храню метку времени сообщения.

"Post_Timeline" : {
    "uid" : {
      "posterUID:postID" : {//example postID value: "post:583190375"
        "timeStamp" : 583190375
      },

Интересно, было бы эффективнее сделать что-то вроде (под эффективностью я имею в виду более быстрое получение или получение правильной информации. Или, может быть, с точки зрения стоимости базы данных и т. Д.):

"Post_Timeline" : {
    "uid" : {
      "randomID" : {
        "timeStamp" : 583190375,
        "posterUID" : "JNFSD78436VSFFDSF"
      },

Код, который я использую для получения:

ref.child("Timeline").child((Auth.auth().currentUser?.uid)!)
            .queryOrdered(byChild: "timeStamp")
            .queryLimited(toLast: 10)
            .observeSingleEvent(of: .value, with: { (snapshot) in

                var i = 0
                for case let rest as DataSnapshot in snapshot.children.reversed() {//.reversed()
                    let keyValue = rest.key
                    let uid = keyValue.split(separator: ":")[0]
                    let postIDDoubleVal = keyValue.split(separator: ":")[2]

                    self.fetchUsersPost(uid: "\(uid)", postID: "post:\(postIDDoubleVal)")

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

1 Ответ

0 голосов
/ 28 июня 2019

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

Я изложу этоответьте, приведя примеры того, почему

"posterUID:postID"

может быть плохим.

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

Проблема № 1: Что, если один и тот же пользователь дважды публикует сообщение?

uid
   posterUID:postID
      timeStamp: 583190375
   posterUID:postID
      timeStamp: 123456789

Ах, вы не можете этого сделать, поскольку у вас не может быть дубликатов ключей в одном и том жеnode

Issue # 2: Запросы любого типа по конкретному сообщению невозможно выполнить без чтения всех узлов и фильтрации кода.Это может быть много данных или избыточность

Проблема № 3: Получение всех сообщений о конкретном сообщении от любого отслеживаемого пользователя.Firebase не поддерживает частичные завершающие строковые запросы.

Проблема № 4: Post_1234 была удалена, и теперь мне нужно удалить ссылки на этот узел из "uid"узел.Что ж, этого не произойдет без чтения во всех дочерних узлах.

Существует ряд дополнительных проблем, с которыми может столкнуться, но они не могут быть решены без понимания всего объемакакие запросы могут быть выполнены.

Это более гибкое решение

Post_Timeline
   uid
      randomID
        timeStamp: 583190375,
        posterUID: "JNFSD78436VSFFDSF"
Добро пожаловать на сайт PullRequest, где вы можете задавать вопросы и получать ответы от других членов сообщества.
...