Ждать полгода, чтобы получить кота в мешке?
Не думаю, что это хорошая идея, ведь новые продукты почти всегда сырые.
А Вам сейчас нужно читать доки, и есть приличные планшеты для этой задачи.
Потом через полгода продадите планшет и купите амазон колор, если действительно приличная вещь.
Шариковые мыши требовательны к качеству поверхности. В частности, нужно, чтобы шарик не проскальзывал, что стеклянному столу не очень свойственно. Кроме того, шарик хорошо собирает грязь. Не зря очень ходовым товаром во времена шариковых мышей были коврики.
Вообще-то минусы незаслужены, замечание дельное, но рецепт совсем не универсальный.
Зависит от нескольких основных условий, навскидку все не назову, например, от разнообразия структуры, от ее изменчивости, от большого количества текстовых полей.
Так что совсем отказываться от SQL не стоит. У него по-прежнему большая область применения в каталогах товаров.
Было бы здорово, если автор ответа написал статью с примером применения noSQL в каталоге товаров.
По моему опыту классификацию больше двух уровней делать бесполезно.
Больше семи пунктов на каждом уровне ставить тоже нельзя (а лучше — пяти).
Причина — люди классифицируют различными способами. Даже один человек в разное время помещает одинаковую информацию в разные рубрики.
Соответственно и эффективность поиска по рубрикатору резко падает с увеличением возможности выбора.
Учиться, несомненно, нужно. Без математической подготовки программисту вырасти очень тяжело. Да и совмещать работу и учебу на первом курсе почти невозможно.
Так что вариант «сразу работать» идет только при серьезной нехватке денег и означает просто потерю времени.
Похоже, это приложение не составляет индекс шинглов. По этой причине придется сравнивать каждый текст со всеми. Следовательно, скорость работы пропорциональна объему базы. Устроит Вас такая скорость?
У Яндекса, естественно, сложнее.
Для больших баз нужно, как минимум, убрать наиболее энтропийные слова, а также повысить вес уникальных n-грамм. Плюс учитывать и отдельные редкие слова (например, ошибки).
Давайте прикинем.
Для упомянутой мной базы и реферата нужно 10^9 поисков каждый примерно в 80*40=3200 операций (50% отличие).
Итого 3*10^12 операций, т.е. где-то 6000 сек.
Вроде, приемлемо, но не ерунда.
И зависит от объема базы.
В моем примере это 70Мб, а для 700Мб получится уже 17 часов.
Может не пройти по быстродействию.
Тысяча рефератов по тысяче предложений, вот и миллион слов, с которыми надо сравнить. Слова очень длинные, да и допустимое расстояние по Левенштейну для копипаста в примере большое.
Следуя по Вашему пути, на новую платформу никогда не перейти.
Только на серьезном проекте и можно это сделать, возможности Питона это окупят.
Да, придется потратить больше своего времени, но заказчик об этом и узнать не должен, ему абсолютно все равно, на чем будет сделан проект, у него другие проблемы.
Вот обеспечить такую прозрачность железобетонная обязанность разработчика.
Да, Лем многогранен, и некоторые произведения трудны для быстрого восприятия.
Правда, «петросянистости», т.е. юмора для тупых, что-то я не припомню при всем желании.
Можете привести пример?