пользователь (группа) - элемент (папка), многокорневая база данных с древовидной структурой - PullRequest
0 голосов
/ 17 августа 2011

Да, карамба!- enter image description here это сжимает мой маленький мозг, не связанный с информатикой - помогите, пожалуйста

У меня потенциально есть две таблицы БД. Первая - таблица пользователей (папок), которая представляет собой древовидную структуру (родительский дочерний элемент) (пользователи организованы вклиенты или отделы) Его полностью редактируемую, поэтому новую структуру (parentid слева направо и т. д.) нужно переписывать довольно часто

Затем у меня есть древовидная структура таблицы элементов (папок)., копировать, вставлять, перемещать ... как в http://www.jstree.com/demo - (редактируемая функциональность PHP MYSQL)

NB Я ожидаю, что глубина дерева редко будет больше 5, поэтому глубина сначалана самом деле не обязательно ... хотя я рассматриваю это (безопаснее) - тем не менее, будет много вещей и, возможно, пользователей.

Просто поискать какое-то направление после долгих поисков в Google... Задача 1 - Один стол или два?- Одна таблица была бы хороша ... только весь DBtable должен был бы быть переписан при сохранении, если я перемещаю папки.Учитывая, что эта структура должна контролировать всех пользователей и элементы ... ее ОБНОВЛЕНИЕ SQL

Проблема 2 - Несколько корневых древовидных структур ... Если бы я просто хотел получить доступ к структуре, скажем ... пользователь 5(root) поиграйте и сохраните часть дерева, которое я открываю, чтобы левый / правый / id были повреждены.

В основном требования должны состоять в том, чтобы пользователи входили в систему - тогда они могут управлять своей пользовательской структурой, котораямогут быть организованы в папки (клиенты).Затем разрешите зарегистрированным пользователям добавлять папки элементов (организующие элементы) другим пользователям и иметь возможность копировать (добавлять, переименовывать, перемещать, удалять) папки элементов между пользователями ... так, чтобы эти пользователи (при входе в систему)) могут просматривать только эти элементы.

Пхев.надеюсь, я объяснил это хорошо

1 Ответ

1 голос
/ 18 августа 2011

Я поговорил с одним из наших лучших администраторов баз данных за некоторую помощь по этому вопросу.

Принципиальная проблема с этими типами дизайна не в количестве таблиц, а в типе использования.

Если это однопользовательская система, использование одной таблицы не является проблемой, этоЭто немного грязно для управления, но здесь может помочь команда слияния.

Если к данным одновременно обращается несколько пользователей, такая структура может вызвать проблемы с блокировкой.

"Я бы выбрал две таблицы: первая содержит данные, а вторая - только информацию об отношениях родитель / потомок. Если у вас есть несколько взаимосвязей между элементами, т. Е. Родитель, имеющий много дочерних элементов, будет иметь несколько строк втаблица отношений (Oracle применил этот подход для своих отношений с внешним ключом (Parent-Child)) "

Надеюсь, это поможет

...