Использование даты в качестве идентификатора документа Firestore?

# #firebase #google-cloud-firestore #nosql #firebase-security

Вопрос:

У меня есть приложение для дневника, в котором я хочу иметь один документ на каждый день. Мой вопрос в том, будет ли хорошей практикой использовать строку даты и времени ISO 8601 в качестве идентификатора документа. Поскольку каждый день может быть только один документ, это будет уникальный идентификатор.

Или мне следует сохранить дату в документе и использовать случайный идентификатор документа? Что было бы лучшим выбором?

Один вопрос, который я хочу сделать, — это проверить, есть ли документ с определенной датой (например, сегодня). Если это так, я хочу получить этот документ, в противном случае, если на сегодня нет документа, я хочу его создать.

Комментарии:

1. Я отредактировал свой вопрос

Ответ №1:

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

Комментарии:

1. Является ли ISO 8601, такой как «2021-11-01T09:12:00.376″ , приемлемым идентификатором документа или » — «или»: «не допускается?

2. Да, это приемлемый формат удостоверения личности документа. Но это также похоже на то, что вы могли бы легко попробовать в консоли Firebase.

3. Я пробовал разные вещи, и в итоге это стало моим лучшим решением: поскольку каждый день уникален, я хочу иметь идентификатор документа «2021-11-01» без времени, чтобы было легко запрашивать. Но как насчет горячих точек, как упоминалось здесь: cloud.google.com/firestore/docs/best-practices?hl=en Будет ли это проблемой?

4. Если бы вы использовали случайный идентификатор документа и сохраняли дату только в поле, вам понадобился бы индекс этого поля, чтобы иметь возможность запрашивать его — и в конечном итоге возникла бы точно такая же ситуация в отношении горячих точек. Также: поскольку вы говорите о приложении для ведения дневника, маловероятно, что в итоге у вас будет слишком много записей.

Ответ №2:

Это кажется хорошим, однако firebase не рекомендует этого делать. Это связано с тем, что использование дополнительных имен идентификаторов документов не рекомендуется. Это может быть Customer1, Customer2, … Клиент, или в вашем случае даты. 10-31-21, 11-1-21, 11-2-21, … постепенно.

Также обратите внимание на их второе предложение: избегайте использования / прямой косой черты в идентификаторах документов.

Или мне следует сохранить дату в документе и использовать случайный идентификатор документа? Что было бы лучшим выбором?

Я бы выбрал последнее. Используйте случайный идентификатор документа, а затем сохраните дату внутри.

С учетом сказанного, лучшие практики и именно это, лучшие практики. Это не правила. В вашем случае, если использование даты в качестве идентификатора документа облегчает задачу и требует меньшего количества считываний, это может быть лучшим выбором.

Комментарии:

1. Спасибо, будет ли монотонное увеличение большой проблемой?

2. Не могли бы вы объяснить, что вы подразумеваете под «монотонным увеличением»?

3. Это означает, что идентификаторы документов выглядят следующим образом: Потребитель1, Потребитель2,…

4. Это вообще не было бы проблемой.