Най-добри практики за първичен ключ в DocumentDB

Разработвам уеб сайт с azure DocumentDB. Трябва да създам уникален и кратък първичен ключ.

Тъй като няма налично автоматично увеличение в documentDB, има ли някакъв добър начин за справяне с този проблем.

Очаквам отговор със съвети за най-добри практики. Благодаря ти


person Dehan Wjiesekara    schedule 29.07.2015    source източник


Отговори (3)


Имам клас документи, чийто първичен ключ е наречен PrimaryKey

public class Document<T> : BaseDocument, IDocument<T>
    {
        [JsonProperty(PropertyName = "id")]
        public virtual T PrimaryKey { get; set; }
    }

Тъй като първичният ключ на базата данни на документа е id (малки букви са задължителни), можете да замените идентификатора с JSONProperty на Newtonsoft.Json, който автоматично ще бъде сериализиран със стойността на PrimaryKey на името на ид.

person Karthikeyan VK    schedule 08.12.2016
comment
Бих добавил, че PrimaryKey трябва да е от тип string. В противен случай получавате Уверете се, че предоставяте уникален непразен низ, по-малък от '255' знака, изключение при създаване на документ. - person UserControl; 24.02.2017
comment
Използвам guid като първичен ключ и той работи безпроблемно в MS-Doc db в azure, а също и в локален. - person Karthikeyan VK; 27.02.2017

Най-често срещаната практика, която съм виждал, е просто да използвате GUID, зададен, когато създавате новия документ, който да бъде добавен/вмъкнат. Можете също да посочите Правила за индексиране. Това може да помогне при ситуации, при които трябва да намерите документ въз основа на други свойства в тези документи.

Създаването на персонализиран, съставен ключ също е полезно, ако обикновено знаете точно кой документ искате да извлечете. В този случай зависи от отделното приложение да определи най-добрия начин за създаване на комбинираната стойност.

person BrentDaCodeMonkey    schedule 29.07.2015

Ако имате нужда от инкрементални, цифрови и уникални ключове, можете да използвате датата на Javascript new Date().getTime() в милисекунди като уникален идентификатор за всеки документ. Предимството на това е, че ако трябва да търсите документи по диапазон, можете да конфигурирате това свойство като индекс на диапазон и да извършвате ефективно търсене в диапазони. В зависимост от вашето приложение шансовете 2 документа да бъдат създадени в една и съща милисекунда са доста малки.

person Luis Delgado    schedule 29.07.2015
comment
Като предупреждение към всеки, който чете тези коментари за съвет, бих посъветвал сериозно да не проектирате условия на състезание като горните във вашето приложение, уникалният идентификатор трябва да бъде абсолютно уникален, какво се случва в горното, когато този малък шанс бъде достигнат... вашият референтната цялост е изчезнала и вероятно ще загубите данни.. (т.е. няма да бъдат запазени).... - person dreadeddev; 24.03.2016
comment
@dreaddeddev: в контекста на documentDb наблюдението ви не е съвсем точно. DocumentDB автоматично ще присвои уникален идентификатор на всеки документ в колекция. Този идентификатор е гарантирано уникален. Така че, в случай на такова състезателно състояние, документите пак ще бъдат запазени в БД. Но ако вашето приложение е толкова масивно, че записването на нови документи в колекция наистина може да се случи в рамките на една и съща милисекунда и това свойство трябва да бъде постепенно уникално, тогава да, ще трябва да измислите различен алгоритъм, за да разрешите този проблем. - person Luis Delgado; 25.03.2016
comment
Наистина питащият го прави.... въпросът му беше относно създаването на самия идентификатор.... не автоматично зададения! - person dreadeddev; 29.03.2016