Блог

Я новичок в мире nosql, и мне трудно разобраться с определенным аспектом денормализации и с тем, как должна быть спроектирована моя база данных. Я буду использовать Firebase, но я считаю, что эта проблема распространяется на денормализацию в целом.

Проблема, с которой я сталкиваюсь, заключается в том, как пометить «лайки» пользователя по отношению к фрагменту данных, когда эти данные (назовем их «строками») локализованы на многих языках. В идеале я бы сделал что-то вроде:

 {
  en: {
    strings: {
      0: "String 0 in English",
      1: "String 1 in English",
      ...
    }
  },
  es: {
    strings: {
      0: "String 0 in Spanish",
      1: "String 1 in Spanish",
      ...
    }
  }
}
  

Таким образом, я мог получить доступ к желаемому тексту на желаемом языке, используя только путь запроса. Легко — за исключением симпатий. Поскольку это глобальный и локализованный набор данных, если испанскому пользователю нравится «string [0]», это должно быть похоже на «string [0]» для всех языков. Я даже не знаю, где хранить «likeCount» в подобной настройке.

Другой подход, о котором я подумал, заключался в объединении локализованных строк, таких как:

 {
  strings: {
    0: {
      likeCount: 110,
      string: {
        en: "String 0 in English",
        es: "String 0 in Spanish"
      }
    },
    1: {
      likeCount: 13,
      string: {
        en: "String 0 in English",
        es: "String 1 in Spanish"
      }
    },
    ...
  }
}
  

Как вы можете видеть, здесь более очевидно, что «likeCount» в этом случае может быть прикреплен непосредственно к объекту. Но теперь, когда я запрашиваю любую или несколько «строк», я верну ВСЕ языки, и тогда клиент должен будет отобразить, какой из них применяется. С большими строками и множеством языков это кажется большим количеством накладных расходов.

Тогда мой вопрос заключается в том, каков наилучший способ структурирования данных в подобном случае, чтобы строки и likeCounts были быстрыми и эффективными?

Если это поможет, и вы хотите сделать все возможное с ответом / примером, я захочу, чтобы объект «user» ссылался на все понравившиеся строки, но я НЕ буду требовать, чтобы «строка» также ссылалась на пользователей, которым это понравилось.

Редактировать:

Еще один случай, который я мог бы рассмотреть, — это выполнение запросов на объединение вручную в клиенте. Если бы я использовал архитектуру в варианте 1 выше, чтобы легко получить локализованный текст, я мог бы добавить дополнительный объект верхнего уровня, такой как:

 {
  en: {
    strings: {
      0: "String 0 in English",
      1: "String 1 in English",
      ...
    }
  },
  es: {
    strings: {
      0: "String 0 in Spanish",
      1: "String 1 in Spanish",
      ...
    }
  },
  likes: {
    0: 110,
    1: 13,
    ...
  }
}
  

Затем, когда в клиенте я мог бы выполнить два одновременных запроса и объединить / объединить результаты. Звучит ли этот подход разумно для Firebase? Я не думаю, что накладные расходы или задержка здесь действительно пострадают.