Деревья

← →
RDA © (2002-07-18 11:15) [0]

База данных структуры организации в которой есть и подразделения и сотрудники. Вопрос следующий как при построении дерева присвоить разные иконки сотрудникам и отделам. Используется специальное поле для определения сотрудник это или отдел.

← →
Sergey13 © (2002-07-18 11:29) [1]

Дык в зависимости от этого поля, наверное и надо рисовать. Тут важно каким компонентом ты это делаешь.
Кстати - интересная организация даных- и подразделения и сотрудники в одной таблице. 8-) ИМХО это все таки разные вещи и налицо ошибка при проектировании базы.

← →
Johnmen © (2002-07-18 12:01) [2]

>Sergey13 © (18.07.02 11:29)

Вот именно !
+
И к тому же пора вспомнить про нормализацию и забыть дибейсные подходы...:)

← →
RDA © (2002-07-18 15:21) [3]

Хорошо есть ошибка в проектировании. Но возможно ли вывести в дереве структуру организации из двух таблиц в одной из которых подразделения оной а в другой сотрудники.

← →
Awex © (2002-07-18 16:09) [4]

Можно попробовать сделать нечто подобное:

CREATE TABLE SUBDIVISION ( /* ПОДРАЗДЕЛЕНИЯ */
SUBDIVISION_ID INTEGER NOT NULL, /* УНИКАЛЬНЫЙ НОМЕР */
SUBDIVISION_CAPTION VARCHAR(63) NOT NULL); /* НАЗВАНИЕ */

ALTER TABLE SUBDIVISION ADD CONSTRAINT PK_SUBDIVISION PRIMARY KEY (SUBDIVISION_ID);

CREATE TABLE EMPLOYEE ( /* СОТРУДНИКИ */
EMPLOYEE_ID INTEGER NOT NULL, /* УНИКАЛЬНЫЙ НОМЕР */
EMPLOYEE_NAME VARCHAR(63) NOT NULL, /* ФИО */
REF_SUBDIVISION INTEGER NOT NULL); /* К КАКОМУ ПОДРАЗДЕЛЕНИЮ ПРИНАДЛЕЖИТ */

ALTER TABLE EMPLOYEE ADD CONSTRAINT PK_EMPLOYEE PRIMARY KEY (EMPLOYEE_ID);
ALTER TABLE EMPLOYEE ADD CONSTRAINT FK_EMPLOYEE FOREIGN KEY (REF_SUBDIVISION) REFERENCES SUBDIVISION (SUBDIVISION_ID) ON UPDATE CASCADE;

/* структура организации */
CREATE VIEW VW_LIST(
ID,/* УНИКАЛЬНЫЙ НОМЕР ПОДРАЗДЕЛЕНИЯ ИЛИ СОТРУДНИКа */
CAPTION,
RTYPE, /* ТИП ЗАПИСИ 0-ПОДРАЗДЕЛЕНИЕ, 1-СОТРУДНИК */
PARENT /* К КАКОМУ ПОДРАЗДЕЛЕНИЮ ПРИНАДЛЕЖИТ СОТРУДНИК (ЕСЛИ ЭТО СОТРУДНИК ИНАЧЕ -1)*/ )
AS
SELECT SUBDIVISION_ID, SUBDIVISION_CAPTION, CAST(1 AS INTEGER) , CAST(-1 AS INTEGER)
FROM SUBDIVISION
UNION
SELECT EMPLOYEE_ID, EMPLOYEE_NAME, CAST(2 AS INTEGER), REF_SUBDIVISION
FROM EMPLOYEE;

← →
Boroda Oleg © (2002-07-18 16:36) [5]

Запросто.

Вот две таблицы:

CREATE TABLE TFIRMA (
ID INTEGER NOT NULL,
NAME CHAR(10));

CREATE TABLE TEMPLOY (
ID INTEGER NOT NULL,
OWNER INTEGER,
FNAME CHAR(10));
Owner во второй таблице - ссылка на ID первой таблицы.

а вот SQL:

Select tf.Name, te.Fname
FROM TFIRMA tf, TEMPLOY te
Where (tf.id = te.owner)
Order by tf.Name, te.Fname

При вставке в TreeView внутри цикла организовываеш проверку на появление нового имени, и в подцикле вставляешь всех сотрудников в узел.
А вот насчет неграмотного построения TreeView в одной таблице - готов поспорить. У меня например почти все деревья строятся по этому принципу:

CREATE TABLE GOODTREE (
ID_GOODTREE IDTYPE,
CHECKED CHECKEDTYPE,
ID_OWNER INDEXTYPE,
ID_TYPE INDEXTYPE,
NAME CHAR100TYPE,
PICTURE INDEXTYPE,
ID_SOURCE INDEXTYPE);

где: ID_GOODTREE - уникальный ID
ID_OWNER - владелец
ID_TYPE - тип (папка, файл, еще что-то...)
ID_SOURCE - источник данных. Здесь просто его ID, таблица определяется из ID_TYPE.

Вот такую структуру, на мой взгляд, можно приложить к любому дереву, буз зависимости и от числа ветвей, и от уровня вложенности. Работать с ней, кстати тоже не сложно. Например, перетаскивание ветви котируется просто изменением ID_Owner у перетаскиваемого элемента.

← →
RDA © (2002-07-21 10:43) [6]

К Awex и Boroda Oleg и остальным.
Спасибо за помощь. Но вот возник вопрос. В Ваших обоих примерах таблица подразделений не может иметь субподразделений, т.к. отсутствует поле владельца. Если есть такая необходимость, то в таблице сотрудников поле устанавливающее связь должно ссылаться на какое поле таблицы подразделений.
И еще, это что получается если не переписывать в одних компонентах доступа к данным запросы, а сделать их статическими то теперь необходимо использовать три набора компонент:
1 - Для считывания из двух таблиц в дерево.
2 - Для работы с таблицей подразделений.
3 - Для работы с сотрудниками.
Или я преувеличиваю.
Заранее благодарен за пояснения.

← →
RDA © (2002-07-21 10:50) [7]

Да, хотелось бы добавить. Наверняка кто-то уже разрабатывал подобную базу данных для организации. В данный момент я использую таблицу с такой структурой
ID Уникальный номер
PARENT Владелец
KIND Тип (подразделение, сотрудник)
NAZV Название
Хотелось бы услишать (прочитать) советы более опытных людей. Так как эта таблица ложиться в основу всей программы, то что за проблеммы меня ожидают дальше.

← →
RDA © (2002-07-22 09:53) [8]

В воскресенье ответа не получил. Может кто-нибудь сегодня поможет ответом.

2RDA © (21.07.02 10:50)
И это вся информация по подразделениям и сотрудникам?!!!
Что за программа то вообще - из-за чего весь сыр-бор?

Нет это не вся программа.
Пока планируется - Кадры, и для бухгалтерии - расчет заработной платы.
1С прошу не предлагать. Организация бюджетная.

2RDA © (22.07.02 10:30)
Ну тогда тебе не над "рисованием разных иконок" надо думать, а над нормальным проектированием базы данных. По этому вопросу горы книг и статей (и на бумаге и в инете). Та схема, которую ты описал - никуда не годится, ИМХО, уж извини.

2RDA
Я так понял, ты пытаешся использовать компоненты типа TTable - мой тебе совет откажись в самом зародыше - потом гемороя с ними не оберешся, не говоря уже о тормозах в работе с сервером....
Оптимальный вариант - использование TQuery и решение всех задач с использованием SQL-запросов - и быстро, и возможностей на порядок побольше.

Наибольшая проблемма, с которой я сталкивался в однотабличной структуре дерева - определение имени предприятия, если мы имеем только ID сотрудника - приходится использовать вложенные запросы, кое где даже процедуры писать, но на SQL - все это решимо.

Что посоветовал бы ввести еще - ссылку на данные. Для предприятия и сотрудника - это принципиально разные вещи, и хранить их в одной таблице, в принципе, неграмотно. Т.е. мы все равно возвращаемся к 3-м таблицам: 1-я для TreeView, 2-я данные для предприятий, 3-я данные для сотрудников.

Деревья Найти похожие ветки