Сколько ошибок в названии треда

Мсье из Англии и пишет текст через онлайн переводчик?

А по теме?

ЗЫ: Как вообще на этом форуме писать новое сообщение а не ответить????

[Ответить на это сообщение] на тело треда.

Та неее, так не покатит( возможно..

Дело в том что у меня ключи будут добавляться пользователем. К примеру по кнопке «добавить», будет предложенно: Введите парамаетр: ввожу: объем В итоге создается новый к ключ «объем». Далее пользователь заходит выбирает, к примеру в выподающем списке, уже добавленный ключ и присваивает ему значение - к примеру: 10 м^3 Не будет же пользователь писать транскрипт для каждого ключа. Вот и отсюдого вопрос:

• Так как же себя будет вести МонгоДБ при поиске по ключу на языке отлючно от Англицкого (в частности на Русском)?
• Какие при этом могут возникнуть проблемы?
• Как повлияет на производительность данный подход?

Какие при этом могут возникнуть проблемы?

Например, тебе может понадобится хранить «1000» и «тонн» в разных полях.

Та неее, так не покатит

Почему?

Будет работать аналогично английскому поиску. Вроде бы даже есть поддержка морфологии для русского.

Вертухай упоролся или шутит?

The word «Russian» in Russian is «русский язык». Use of the word «язык» and writing with a lowercase letter are obligatory.

All text above was translated by Google Translate, sorry.

Поциент спрашивает, есть ли поиск по названию ключа.

According to the latest rules of grammar of the Russian language, the word «Orthodox» is synonymous with the word «Russian» and it must be written with a capital letter, otherwise you all will be punished by God.

Please excuse me if something is wrong, if you suddenly felt that I say something wrong or that you do not want to hear. With great respect and scrotum in a leather pouch.

Почему?

Еще раз:

Дело в том что у меня ключи будут добавляться пользователем. К примеру по кнопке «добавить», будет предложенно: Введите парамаетр: ввожу: объем В итоге создается новый к ключ «объем». Далее пользователь заходит выбирает, к примеру в выподающем списке, уже добавленный ключ и присваивает ему значение - к примеру: 10 м^3 Не будет же пользователь писать транскрипт для каждого ключа.

Если тебе нужен не поиск, а получение записи по ключу (т.е. по точному значению), то должно быть одинаково (± время на быстрое хэширование ключа и на сравнение строк в пределах списка по хэшу, но это время ничтожно). Почему?

Если бы я проектировал простую БД, я бы складывал записи так, чтобы их можно было найти по хэшу индекса. Т.е. по хэшу хранится список собственно записей (не 1 запись т.к. может быть коллизия, мы не хотим выкидывать запись, у ключа которой тот же хэш). При поиске считаем хэш от запроса, околобинарным поиском ищем в индексе (который дерево, сложность в районе O(log(n)) независимо от юникодов: у нас хэши), ищем нужную запись среди списка коллизий (который обычно длиной в 1 элемент, но вообще O(n)), выдаём нужную запись. Нет оснований полагать, что девелоперы mongodb (несмотря на их критику) изобрели нечто хуже, поскольку это — азбука.

Если очень хочется — складируй записи не по «Снаряженная масса»:{ <whatever>}, а по быстрый_хэш(«Снаряженная масса»):{«Снаряженная масса», <whatever>}. Получишь гарантированно одинаковую работу с UTF-8 и ASCII независимо от того, что в mongodb. Но вряд ли это что-то изменит.

Конечно, если тебе нужен, например, регистронезависимый поиск, поиск по части слова (зачем?), юникодный collation и каноничный equiualence разных уровней, то могут быть серьёзные отличия в производительности, но нафиг оно тебе?

И, в конце концов, давно бы взял и измерил.

Спасибо!

Приятно слышать профессиональный ответ.