Как говорит Доминик Барнс, целые числа с автоинкрементом не масштабируемы, не распределены и не облачны.Кажется, что каждое приложение в настоящее время нуждается в мобильной версии с поддержкой в автономном режиме, которая не совместима напрямую с целыми числами с автоинкрементом.Мы все это знаем, но это так: целые числа с автоинкрементом необходимы для унаследованного кода и, возможно, других вещей.
В обоих сценариях вы несете ответственность за создание целого числа с автоинкрементом.Представление работает emit(the_numeric_id, null)
.(У вас также может быть пространство имен типа, например emit([doc.type, the_numeric_id], null)
. Запрос последней строки (например, с startkey=MAXINT&descending=true&limit=1
, увеличьте возвращаемое значение, и это ваш следующий идентификатор. Попытка сохранения находится в циклекоторый может повторить попытку в случае столкновения.
Вы также можете играть трюки, если вам не нужна 100% -ная плотность списка идентификаторов. Например, вы можете добавить временные метки к строкам emit()
иоцените скорость создания документа и увеличьте ее на величину, умноженную на ваши вычисления и время передачи. Вы также можете просто увеличить случайное целое число от 1 до N, поэтому большую часть времени первая вставка работает за счет неоднородного идентификаторачисла.
О том, где хранить целое число, я думаю, что есть стратегия id и стратегия try and check .
The * 1017Стратегия * id проще и быстрее за короткий промежуток времени . Идентификаторы документов являются целыми числами (возможно, с префиксом типа для добавления пространства имен). Так как Couch гарантирует уникальность _id
поле, вы просто беспокоитесь об автоинкременте.Сделайте это в цикле: 409 Conflict
запускает повтор, 201 Accepted
означает, что вы закончили.
Я думаю, что основная боль в этом трюке заключается в том, что , если и когда вы получитеконфликты, у вас есть два совершенно не связанных документа, и один из них должен быть скопирован в новый документ.Если были отношения с другими документами, все они должны быть исправлены.(Вспоминается трюк CouchDB 0.11 emit(key, {_id: some_foreign_doc_id})
.)
Стратегия try and check использует UUID по умолчанию в качестве doc._id
, поэтому каждая вставка будет успешной.В идеале все или большинство ваших междокументарных отношений основаны на неизменяемом UUID _id
, а не на целом числе.Это просто используется для пользователей и пользовательского интерфейса.Автоинкрементное целое число - это просто поле в документе {"int_id":20}
.Мнение конечно делает emit(doc.int_id, null)
.(Вы можете искать документ по целочисленному идентификатору с параметром ?key=23?include_docs=true
представления.
Конечно, после репликации могут возникнуть конфликты идентификаторов (не официальные конфликты CouchDB, а только документы, использующие тот жечисловой идентификатор). Представление, которое генерирует по идентификатору, также будет иметь фазу сокращения: достаточно просто _count
. Затем вы должны патрулировать БД, запрашивая это представление с помощью ?group=true
и ища любую строку (соответствующую целочисленному идентификатору).) с числом> 1. С другой стороны, исправление числового идентификатора документа является незначительным изменением, поскольку не требует создания нового документа.
Это мои идеи. Теперь, когда я их записалЯ чувствую, что вы должны выполнять пасти отношений независимо от того, где хранится идентификатор, поэтому, возможно, лучше использовать _id
. Единственный другой недостаток, который я вижу, это то, что вы навсегда состоите в браке с принципиально нарушенной моделью именования - для некоторыхопределение понятия «навсегда»