Цитата:
|
Сообщение от morebeauty
Да да, именно так я и делал раньше для задания иерархии. И в данной модели можно сделать так же. Но вот именно для этой модели лучше использовать предложенную мной структуру ИМХО.
Стыдно, но я не могу вспомнить, почему я пришел к такому выводу. Но пришел я к нему уже в процессе написания класса. Может и ошибся.
|
Мне то всё равно как у тебя всё будет организовано, я просто написал как это правильно/общепринято делается.
Несколько замечаний:
1) Если в твоей структуре удалить например "7 / File3", то потом ещё нужно найти папку в которой этот элемент находился (в данном случае это "4 / Catalog3") и у него редактировать текстовое поле (т.е. прочитать это значение, найти и удалить в нём подстроку "(7)" и потом записать назад этот обновлённый текст), а в правильном варианте ничего этого не нужно делать: удалили элемент "4 / Catalog3" - он автоматически пропадёт из папки "4 / Catalog3".
2) Если например удалить элемент "3 / Catalog2", то либо останутся файлы которые будут теперь нахидиться "нигде". Либо же нужно писать дополнительный код, который будет искать и удалять всё содержимое удалённой папки. В правильном же варианте, можно настроить связи (Relationship) между таблицами либо чтобы все подчинённые элементы автоматически удалялись вместе со своим владельцем, либо запрет удаления владельца который владеет хоть одним подчинённым элементом (т.е. на который ссылается хоть один элемент). Таким образом сохраняется целостность базы данных.