#firebase #localization #firebase-realtime-database #denormalization
#firebase #локализация #firebase-база данных в реальном времени #денормализация
Вопрос:
Я новичок в мире 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? Я не думаю, что накладные расходы или задержка здесь действительно пострадают.