powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование без избыточности
13 сообщений из 63, страница 3 из 3
Проектирование без избыточности
    #39397263
аля1ц
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
OkeTurelsoftwarer, все в общих чертах понятно, и я решила вообще уйти от реаляционной модели и сделать как в 1-С, как мне советовал vmag. У меня получалась реляция, потому что я придавала большое значение таблице "персоны" и считала ее главной и думала - надо, чтобы на ней все висело.

Думаю, надо сделать "Персоны" простым справочником,

который, может, и связан-то ни с чем не будет,

ну, будет ИД,
но этот ИД в таком большом количестве
документов будет (как шапок документов, так и табличной части),
что нет смысла там связи будет делать.

ну вроде - Умница


почти

..;))
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39398662
Бредятина
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelЗдравствуйте.

Я не могу никак увязать две сущности - действие и документ. На одном действии, например "Присвоение сотруднику квалификационной категории", может висеть как один документ "Приказ о присвоении", так и 2 документа: "Вышестоящий приказ о присвоении" и "Наш Приказ о присвоении".
Я понимаю, что тут связь "один ко многим", 2 таблицы - "Действия" и "Документы", связанные "один ко многим". Но когда я так делаю, то запросы получаются совершенно безумные по объему и сложности, потому что действий полно, а один документ может висеть на разных действиях. Выглядит ужасно и работает через пень-колоду.

Я решила было плюнуть и вообще не выносить документы в отдельную таблицу, а сделать для ИД документа 2 поля в основных таблицах. Например, в таблице "Действия" 2 поля "document_id". Но меня беспокоит, что это будет типа избыточность или как там ее. Я ненавижу избыточность и стараюсь строить базы строго из нужных полей, а тут получается, что одно поле "document_id" у меня почти всегда будет пустое (очень мало действий, на которых висело бы сразу 2 документа). Но зато запросы меньше и аккуратнее и работают чище.

Посоветуйте что-нибудь, а то я запуталась. Что выбрать? Я хочу сделать по правилам.
Здравствуйте.
Чтобы "сделать по правилам" нужно знать теорию и практику проектирования баз данных на таком уровне, на котором Вы не будете нуждаться в советах)) Сейчас Вам полезны большинство советов, то есть, советы для Вас совершенно бесполезны. У Вас сейчас - не имеющая никакого смысла схема БД, которую советы могут сделать только еще более бессмысленной. Если Вы, действительно, хотите тратить свою жизнь на изучение теории и практики проектирования баз данных, то (с учетом того, что у Вас есть и какая-то основная работа, насколько я понимаю) у Вас уйдет от трех до пяти лет, чтобы сделать хороший техпроект в этой предметной области. Собственно первые же два-три месяца и Вам самой покажут - интересно ли Вам, на самом деле, это занятие)) Начните со словаря. И с какого-нибудь относительно сложного понятия, например, "документ".
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39402365
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Здравствуйте.

Я переделала базу, вот моя новая схема.
http://hostingkartinok.com/show-image.php?id=5d241fdb6c770eb5599549021e9032c2

Все висит на таблице "Документы".
База стала намного удобнее. Большинство запросов оказались не нужны. Оставшиеся срабатывают без ошибок.
В коде тоже многое стало не нужно, и формы почти все вообще перестали нуждаться в модулях.
Макросы, скорее всего, многие тоже отправятся в топку.
Общий вес базы сократился примерно в 2 раза без потери функциональности.

Спасибо большое за прекрасные советы!
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39402401
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurel
Да, сейчас намного красивее :)
Попробуйте еще person_id перенести в таблицу "Документы" (убрав из остальных таблиц). Ведь это поле есть во всех документах. И подумать о переносе других "общих" полей, которые есть во всех (или большинстве) документах. И вам намного проще будет строить запрос "Получить все документы по Васе Пупкину".
То есть ваша база будет содержать ОДНУ основную таблицу "документы", в которую заносятся основные данные по документу - сотрудник, тип документа, номер документа (дата документа и еще несколько полей, которые есть во всех или почти всех документах). И будет еще два основных справочника - сотрудники и типы документов.
И таблицы - расшифровки для каждого типа документов, где они требуются. Некоторые типы документов могут содержать только общие поля, уже содержащиеся в основной таблице "Документы", и не требовать отдельной таблицы для дополнительных, специфичных только для этого типа документов, полей.

Сейчас, чтобы найти список всех документов по сотруднику, вам надо включить в запрос таблицы для всех возможных типов документов. И если добавите новый тип документов - надо будет переделывать этот запрос (добавлять новую таблицу).
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39402720
Фотография vmag
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurel,

ну из всех минусов теперь явных только два и то спорных:
- необходима доработка структуры и возможно интерфейса при добавлении нового типа документов... прямо как у фирмы 1С...
- из-за простоты схемы, вместо вас для доработок и развития теперь могут взять какого-то пионэра...
берегите исходники...
зато есть плюсы и они гораздо весомее:
- теперь вам всё понятно, прозрачно и спокойнее на душе...
- ничего не глючит и работает быстрее...
- вы становитесь востребованной (пока) с точки зрения развития и доработки программы...
- Ой... а с технической точки зрения сколько плюсов... только одна мысль о том, что строки каждого документа можно хранить в отдельном хранилище сразу решает кучу проблем: с архивацией, доступом,
объемами документов, переходом на новый год и т.д.
имхо ваша модель теперь таки имеет шансы...
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39403412
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Привет! :о)

s_ustinov, но у меня в базе документ может относиться к одному сотруднику (типа паспорт или пенсионное) и к нескольким сразу (например, на приказе о приеме на работу может висеть несколько сотрудников, один документ - несколько людей). И во втором случае вставлять person_id в таблицу "Документы", наверно, не надо? Или тогда придется дублировать документы, скажем, один приказ занести 2 раза, на Иванова и тот же самый на Петрова.

vmag, я не против дорабатывать структуру... Сейчас вот 54 типа документа в таблице "Категории документов", будут еще - доработаю (табличка для табличной части, формочка для ввода в табличную часть, если надо - запросик для вывода в Ворд или Эксель).

Да, я вздохнула спокойно по сравнению с теми временами, когда считала, что реляционная база - это круто.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39403490
buven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurelИ во втором случае вставлять person_id в таблицу "Документы", наверно, не надо? Или тогда придется дублировать документы, скажем, один приказ занести 2 раза, на Иванова и тот же самый на Петрова.

А вот здесь я бы пошел к тому, кто подписывает, и слезно попросил подписывать приказы на каждого отдельно:)
Приказы же формируются на основании заявления о приеме, которое, в свою очередь, ни разу не коллективное.
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39403689
Фотография ПЕНСИОНЕРКА
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
buvenПриказы же формируются на основании заявления о приеме, которое, в свою очередь, ни разу не коллективное.

бригаду ремонтников в 20 человек посылают в командировку --печатаем 20 приказов
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39403707
Кот Матроскин
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
ПЕНСИОНЕРКАbuvenПриказы же формируются на основании заявления о приеме, которое, в свою очередь, ни разу не коллективное.

бригаду ремонтников в 20 человек посылают в командировку --печатаем 20 приказов
Решили всем сотрудникам проиндексировать зарплату - делаем приказ на каждого из тысячи сотрудников. И все это потому что программист не очень понимает отношение M:N :)
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39403714
buven
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кот МатроскинПЕНСИОНЕРКАпропущено...


бригаду ремонтников в 20 человек посылают в командировку --печатаем 20 приказов
Решили всем сотрудникам проиндексировать зарплату - делаем приказ на каждого из тысячи сотрудников. И все это потому что программист не очень понимает отношение M:N :)
Приказ будет один, доп. соглашений к ТД будет 1000 :)
Я в кадрах не силен, поэтому, наверно, не совсем корректно выразился. Посыл был в том, что некоторые процессы можно и нужно "выпрямлять" на уровне регламентов, и довольно часто их кривость видна именно при попытке автоматизации бардака:)
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39404229
s_ustinov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
OkeTurel
s_ustinov, но у меня в базе документ может относиться к одному сотруднику (типа паспорт или пенсионное) и к нескольким сразу (например, на приказе о приеме на работу может висеть несколько сотрудников, один документ - несколько людей). И во втором случае вставлять person_id в таблицу "Документы", наверно, не надо? Или тогда придется дублировать документы, скажем, один приказ занести 2 раза, на Иванова и тот же самый на Петрова.

Сейчас в базе у вас один номер документа (одна строка) и несколько строк в таблице конкретного вида документа (один ко многим)?
Можно оставить существующую схему, но лично я бы добавил таблицу "Детали документа" со связью много к одному с таблицей "Документы", где и указывал бы сотрудника. И тогда уже к этой таблице делал уточняющие таблицы.
Сейчас вам надо под каждый новый тип документа создавать новые таблицы, а это не всегда нужно. Очень большое количество таблиц начинает мешать со временем.

OkeTurelДа, я вздохнула спокойно по сравнению с теми временами, когда считала, что реляционная база - это круто.

А какая, по вашему мнению, у вас база сейчас?
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39405420
OkeTurel
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
s_ustinovСейчас в базе у вас один номер документа (одна строка) и несколько строк в таблице конкретного вида документа (один ко многим)?Да.
s_ustinovА какая, по вашему мнению, у вас база сейчас? Ну, реляционная, но в меру... ))) Связь всего по id_документа...
...
Рейтинг: 0 / 0
Проектирование без избыточности
    #39419005
аля1ц
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
OkeTurels_ustinovСейчас в базе у вас один номер документа (одна строка) и несколько строк в таблице конкретного вида документа (один ко многим)?Да.
s_ustinovА какая, по вашему мнению, у вас база сейчас?
Ну, реляционная, но в меру... )))

Связь всего по id_документа...

во-во ----->>> почти Задорнов

но в меру

)))


ач е - этого мало чоль
...
Рейтинг: 0 / 0
13 сообщений из 63, страница 3 из 3
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Проектирование без избыточности
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]