Я сохраняю структуру папок в основных данных. Он отражает локальную структуру файлов / папок и требует обновления БД всякий раз, когда пользователь выполняет какую-либо операцию в поисковике (например, переименование / удаление / создание).

Я определил узел единственной сущности (имя, полный путь, тип (каталог / файл)).
отношение ко многим children от сущности узла к самому себе, при этом для правила удаления установлено каскадное
отношение к одному parent от сущности узла к самому себе, с установленным правилом удаления обнулить.
и установите их как обратные отношения друг к другу.

У меня проблема, когда пользователь переименовывает папку. В настоящее время я обновляю узел и добавляю метод для построения полного пути через родительский путь и имя ребенка.

Но иногда мне нужно получить узел по пути, а файловые узлы не обновляются после переименования. Я не хочу перебирать все файлы внутри папки после переименования. Некоторая папка содержит 100к узлов.

Может ли кто-нибудь помочь мне или предложить мне лучший дизайн?

0
Parag Bafna 17 Фев 2018 в 07:51

1 ответ

Лучший ответ

Вы создали эту проблему и теперь видите ее последствия.

  • Вы сохраняете полный путь на каждом узле
  • У вас есть узлы со 100 тыс. Или более подузлов
  • Вы хотите иметь возможность переименовывать произвольные части пути

Независимо от того, как вы храните данные, вы создали ситуацию, когда может потребоваться обновить строковые значения сразу на 100 тыс. Или более узлов. Это большая работа, и ее нелегко оптимизировать, потому что рано или поздно вам придется вычислять и обновлять все эти строки.

Итак, настоящий вопрос заключается в том, почему вы храните полный путь на каждом узле и сможете ли вы перестать это делать?

Я не уверен, зачем вы это делаете. Для каждого узла вы можете определить путь, рекурсивно следуя родительским отношениям, пока не достигнете корневого узла. Аналогичным образом, если у вас есть полный путь и вам нужно найти узел, вы можете разделить путь на компоненты, используя разделитель пути (возможно, "/"), а затем спуститься от корневого узла через дочерние отношения к получить целевой узел.

Приятно то, что если вы переименуете узел где-нибудь в середине дерева, готово! Нет необходимости обновлять какие-либо другие узлы.

Возможно, было бы лучше представить данные в виде дерева вместо того, чтобы просто называть каждый узел и связывать его дочерние узлы, но это требует творческого подхода в Core Data. Некоторое время назад я описал один из возможных подходов, но я не обязательно утверждаю, что это лучший. Я бы не стал пробовать это, если вы не сочтете описанный выше подход медленным на практике.

1
Tom Harrington 20 Фев 2018 в 00:17