Официальный драйвер MongoDB C #: сопоставление объектов с короткими именами для ограничения пространства

Я ищу способ сопоставить объекты Bson, определенные с использованием читаемых имен ("категория"), с сокращенными именами ("ct") и ограничить пространство, занимаемое именами элементов в основной базе документа. Я видел это с помощью других драйверов, но как насчет использования официального драйвера. Как я могу делать, где лучше всего определять. Можно ли использовать длинные имена в запросах и получать короткое содержимое?

Благодарю.


person user325558    schedule 21.02.2011    source источник
comment
Хех, тебе лучше надеяться, что тебе никогда не придется просматривать базу данных. Хм. был ct Category или это был CustomerTab. Подождите, а что это за поле a? Я считаю, что в 90% случаев это преждевременная оптимизация   -  person Earlz    schedule 22.02.2011
comment
Я думаю, что если у вас есть записи имен, которые вы создали для полей в вашей базе данных, хранящиеся в безопасном месте, все в порядке.   -  person Arvindh Mani    schedule 18.07.2017


Ответы (3)


Поскольку на самом деле никто не дал ответа на этот вопрос, вот он.

С официальным драйвером вы можете сделать это, украсив имя свойства с помощью BsonElement. Например:

public class SomeClass
{
    public BsonObjectId Id { get; set; }

    [BsonElement("dt")]
    public DateTime SomeReallyLongDateTimePropertyName { get; set; }
}

Теперь драйвер будет использовать «dt» в качестве имени свойства BSON.

Однако в настоящее время нет возможности запросить имя свойства POCO. Вам нужно будет использовать "dt" в ваших запросах. Существует отдельный проект, созданный поверх драйвера C #, который предоставляет возможности запросов в стиле LINQ, но я не тестировал его, чтобы убедиться, что он будет делать то, что вы просите.

person Bryan Migliorisi    schedule 22.02.2011
comment
Это все хорошо, но все запросы будут работать с короткими именами. Таким образом, через час вы забудете, что означает следующий запрос: Query.And (Query.EQ (fn, filter.Field1), Query.NE (ms, filter)) или что-то подобное. - person Andrew Orsich; 22.02.2011
comment
Согласен ... но если ваша коллекция будет содержать миллионы или даже миллиарды записей (например, для платформы аналитики), вам стоит оставить где-нибудь заметки о названиях ваших свойств. - person Bryan Migliorisi; 23.02.2011

Лучше содержать модели в чистоте. А MongoDB.Driver позволяет делать это снаружи.

BsonClassMap.RegisterClassMap<SomeClass>(x =>
{
     x.AutoMap();
     x.GetMemberMap(m => m.SomeReallyLongDateTimePropertyName).SetElementName("dt");
});
person rnofenko    schedule 13.10.2015
comment
@ilans Этот код следует вызывать только один раз, возможно, в экземпляре конфигурации singleton. «x.AutoMap ()» выполняет первоначальную проверку всех свойств SomeClass: определяет тип данных, имя поля и т. д. и сохраняет только настройки. Затем вы можете отменить настройки из предыдущего шага. В этом примере «SetElementName» просит драйвер mongo использовать имя поля «dt» вместо имени по умолчанию (SomeReallyLongDateTimePropertyName). - person rnofenko; 15.10.2019

Считайте запись

{last_name: "Smith", лучший_счет: 3.9}

Строки last_name и best_score будут храниться в BSON каждого объекта. Использование более коротких строк позволит сэкономить место:

{lname: "Smith", оценка: 3,9}

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

Имена полей не хранятся в индексах, поскольку индексы имеют предопределенную структуру. Таким образом, сокращение имен полей не поможет размеру индексов. Как правило, нет необходимости использовать короткие имена полей.

проверьте источник для получения дополнительных сведений.

но другая сторона описана в известной теме "Вы сэкономили 5 центов, и ваш код не читается, поздравляю!"

И мое собственное мнение, что короткое имя - плохой вариант.

person Andrei Andrushkevich    schedule 21.02.2011
comment
Имейте в виду, но я использую коллекцию, в которой имена элементов и подпункты всегда повторяются с одной и той же информацией, именами элементов или именами ключей. Более 70% представляют собой подробную информацию вместо ценностных данных. Я думаю, что у картографии есть настоящий смысл. Просмотрите свое хранилище данных и пропускную способность, которые не являются бесплатными. - person user325558; 21.02.2011
comment
Хотя я согласен с тем, что вы не хотите жертвовать удобочитаемостью кода, ничего не стоит, если в некоторых случаях эти 9 байтов быстро складываются. Это плохой ответ, потому что, хотя он действителен для коллекции из 10 объектов, он будет вреден при работе с коллекцией из 10 миллионов. Место на диске дешевое, но не бесплатное. - person Bryan Migliorisi; 22.02.2011
comment
Использование диска - даже не самая большая проблема. Более крупные имена снизят кэшируемость объектов как в кеш-памяти RAM-диска, так и в кеш-памяти ЦП. Это значительно снижает производительность, особенно на магнитных дисках, даже для небольших наборов данных. - person Emil Vikström; 26.06.2014