|
|
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurelsoftwarer, все в общих чертах понятно, и я решила вообще уйти от реаляционной модели и сделать как в 1-С, как мне советовал vmag. У меня получалась реляция, потому что я придавала большое значение таблице "персоны" и считала ее главной и думала - надо, чтобы на ней все висело. Думаю, надо сделать "Персоны" простым справочником, который, может, и связан-то ни с чем не будет, ну, будет ИД, но этот ИД в таком большом количестве документов будет (как шапок документов, так и табличной части), что нет смысла там связи будет делать. ну вроде - Умница почти ..;)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2017, 14:26 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurelЗдравствуйте. Я не могу никак увязать две сущности - действие и документ. На одном действии, например "Присвоение сотруднику квалификационной категории", может висеть как один документ "Приказ о присвоении", так и 2 документа: "Вышестоящий приказ о присвоении" и "Наш Приказ о присвоении". Я понимаю, что тут связь "один ко многим", 2 таблицы - "Действия" и "Документы", связанные "один ко многим". Но когда я так делаю, то запросы получаются совершенно безумные по объему и сложности, потому что действий полно, а один документ может висеть на разных действиях. Выглядит ужасно и работает через пень-колоду. Я решила было плюнуть и вообще не выносить документы в отдельную таблицу, а сделать для ИД документа 2 поля в основных таблицах. Например, в таблице "Действия" 2 поля "document_id". Но меня беспокоит, что это будет типа избыточность или как там ее. Я ненавижу избыточность и стараюсь строить базы строго из нужных полей, а тут получается, что одно поле "document_id" у меня почти всегда будет пустое (очень мало действий, на которых висело бы сразу 2 документа). Но зато запросы меньше и аккуратнее и работают чище. Посоветуйте что-нибудь, а то я запуталась. Что выбрать? Я хочу сделать по правилам. Здравствуйте. Чтобы "сделать по правилам" нужно знать теорию и практику проектирования баз данных на таком уровне, на котором Вы не будете нуждаться в советах)) Сейчас Вам полезны большинство советов, то есть, советы для Вас совершенно бесполезны. У Вас сейчас - не имеющая никакого смысла схема БД, которую советы могут сделать только еще более бессмысленной. Если Вы, действительно, хотите тратить свою жизнь на изучение теории и практики проектирования баз данных, то (с учетом того, что у Вас есть и какая-то основная работа, насколько я понимаю) у Вас уйдет от трех до пяти лет, чтобы сделать хороший техпроект в этой предметной области. Собственно первые же два-три месяца и Вам самой покажут - интересно ли Вам, на самом деле, это занятие)) Начните со словаря. И с какого-нибудь относительно сложного понятия, например, "документ". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 04.02.2017, 17:47 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Я переделала базу, вот моя новая схема. http://hostingkartinok.com/show-image.php?id=5d241fdb6c770eb5599549021e9032c2 Все висит на таблице "Документы". База стала намного удобнее. Большинство запросов оказались не нужны. Оставшиеся срабатывают без ошибок. В коде тоже многое стало не нужно, и формы почти все вообще перестали нуждаться в модулях. Макросы, скорее всего, многие тоже отправятся в топку. Общий вес базы сократился примерно в 2 раза без потери функциональности. Спасибо большое за прекрасные советы! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2017, 15:49 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurel Да, сейчас намного красивее :) Попробуйте еще person_id перенести в таблицу "Документы" (убрав из остальных таблиц). Ведь это поле есть во всех документах. И подумать о переносе других "общих" полей, которые есть во всех (или большинстве) документах. И вам намного проще будет строить запрос "Получить все документы по Васе Пупкину". То есть ваша база будет содержать ОДНУ основную таблицу "документы", в которую заносятся основные данные по документу - сотрудник, тип документа, номер документа (дата документа и еще несколько полей, которые есть во всех или почти всех документах). И будет еще два основных справочника - сотрудники и типы документов. И таблицы - расшифровки для каждого типа документов, где они требуются. Некоторые типы документов могут содержать только общие поля, уже содержащиеся в основной таблице "Документы", и не требовать отдельной таблицы для дополнительных, специфичных только для этого типа документов, полей. Сейчас, чтобы найти список всех документов по сотруднику, вам надо включить в запрос таблицы для всех возможных типов документов. И если добавите новый тип документов - надо будет переделывать этот запрос (добавлять новую таблицу). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.02.2017, 17:10 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurel, ну из всех минусов теперь явных только два и то спорных: - необходима доработка структуры и возможно интерфейса при добавлении нового типа документов... прямо как у фирмы 1С... - из-за простоты схемы, вместо вас для доработок и развития теперь могут взять какого-то пионэра... берегите исходники... зато есть плюсы и они гораздо весомее: - теперь вам всё понятно, прозрачно и спокойнее на душе... - ничего не глючит и работает быстрее... - вы становитесь востребованной (пока) с точки зрения развития и доработки программы... - Ой... а с технической точки зрения сколько плюсов... только одна мысль о том, что строки каждого документа можно хранить в отдельном хранилище сразу решает кучу проблем: с архивацией, доступом, объемами документов, переходом на новый год и т.д. имхо ваша модель теперь таки имеет шансы... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.02.2017, 16:58 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
Привет! :о) s_ustinov, но у меня в базе документ может относиться к одному сотруднику (типа паспорт или пенсионное) и к нескольким сразу (например, на приказе о приеме на работу может висеть несколько сотрудников, один документ - несколько людей). И во втором случае вставлять person_id в таблицу "Документы", наверно, не надо? Или тогда придется дублировать документы, скажем, один приказ занести 2 раза, на Иванова и тот же самый на Петрова. vmag, я не против дорабатывать структуру... Сейчас вот 54 типа документа в таблице "Категории документов", будут еще - доработаю (табличка для табличной части, формочка для ввода в табличную часть, если надо - запросик для вывода в Ворд или Эксель). Да, я вздохнула спокойно по сравнению с теми временами, когда считала, что реляционная база - это круто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2017, 13:06 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurelИ во втором случае вставлять person_id в таблицу "Документы", наверно, не надо? Или тогда придется дублировать документы, скажем, один приказ занести 2 раза, на Иванова и тот же самый на Петрова. А вот здесь я бы пошел к тому, кто подписывает, и слезно попросил подписывать приказы на каждого отдельно:) Приказы же формируются на основании заявления о приеме, которое, в свою очередь, ни разу не коллективное. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2017, 14:34 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
buvenПриказы же формируются на основании заявления о приеме, которое, в свою очередь, ни разу не коллективное. бригаду ремонтников в 20 человек посылают в командировку --печатаем 20 приказов ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2017, 17:53 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
ПЕНСИОНЕРКАbuvenПриказы же формируются на основании заявления о приеме, которое, в свою очередь, ни разу не коллективное. бригаду ремонтников в 20 человек посылают в командировку --печатаем 20 приказов Решили всем сотрудникам проиндексировать зарплату - делаем приказ на каждого из тысячи сотрудников. И все это потому что программист не очень понимает отношение M:N :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2017, 18:22 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
Кот МатроскинПЕНСИОНЕРКАпропущено... бригаду ремонтников в 20 человек посылают в командировку --печатаем 20 приказов Решили всем сотрудникам проиндексировать зарплату - делаем приказ на каждого из тысячи сотрудников. И все это потому что программист не очень понимает отношение M:N :) Приказ будет один, доп. соглашений к ТД будет 1000 :) Я в кадрах не силен, поэтому, наверно, не совсем корректно выразился. Посыл был в том, что некоторые процессы можно и нужно "выпрямлять" на уровне регламентов, и довольно часто их кривость видна именно при попытке автоматизации бардака:) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 13.02.2017, 18:48 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurel s_ustinov, но у меня в базе документ может относиться к одному сотруднику (типа паспорт или пенсионное) и к нескольким сразу (например, на приказе о приеме на работу может висеть несколько сотрудников, один документ - несколько людей). И во втором случае вставлять person_id в таблицу "Документы", наверно, не надо? Или тогда придется дублировать документы, скажем, один приказ занести 2 раза, на Иванова и тот же самый на Петрова. Сейчас в базе у вас один номер документа (одна строка) и несколько строк в таблице конкретного вида документа (один ко многим)? Можно оставить существующую схему, но лично я бы добавил таблицу "Детали документа" со связью много к одному с таблицей "Документы", где и указывал бы сотрудника. И тогда уже к этой таблице делал уточняющие таблицы. Сейчас вам надо под каждый новый тип документа создавать новые таблицы, а это не всегда нужно. Очень большое количество таблиц начинает мешать со временем. OkeTurelДа, я вздохнула спокойно по сравнению с теми временами, когда считала, что реляционная база - это круто. А какая, по вашему мнению, у вас база сейчас? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.02.2017, 15:28 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
s_ustinovСейчас в базе у вас один номер документа (одна строка) и несколько строк в таблице конкретного вида документа (один ко многим)?Да. s_ustinovА какая, по вашему мнению, у вас база сейчас? Ну, реляционная, но в меру... ))) Связь всего по id_документа... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 16.02.2017, 08:40 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurels_ustinovСейчас в базе у вас один номер документа (одна строка) и несколько строк в таблице конкретного вида документа (один ко многим)?Да. s_ustinovА какая, по вашему мнению, у вас база сейчас? Ну, реляционная, но в меру... ))) Связь всего по id_документа... во-во ----->>> почти Задорнов но в меру ))) ач е - этого мало чоль ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 14.03.2017, 15:20 |
|
||
|
|

start [/forum/topic.php?fid=32&msg=39403689&tid=1540198]: |
0ms |
get settings: |
13ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
45ms |
get topic data: |
8ms |
get forum data: |
6ms |
get page messages: |
46ms |
get tp. blocked users: |
1ms |
| others: | 245ms |
| total: | 385ms |

| 0 / 0 |

Извините, этот баннер — требование Роскомнадзора для исполнения 152 ФЗ.
«На сайте осуществляется обработка файлов cookie, необходимых для работы сайта, а также для анализа использования сайта и улучшения предоставляемых сервисов с использованием метрической программы Яндекс.Метрика. Продолжая использовать сайт, вы даёте согласие с использованием данных технологий».
... ля, ля, ля ...