Предпочтение структуры базы данных

Question

Предпочтение структуры базы данных

Причина, по которой вы не получаете точное значение a, состоит в том, что R хранит его как double вместо целого. Поскольку a очень велика, существует некоторое округление, когда вы назначаете a.

Обычно для хранения вещей в виде целых чисел вы должны использовать L в конце чисел; что-то вроде:

a <- 12L
class(a)
# [1] "integer"

Однако ваш номер слишком велик для стандартного целого числа в R, и вы вынуждены использовать двойное представление:

a <- 123456789123456789123456789L
# Warning message:
# non-integer value 123456789123456789123456789L qualified with L; using numeric value 
class(a)
# [1] "numeric"

Вам понадобится многократная точность, чтобы точно хранить целое число, такое большое. Одним из вариантов был бы пакет gmp:

library(gmp)
a<-as.bigz("123456789123456789123456789")
a
# Big Integer ('bigz') :
# [1] 123456789123456789123456789

Другие варианты арифметики с несколькими точками доступны в подзаголовке «Многоточечная арифметическая и символьная математика» в задаче CRAN для численной математики вид .

0

mongodb nosql google-cloud-firestore

задан TorchNight MC 16 January 2019 в 01:03

2 ответа

Другие вопросы по тегам:

mongodb nosql google-cloud-firestore

Похожие вопросы:

score 0 · Answer 1

Не существует «идеального», «лучшего» или «правильного» решения для структурирования базы данных Cloud Firestore.

Я везде гуглил, и во всех документах, как правило, предлагается предотвращать структуру вложенных данных, но как эта вложенная структура данных может быть плохой?

В отличие от базы данных реального времени Firebase, где отображая список еженедельных повесток дня, вы бы скачали весь пользовательский объект, в Cloud Firestore это больше не проблема. Поэтому размещение вложенной коллекции с именем weekly_agenda в каждом пользовательском документе не будет проблемой. Недостатком первого подхода является то, что вы не можете запрашивать вашу базу данных для отображения всех повесток дня всех пользователей. Таким образом, возможная схема, представляющая собой сочетание вашего решения, может быть:
Firestore-root
   |
   --- users (collection)
   |    |
   |    --- uid (document)
   |         |
   |         --- username: "John"
   |         |
   |         --- age: 22
   |         |
   |         --- gender: "male"
   |
   --- weeklyAgenda (collection)
         |
         --- weeklyAgendaId (document)
                |
                --- uid: "UidOfTheUser"
                |
                --- //Weekly Agenda Properties
Используя эту схему, вы можете просто:
Запросить всех пользователей из всей базы данных, прикрепив слушатель на users коллекции.

Запросите повестки дня всех пользователей, подключив слушателя к коллекции weeklyAgenda.
Запросите все повестки дня, принадлежащие одному пользователю, с помощью запроса, который в Android может выглядеть следующим образом:
FirebaseFirestore rootRef = FirebaseFirestore.getInstance();
Query query = productsRef.whereEqualTo("uid", uid);
Этот запрос также может быть написан на других языках программирования.

score 0 · Answer 2

(для дальнейшего использования этот тип «передового опыта» лучше подходит для Firebase Google Group , чем для переполнения стека)

Во-первых, я не уверен, что это был преднамеренное или ошибка в вашей диаграмме, но я просто хочу отметить, что в структуре # 1 вы должны иметь поля username, age и gender в качестве полей в пользовательском документе, а не в качестве подколлекции в качестве диаграммы предлагает. (Я предполагаю, что это то, что вы имели в виду, учитывая ваше описание, но просто чтобы быть уверенным, поскольку пользовательские данные будут плохо использовать подколлекции).

Теперь перейдем к вашему основному вопросу:

Firestore значительно выигрывает при работе с плоской структурой данных , то есть с большим количеством небольших документов, в отличие от небольшого количества. больших документов. Это один из моментов, на которые ссылаются люди, когда говорят об анти-вложенных методах.

То, как вы структурируете свои данные, зависит именно от того , как вы планируете взаимодействовать с ними , а не только от того, на что имеет смысл смотреть.

Structure #1 не будет работать так же хорошо, как Structure #2, если вы когда-либо планируете, чтобы пользователь мог видеть повестки дня других пользователей. Это все еще будет работать, но запрос будет намного ужаснее.

При этом, если повестки дня видны только их владельцам, тогда Structure #1 может иметь больше смысла, просто учитывая тот факт, что организация более интуитивно понятна для этой цели. Вы также можете получить немного более быстрое время ответа на запрос, используя Structure #1.

Нет ничего плохого в Structure #2. Если либо сейчас, либо в будущем пользователи могут просматривать повестки дня других пользователей, то Structure #2 - ваш лучший выбор. Structure #2 также будет лучше, если вы планируете искать программы по нескольким пользователям по одному из его полей. Например, если вы когда-либо хотели просмотреть 20 самых последних документов повестки дня для всего приложения по их полю timestamp.

У моего проекта очень похожая ситуация в другом контексте. Наше приложение имеет Posts и Content. Каждый Post содержит один или несколько Content. Мы могли бы сделать Content вложенной коллекцией для каждого Post (как ваш Structure #1), но вместо этого мы сделали Content коллекцию корневого уровня (как ваш Structure #2), потому что нам нужно было запрашивать Content документы между пользователями на основе одного из их полей.

В заключение, Structure #2 является более гибким, но если вы уверены, что не хотите запрашивать повестки дня у нескольких пользователей ( запрос группы сбора ), тогда Structure #1 может быть более выгодным .

Обычно я по умолчанию использую Structure #2, за исключением тех редких, но законных обстоятельств, когда действительно имеет смысл выделять данные для конкретных документов.