Сложно ответить, потому что вы спрашиваете мнение о структуре вашей базы данных, когда у нас нет концепции вашего варианта использования.
Однако позвольте мне выбросить пару мыслей.
если я выберу название документа, чтобы мне было проще
запрос
Имя ключа не связано и не имеет ничего общего с дочерними данными, содержащимися в запросе. посмотрите
users
-Y89j9kksd0kskd //a users uid for example
email: "thing@test.com"
-y9099k,msp,sps
email: "dude@thing.com"
Если вы хотите запросить электронное письмо с именем «dude@thing.com», запрос «игнорирует» каждый дочерний ключ (-Y89 ... -y90 ... и т. Д.) И просматривает узел email: внутри.
Если вы называете ключи и делаете запрос, это все равно не имеет значения, оно все равно игнорирует этот ключ. Он возвращается в качестве ключевого свойства снимка, но здесь это не проблема, поскольку мы знаем, что значением является адрес электронной почты: child.
users
-thing@test.com
email: "thing@test.com"
-dude@thing.com
email: "dude@thing.com"
Проблема здесь в том. не может использоваться в именах ключей, поэтому теперь вы должны кодировать / декодировать каждый ключ. Это много лишнего кода.
Что еще более важно, если адрес электронной почты изменится, вам придется изменять при каждом появлении этого адреса электронной почты во ВСЕХ ваших данных . А поскольку вы не можете изменить ключи, вам придется удалить каждый узел и переписать его. Тьфу.
Использование первого примера - путь. Вы можете сохранить ссылку на этого пользователя во всем приложении (например, с помощью uid), и независимо от того, какие дочерние данные изменяются в этом узле (например, электронная почта), остальные данные остаются неизменными.
Здесь есть но ... всегда есть но.
Иногда вам может понадобиться узнать, существует ли фрагмент данных по определенному пути - в этих случаях вы можете получить к нему прямой доступ. Например
users
-Y89j9kksd0kskd //a users uid for example
email: "thing@test.com"
things_i_like
food:
pizza: true
taco: true
color:
blue: true
wine:
ornellaia: true
Предположим, у меня есть этот пользовательский uid -Y89j9kksd0kskd, и я хочу посмотреть, является ли пицца той едой, которая им нравится. Вместо того, чтобы запрашивать пищевой узел, я могу получить к нему прямой доступ по номеру
/uid/things_i_like/food/pizza
и посмотрите, является ли значение истинным (или посмотрите, существует ли оно)
или посмотреть, нравится ли им замечательное итальянское вино Орнеллайя, проверить на правду (или существование) в
/uid/things_i_like/wine/ornellaia
Как вы можете видеть, использование ключей uid или Firebase на верхнем уровне не влияет на ваши запросы, но когда вы знаете, что хотите получить доступ к определенной точке данных в известном узле, присвоение имен ключам узла является одним из решений.
Все зависит от того, какие запросы вы хотите запускать ... Если вы хотите знать всех пользователей, которым нравится пицца, это будет запрос (и немного другая структура), поэтому вы не будете знать потребуется конкретный путь и запрос.