Использование автоматически сгенерированного идентификатора документа Firestore по сравнению с использованием пользовательского идентификатора
В настоящее время я выбираю структуру данных Firestore.
Мне понадобится products коллекция, а products предметы будут жить в ней как документы.
Вот мои поля продукта:
- Строка уникальный ключ:
- описание: массив строк
- картинки: массив объектов
- цена: номер
ВОПРОС
Должен ли я использовать автоматически сгенерированный Firestore идентификатор в качестве ID моих документов, или лучше использовать мой uniqueKey (который я буду запрашивать во многих случаях) в качестве идентификатора документа? Есть ли лучший вариант между этими двумя?
Я предполагаю, что если я использую свой uniqueKey, это облегчит мою жизнь при поиске одного документа, но мне также придется запрашивать более 1 продукта во многих случаях.
Используя мой uniqueKey как ID:
db.collection("products").doc("myUniqueKey").get();
Используя мой автоматически сгенерированный Firestore ID:
db.collection("products").where("uniqueKey", "= = ", "myUniqueKey").get();
Это достаточная причина, чтобы использовать мой uniqueKey вместо автоматически сгенерированного? Есть ли здесь эмпирическое правило? Какова наилучшая практика в этом случае?
Ответы 1
Что касается выполнения запросов от клиента с использованием только той информации, которую вы указали в вопросе, я не вижу большой практической разницы между получением документа с использованием его известного идентификатора или запросом в поле, которое также уникально. . В любом случае индекс используется на стороне сервера и стоит ровно 1 прочитанный документ. Документ get() может быть немного быстрее, но его не стоит оптимизировать таким образом (на мой взгляд).
Принимая решение о подобном моделировании данных, важнее думать о таких вещах, как поведение системы под нагрузкой и правилах безопасности.
Если вы читаете и пишете много документов, идентификаторы которых имеют свойство последовательного доступа, вы можете столкнуться с горячие точки при такой записи. Итак, если вы хотите использовать свой собственный идентификатор и предполагаете, что будете читать и записывать их в этой последовательности при большой нагрузке, у вас могут возникнуть проблемы. Если вы не ожидаете, что это произойдет, то, вероятно, не имеет большого значения, чей идентификатор вы используете.
Если вы собираетесь использовать правила безопасности для ограничения доступа к документам и для этого используете содержимое других документов, вам необходимо иметь возможность однозначно идентифицировать эти документы в своем правиле. Вы не можете выполнить запрос к коллекции в правилах, поэтому вам могут понадобиться осмысленные идентификаторы, которые дадут прямой доступ при использовании правилами. Если ваши собственные идентификаторы можно легко использовать таким образом в правилах безопасности, в целом это может быть более удобным. Если вы вынуждены использовать сгенерированные идентификаторы Firestore, может оказаться неудобным, сложным или дорогим пытаться поддерживать связь между вашими идентификаторами и идентификаторами Firestore.
В любом случае решение, которое вы принимаете, заключается не только в том, какой идентификатор «лучше» в общем смысле, но и в том, какой идентификатор лучше для вашей конкретной, ожидаемой ситуации, под нагрузкой, с учетом безопасности.
@cbdeveloper Эй, я просто хочу знать, как вы решили или, что более важно, какой-либо ресурс, сообщение в блоге помогло вам принять решение? :) Я как раз в то же решение сделать
@ lukas28277 Эй, Лукас, для такого рода коллекций с, возможно, «бесконечными» элементами, такими как коллекция products, которую вы все равно всегда запрашиваете для какого-либо свойства, я выбрал autoID. Но для определенных коллекций с конечным числом элементов, которые я получу doc напрямую, без запроса, я даю им «удобный для разработчиков» идентификатор. Допустим, у меня есть коллекция siteData с несколькими документами для одного языка. Каждому doc я бы назвал siteDataDoc_EN, siteDataDoc_FR и т. д. Надеюсь, это поможет.
Большое спасибо :) хорошо, я собираюсь создать базу данных пользователей и захочу фильтровать людей, скажем, по городу, навыкам и т. д., поэтому я думаю о лучшем и наиболее эффективном способе в смысле количества необходимых чтений.
Спасибо, Дуг! Я думаю, что в дальнейшем я буду лучше знать, как рассуждать об этих выборах. Но это было действительно полезно!