Скажу больше - у меня есть личное убеждение что mongo изрядно перепиарен. Мы пару лет назад делали собственные тесты, всего лишь 2kk небольших записей раздули базу до 17gb и устроили деградацию времени записи до нескольких секунд. Я допускаю что мы "просто не умеем её готовить" - но после таких результатов желание экспериментировать дальше отпало.
@lookingfor По поводу второго варианта - да, если у прототипа меняется регулярность - то надо пересоздать все задачи.
Мне лично очень нравится функционал icloud - там есть удобная штука, что при изменении задачи он спрашивает - внести изменения во все задачи, только в будущие, или только в текущую. Мне кажется это реально удобно для планирования. Но реализовать это можно только таким способом
Объемы данных будут кстати не очень большие, можно во всех значимых полях кроме даты хранить null если они не отличаются от прототипа. Можно дополнительно схитрить, и задачи на сильно будущее время заранее не создавать, а задачи из сильно прошлого - убирать в какой то отдельный архив
@victorvsk Вы упускаете порядок сортировки. SQL сервер осуществляет сортировку по аргументам в том порядке, в котором они написаны. Поэтому has_price должен быть первым.
@victorvsk Тогда там же где вы храните цены - добавляем поле has_price и далее как я написал в варианте 3: перед всеми вашими сортировками вставляем сортировку по has_price.
Не создавайте вопросы ответами, лучше создавать новый вопрос или изменять существующий.
В Windows нет корня ФС.
Что бы получить существующие диски надо либо извращаться с win32api, либо (что на мой взгляд проще хоть и кривовато) просто в цикле перебрать все буквы алфавита начиная с C:\