Покритикуйте пожалуйста структуру БД.
Схема во вложенном файле =)

Kirill Razuvaev
>> Покритикуйте пожалуйста структуру БД.

Было бы неплохо формализуемую предментную область описать...



Это краткое описание ? =)

Система планирования и учёта. направленная на строительство. Что то вроде MS Project только очень маленькая )))

TBL_BRIGADE - Таблица бригад рабочих
TBL_BRIGADE_WORKERS_TREE - Дерево привязки рабочих к бригадам
TBL_COUSTS - таблица затрат
TBL_GRAPH - Основная таблица. Хранятся задачи и их сроки.
TBL_GRAPH_BRIGADE_TREE - Таблица привязки бригад к задачам
TBL_GRAPH_MASH_TREE - Таблица привязки техники к задачам
TBL_GRAPH_RESOURCES_TREE - Таблица привязки материалов к задачам
TBL_GROUP_COUSTS - Таблица групп затрат
TBL_OBJECT_LIST - Список строительных объектов
TBL_RESOURCES_EI - Единицы измерения (м,м2,м3,кг,тн...)
TBL_RESOURCES_TYPE - Типы материалов
TBL_WORKERS - Таблица рабочий
TBL_USERS - Таблица пользователей системы
TBL_USERS_DEPARTMENTS - Список отделов для пользователей
TBL_USERS_POSTS - Должности пользователей
TBL_USERS_ROLE - Пользовательские роли
TBL_USERS_ROLE_ATRIB - Атрибуты для роли
TBL_WORKERS_POSTS - Должности рабочих

Неужели нет никаких косяков ? =)
Тогда спрошу )))
Как организовать хранение и вывод суммарных задач ? как в MS Project ?

Kirill Razuvaev
>> Неужели нет никаких косяков ? =)
Вообще-то, я имел ввиду словесное описание задачи. Тем более, что не все
видели MS Project.

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

авторСмысл отдельного ПК ID_TREE в TBL_BRIGADE_WORKERS_TREE?
Я просто не успел удалить табличку ID_TREE =)

автор3. Получается двоякая связь бригады с объектом TBL_BRIGADE -
TBL_OBJECTS_LIST и
TBL_BRIGADE - TBL_GRAPH_BRIGADE_TREE - TBL_GRAPH - TBL_OBJECTS_LIST.
Рискуете получить неоднозначность.
Я не могу удалить связь TBL_BRIGADE - TBL_GRAPH_BRIGADE_TREE - TBL_GRAPH - TBL_OBJECTS_LIST
Но и TBL_BRIGADE - TBL_OBJECTS_LIST тоже вроде не удалить.
Т.К. первый пользователь при создании бригады будет привязывать её к объекту потом следующий пользователь получит список выделенных ему бругад и только после этого будет раскидывать их по работам!
Даже не знаю что и делать =(
автор4. TBL_GRAPH_MASH-TREE - "Таблица привязки техники к задачам" - по
определению не может иметь только один внешний ключ.
Да действительно что то я поспешил =)
Надо полностью переделывать эту связь и добавлять таблички.
Что бы ещё учесть что бы не получилось так что один кран одновременно работал на двух объектах )))
автор5. Не ясен смысл связи TBL_GRAPH - "Основная таблица. Хранятся задачи и их
сроки." и TBL_RESOURCES_EI - "Единицы измерения".
Ну надеюсь после скриншота станет понятно =)
автор6. Обычно не делают без особой нужды отдельные таблицы для аналогичных
сущностей - "Должности рабочих" и "Должности пользователей", удобнее один
справочник, в котором можно флагами разделить рабочих от служащих.

А очень плохо использовать это в двух табличках ?
Просто хотел ограничить доступ пользователей к редактированию таблиц TBL_USERS, TBL_USERS_POSTS, TBL_USERS_DEPARTMENTS, TBL_USERS_ROLE, TBL_USERS_ROLE_ATRIB
авторЕсть такие страшные слова - "отчеты", "выборки", "запросы"... Без них и MSP
не обходится.
Да я это понимаю... =)
Просто думаю как хранить суммарные задачи в базе.
Суммарные задачи это задачи в скриншоте которые выделенные жирным!
Их атрибуты(зарплата,материалы, сроки и прочее) вычисляются из подзадач.
Грубо говоря это как дерево. Где листья это обычные задачи а узлы разветвления это и есть суммарные задачи. Ну а ствол и есть главная суммарная задача состоящая из других суммарных задач =)
авторP.S. Если мы так проектируем учет - то страшно подумать, как строим... :-)))
Я только начинаю =))) Поэтому и попросил указать на ошибки =)
Строим вроде нормально =)

Kirill Razuvaev
А вот этого - пока не ощущается.
Скажу честно, не вижу никакого смысла в Вашем случае хранить агрегаты. Их
хранят отдельно только тогда, когда эти итоги очень часто используются в
качестве исходных данных при объемных расчетов.

P.S. Короче, переделывайте и нормальную схему с бизнес-описанием
выкладывайте, если хотите совет получить. Не забыв, ессно, про все
вышеуказанное.


У каждой задачи есть объём работы. Этот объём измеряется в единицах измерения. Что бы не создавать лишнюю таблицу использую справочник единиц измерения материалов.

Переделывать всё полностью или только части по которым замечания ?

А можно ещё ссылочку на нормальное бизнес описание ? В интернете ничего не нашёл =(

Исправленная схема =)
Над описанием ещё работаю =)

Serguei
С ключами проблема большая у вас. Читайте что такое primary key и для чего они нужны.


Хм странно. Очень внимательно читал тему ключей.
Вроде сделал всё правильно. Не стал использовать естественный ключ а использую суррогатный ключ.
Вроде как у естественного есть недостатки.
Что именно неправильно ?

Составил схему бизнес-процессов =) ну а точнее что то приближённое =)