|
|
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. Я не могу никак увязать две сущности - действие и документ. На одном действии, например "Присвоение сотруднику квалификационной категории", может висеть как один документ "Приказ о присвоении", так и 2 документа: "Вышестоящий приказ о присвоении" и "Наш Приказ о присвоении". Я понимаю, что тут связь "один ко многим", 2 таблицы - "Действия" и "Документы", связанные "один ко многим". Но когда я так делаю, то запросы получаются совершенно безумные по объему и сложности, потому что действий полно, а один документ может висеть на разных действиях. Выглядит ужасно и работает через пень-колоду. Я решила было плюнуть и вообще не выносить документы в отдельную таблицу, а сделать для ИД документа 2 поля в основных таблицах. Например, в таблице "Действия" 2 поля "document_id". Но меня беспокоит, что это будет типа избыточность или как там ее. Я ненавижу избыточность и стараюсь строить базы строго из нужных полей, а тут получается, что одно поле "document_id" у меня почти всегда будет пустое (очень мало действий, на которых висело бы сразу 2 документа). Но зато запросы меньше и аккуратнее и работают чище. Посоветуйте что-нибудь, а то я запуталась. Что выбрать? Я хочу сделать по правилам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2017, 16:21 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurelЗдравствуйте. Я не могу никак увязать две сущности - действие и документ. На одном действии, например "Присвоение сотруднику квалификационной категории", может висеть как один документ "Приказ о присвоении", так и 2 документа: "Вышестоящий приказ о присвоении" и "Наш Приказ о присвоении". Я понимаю, что тут связь "один ко многим", 2 таблицы - "Действия" и "Документы", связанные "один ко многим". Но когда я так делаю, то запросы получаются совершенно безумные по объему и сложности, потому что действий полно, а один документ может висеть на разных действиях. Выглядит ужасно и работает через пень-колоду. Я решила было плюнуть и вообще не выносить документы в отдельную таблицу, а сделать для ИД документа 2 поля в основных таблицах. Например, в таблице "Действия" 2 поля "document_id". Но меня беспокоит, что это будет типа избыточность или как там ее. Я ненавижу избыточность и стараюсь строить базы строго из нужных полей, а тут получается, что одно поле "document_id" у меня почти всегда будет пустое (очень мало действий, на которых висело бы сразу 2 документа). Но зато запросы меньше и аккуратнее и работают чище. Посоветуйте что-нибудь, а то я запуталась. Что выбрать? Я хочу сделать по правилам. Если у Вас на одном действии может быть несколько документов, а один документ относиться к нескольким действиям - это, очевидно, отношение "многие ко многим". Достаточно странно, что добавление одной связующей таблицы превращает запросы в "безумные" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2017, 16:46 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин, спасибо за ответ. Понимаете, на самом деле получается гораздо больше таблиц в запросе! Вовсе не две! 1. Таблица "Действия". 2. Таблица "Ассоциированные документы", где действиям присвоены ид документов. 3. Таблица "Документы" с полями серии, номера, даты начала и окончания, выдавшей организации, подписавшего человека. 4. Таблица "Юрлица", связанная с таблицей "Документы" по ид_юрлица" - для получения в запросе наименования юрлица, выдавшего документ. 5. Таблица "Физлица", связанная с таблицей "Документы" по ид_физлица" - для получения в запросе наименования физлица, подписавшего документ. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2017, 16:54 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurelКот Матроскин, спасибо за ответ. Понимаете, на самом деле получается гораздо больше таблиц в запросе! Вовсе не две! Это понятно, я имел в виду -становится на одну таблицу больше. В одном случае у Вас 4 таблицы, в другом 5 - такая ли большая разница? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2017, 17:01 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurel может висеть как один документ "Приказ о присвоении", так и 2 документа: "Вышестоящий приказ о присвоении" и "Наш Приказ о присвоении".Если документов может быть только два и никогда три или больше (даже в военное время и по особому распоряжению) то ваш подход с двумя document_id вполне нормальный. Повесьте check на таблицу, чтобы исключить ситауации когда основной document_id пустой, а дополнительный нет. Добавление третьего document_id превращает check в очень громоздкий, а четвертый в полный кошмар. OkeTurel Я ненавижу избыточность и стараюсь строить базы строго из нужных полейЭто пройдет с годами ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2017, 17:38 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurel, ... Я хочу сделать по правилам. ...правила на то и существуют чтоб их нарушать....) избыточность - если не безумная может быть полезна .OkeTure..Я решила было плюнуть и вообще не выносить документы в отдельную таблицу, а сделать для ИД документа 2 поля в основных таблицах.... так можно и в уважаемый Ексель вернуться...)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2017, 18:02 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurelКот Матроскин, спасибо за ответ. Понимаете, на самом деле получается гораздо больше таблиц в запросе! Вовсе не две! 1. Таблица "Действия". 2. Таблица "Ассоциированные документы", где действиям присвоены ид документов. 3. Таблица "Документы" с полями серии, номера, даты начала и окончания, выдавшей организации, подписавшего человека. 4. Таблица "Юрлица", связанная с таблицей "Документы" по ид_юрлица" - для получения в запросе наименования юрлица, выдавшего документ. 5. Таблица "Физлица", связанная с таблицей "Документы" по ид_физлица" - для получения в запросе наименования физлица, подписавшего документ. И что с этими таблицами не так? Вполне нормальная структура. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2017, 18:26 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurelНа одном действии, например "Присвоение сотруднику квалификационной категории", может висеть как один документ "Приказ о присвоении", так и 2 документа: "Вышестоящий приказ о присвоении" и "Наш Приказ о присвоении" В этом месте у меня зарождается сомнение. Не буду выдавать всю цепочку размышлений, просто скажу результат: имхо, весь этот механизм в итоге приходит к примерно следующему дереву: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2017, 18:41 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
softwarerOkeTurelНа одном действии, например "Присвоение сотруднику квалификационной категории", может висеть как один документ "Приказ о присвоении", так и 2 документа: "Вышестоящий приказ о присвоении" и "Наш Приказ о присвоении" В этом месте у меня зарождается сомнение. Не буду выдавать всю цепочку размышлений, просто скажу результат: имхо, весь этот механизм в итоге приходит к примерно следующему дереву: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Вот мне тоже кажется, что у действия есть основание и это один документ, а у последнего в свою очередь своё основание. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.01.2017, 19:50 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurelЯ не могу никак увязать две сущности - действие и документ. OkeTurelПосоветуйте что-нибудь, а то я запуталась. Что выбрать? Я хочу сделать по правилам. К черту все правила... - всего и будет две таблицы (не учитывая прочей мишуры типа дат и подписей), только нужно поставить все с головы на ноги - документ первичен, действия по нему вторичны... - Все документы (и "Вышестоящие" и " Наши" в одной ГЛАВНОЙ таблице docs ) - Если документ "Вышестоящий" (выше уже не бывает), то значение owner (владелец) у него равно нулю (или null, кому как, но мне лучше ноль - ибо это конкретная величина) и соответственно, действий по нему В ПОДЧИНЕННОЙ таблице Actions может и не быть (а могут и быть). - Если документ " Наш", то значение owner у него содержит id_doc "Вышестоящего" документа из этой же таблицы Docs и соответственно в подчиненной таблице Actions есть вся движуха по этому документу... Преимущества: - Документов с owner = 0 "Вышестоящих" будет мало (по вашим же словам) и вы в запросах будете оперировать только с теми документами у которых owner > 0 с "Вашими" документами. - Не ограниченный уровень иерархии подчинения документов (например, сначала был приказ, потом директива со ссылкой на приказ, а потом уже внутренний приказ со ссылкой на директиву и естественно уже и действиями в Actions). - при желании "Вышестоящие" документы можно упаковывать и хранить как "Наши", например описывая в Actions их краткое содержание, суть и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 00:24 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
vmag- Не ограниченный уровень иерархии подчинения документов (например, сначала был приказ, потом директива со ссылкой на приказ, а потом уже внутренний приказ со ссылкой на директиву и естественно уже и действиями в Actions). Если такое будет, то в таблицу Docs добавить дополнительный признак наш/не наш дабы отделить мух от котлет... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 00:38 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
в общем имхо окончательный вариант таки с признаком наш/не наш (my) на случай если иерархия документов больше двух или если вообще нет "вышестоящих" документов, а только "наш", тогда признаки в записях ставим по ситуации: 1. Вышестоящий документ верхнего уровня: owner = 0 my = False (не "наш") 2. Вышестоящий документ промежуточный или нижнего уровня: owner = id_doc вышестоящего my = False (не "наш") 3. Наш документ имеющий Вышестоящий документ: owner = id_doc вышестоящего my = True ("наш") 4. Наш документ не имеющий Вышестоящего документа (сам по себе): owner = 0 my = True ("наш") Естественно основная работа теперь будет по признаку my = True ("наш") ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 01:04 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
vmag, Может быть ситуация, что с одним действием связаны несколько документов. А эти документы при этом не связаны между собой по типу главный / подчиненный. Например, есть приказ о присвоении категории, а есть к примеру медицинская справка об обследовании, которое должно выполняться при смене категории. То есть к одному действию надо присоединить два документа. Так что без дополнительной таблицы связи многие ко многим не обойтись. Да и связи между документами могут быть не такими однозначным. Например, есть приказ вышестоящей организации о присвоении категории тем, кто прошел тесты. И есть протокол проведения тестирования сотрудников. И у приказа о присвоении категории будет два вышестоящих документа - вышестоящий приказ и протокол тестирования. А это еще одна таблица связей. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 10:30 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
[quot Но когда я так делаю, то запросы получаются совершенно безумные по объему и сложности, потому что действий полно, а один документ может висеть на разных действиях. Выглядит ужасно и работает через пень-колоду. покажи пример безумных запросов. я полагаю, безумно сложные запросы ты даже никогда не видела. (очень мало действий, на которых висело бы сразу 2 документа). Но зато запросы меньше и аккуратнее и работают чище. не бывает "2". Либо один, либо больше одного - т. е . много. я думаю, тебе не надо паниковать, а надо делать как задумано по ТЗ, т. е. про первому варианту, одно действие - много документов. база данных не должна быть удобной для запросов, она должна быть адекватна по структуре своей задаче. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 10:35 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurelКот Матроскин, спасибо за ответ. Понимаете, на самом деле получается гораздо больше таблиц в запросе! Вовсе не две! 1. назови цифру, от которой ты бы считала, что в запросе много таблиц. потом я назову свою. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 10:37 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurel, вообще, покажи свою структуру уже... начальный или оба варианта ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 10:39 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
MasterZivназови цифру, от которой ты бы считала, что в запросе много таблиц. потом я назову свою. Точно, давайте меряться количеством таблиц! Код: sql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39. 40. 41. 42. 43. 44. 45. 46. 47. 48. 49. 50. 51. 52. 53. 54. 55. 56. 57. 58. 59. 60. 61. 62. 63. 64. 65. 66. 67. 68. 69. 70. 71. 72. 73. 74. 75. 76. 77. 78. 79. 80. 81. 82. 83. 84. 85. 86. 87. 88. 89. 90. 91. 92. 93. 94. 95. 96. 97. 98. 99. 100. 101. 102. 103. 104. 105. 106. 107. 108. 109. 110. 111. 112. 113. 114. 115. 116. 117. 118. 119. 120. 121. 122. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 11:19 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
s_ustinovvmag, Может быть ситуация, что с одним действием связаны несколько документов. А эти документы при этом не связаны между собой по типу главный / подчиненный. Например, есть приказ о присвоении категории, а есть к примеру медицинская справка об обследовании, ИМХО вы собрали в кучу не собираемое (приказ о присвоении очередного воинского звания со справкой в бассейн)... в Docs руководящие документы, а если нудны подтверждающие документы (иногда), то проще завести дополнительную таблицу для этого и повесить её уже на таблицу Actions как подчиненную... Но даже в той прошлой моей последней схеме ваша проблема решается на ура добавлением еще одного признака в таблицу Docs - статус документа (например 1 это руководящий, 2 - сопутствующий) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 11:45 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurelЯ не могу никак увязать две сущности - действие и документ. На одном действии, например "Присвоение сотруднику квалификационной категории", может висеть как один документ "Приказ о присвоении", так и 2 документа: "Вышестоящий приказ о присвоении" и "Наш Приказ о присвоении". я бы сочла, что это типа ежедневника или контроля исполнения документов номерном для ссылки на вышестояший автордатаназваниеисполнительдата исполнение статус10директор10/01/2017наградить женщин к 8 мартапрофком20/02/2017110директор02/03/2017выдать женщинам по хххх руббухгалтерия06/03/201720директор11/01/2017наградить участников вовсовет ветеранов10/02/2017вып120директор22/02/2017выдать ветеранам по хххх руббухгалтерия23/02/201731профком12/01/2017запрос в отдел кадров на работающих женщин старше 30 летотдел кадров14/01/2017вып41профком14/01/2017роздать цехам спискисеменова15/01/2017вып51профком18/01/2017получить спискисеменова20/01/201762совет ветеранов19/01/2017запрос в отдел кадров на работающих ветерановотдел кадров20/01/2017вып72совет ветеранов20/01/2017составить и выверить списки пенсионеров-ветерановильина22/01/2017вып82совет ветеранов25/01/2017оформить ответ в дирекциюильина26/01/2017вып ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 13:35 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
Здравствуйте. :^) Сейчас прочту все посты и все уясню, а пока только уяснила, что требуется показать мою структуру. Вот моя структура, пожалуйста. [img] http://savepic.net/8882997.jpg [/img] ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 15:48 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurelЗдравствуйте. :^) Сейчас прочту все посты и все уясню, а пока только уяснила, что требуется показать мою структуру. Вот моя структура, пожалуйста. [img] http://savepic.net/8882997.jpg [/img] Для начала требуется вашу структуру немного упорядочить, чтобы связи через весь экран не проходили... Вы сами вашу структуру в таком виде понимаете? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 16:14 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
Добавлю, что у меня кадровая база, т.к. я кадровик, а специализированных кадровых систем типа 1-С или Паруса у нас нет. Приходится пыхтеть самой. :) Уважаемые ответившие, у меня в таблице "Документы" ЕСТЬ 2 поля document_id и document1_id, и второе поле как раз для наддокумента. Я им пользовалась для допсоглашений к трудовым договорам: трудовой договор - наддокумент для допсоглашения, другими словами - допсоглашение подчинено трудовому договору. Но в случае с приказами я не пользовалась этим, а теперь поняла, что да, вышестоящий областной приказ - наддокумент для нашего внутреннего приказа. Когда я вставила эту связь, то запрос заработал более-менее сносно. Хотя я согласна с s_ustinov, могут быть и два несвязанных между собой документа, висящие на одном действии. Тогда запрос выдает на одного сотрудника 2 строки. А это нельзя, потому что из запроса все экспортируется программно в Эксель в бланк приказа. Но с другой стороны, действительно можно добавить дополнительные свойства документам, типа "руководящий", "сопутствующий", как советует vmag. И в запросе отсеять только нашей организации документы. А с третьей стороны, можно предельно "раздробить" действия, сделать их очень мелкими, и тогда, наверно, будет одно действие - один документ, как и пишет skyANA. SERG1257, я сейчас попробовала без этого, но если будет продолжаться с моей базой такая петрушка, то придётся. Устала разбираться в собственных запросах. :) MasterZiv, у меня в одном запросе 9 таблиц, из этих таблиц 6 штук - на самом деле не таблицы, а другие запросы, которые сами состоят из таблиц числом от четырех до семи. Можно ли это считать нормальным? аля1ц, я не хочу в Эксель, мне он не нравится. ) vmag, я долго ломала голову, что первично, мне кажется, что первично действие, возможно я ошибаюсь. Не знаю, в таблице "Документы" можно сделать ссылку на что угодно - на код звания, на код отпуска, на код физлица для личных документов типа паспортов. И как-то в формах сначала показываются эти действия, а при нажатии на плюсик развертываются документы, мне кажется, это значит, что документы вторичны? Ну, не знаю. ПЕНСИОНЕРКА, да, похоже на мою таблицу "документы". Большое спасибо, что ответили мне. :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 16:40 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
s_ustinov, как это упорядочить структуру, там структура нелинейная, не типа "ступенька - другая ступенька", а все перемешано. Все равно будут косые линии. Если приглядеться, то понимаю. ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 16:42 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurels_ustinov, как это упорядочить структуру, там структура нелинейная, не типа "ступенька - другая ступенька", а все перемешано. Все равно будут косые линии. Если приглядеться, то понимаю. ) Речь не о косых линиях. При проектировании БД стараются таблицы располагать группами. И чтобы большая часть связей была внутри групп, а между группами было 1-2 связи, а не паутина. У вас вроде так не получается, так как много "петель". Скорее всего, надо повысить уровень нормализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 16:47 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
softwarer, это все так красиво выглядит, как Вы начертили, а на деле не знаю даже, на каждой таблице куча других - кто подписал документ, какая организация издала, если трудовой договор - то на какой основании действует подписавший. Возможно, надо избавиться от некоторой информации, хотя и жалко. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 16:51 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurel, Например таблицы persons accounts operations documents_associates образуют "кольцо". Это явный признак избыточности данных (денормализованная база). У вас явно не те объемы данных, чтобы денормализация была оправданной. Поэтому на вашем месте я бы попробовал для начала привести всё к третьей форме, а уже после этого продумывать, как связывать действия и документы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 16:54 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
s_ustinov, я не знаю, захотите ли Вы смотреть мою базу, если я ее приложу, но я уверяю Вас - моя база в смысле нормализации хорошая! У меня ни оно значение не вводится дважды, как и пишут в книгах про базы. И ни одно значение не вводится, если его можно рассчитать (ну, типа стажа - он считается программно). Как и пишут в книгах про базы, у меня таблицы приведены к этим пресловутым нормальным формам. Ну, по крайней мере, я старалась. Хорошо, я дома постараюсь поаккуратней расположить на экране таблицы и сделаю скрин снова. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 16:56 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
s_ustinov, если Вы так считаете, что там кольцо, то тогда я подумаю. Возможно, я чего-то не учла. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 16:57 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurels_ustinov, я не знаю, захотите ли Вы смотреть мою базу, если я ее приложу, но я уверяю Вас - моя база в смысле нормализации хорошая! А тот рисунок, что вы выложили - не ваша база? Я говорил про базу на рисунке - она довольно сильно денормализована. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 17:02 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
s_ustinov, проклятие, я не знала не про какие кольца! Но я поняла - располагать группами, связывать в группах, а связь групп - только в малых дозах. Посмотрю. Мне всегда казалось, что надо одну тему располагать в одной таблице, скажем "награждения", "звания", "лицевые счета", "табельные номера", "наказания", "отпуска" и т.д., у меня так сделано, и все это висит на персон_ид, ну, на человеке то есть... На аккаунт_ид висят операции. Думаю, кольцо из-за сборной таблицы "ассоциированные документы", где каждому документу ставятся в соответствие или отпуск, или звание, или наказание, или персона. Не делать же много таблиц "документы", где каждому документу только одно что-то соответствует, типа "документ званий", "документы отпусков". Так разве правильно. Таблиц будет уйма. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 17:09 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurels_ustinov, проклятие, я не знала не про какие кольца! Но я поняла - располагать группами, связывать в группах, а связь групп - только в малых дозах. Посмотрю. Это не жесткое правило, но так намного удобнее проектировать схему БД. OkeTurelМне всегда казалось, что надо одну тему располагать в одной таблице, скажем "награждения", "звания", "лицевые счета", "табельные номера", "наказания", "отпуска" и т.д., Правильно, это называется "сущность". OkeTurelДумаю, кольцо из-за сборной таблицы "ассоциированные документы", где каждому документу ставятся в соответствие или отпуск, или звание, или наказание, или персона. Не делать же много таблиц "документы", где каждому документу только одно что-то соответствует, типа "документ званий", "документы отпусков". Так разве правильно. Таблиц будет уйма. У вас проблема со схемой БД - именно об этом свидетельствуют "кольца". В чем именно... В том виде, в каком схема БД сейчас, разбирать долго. Попробуйте сами упорядочить свою схему - после этого будет понятнее. А количество таблиц не обязательно станет больше. Скорее всего можно будет обойтись одной универсальной таблицей "документы". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 17:19 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurelsoftwarer, это все так красиво выглядит, как Вы начертили, а на деле не знаю даже, на каждой таблице куча других О том, что я нарисовал, надо думать ещё до таблиц. Надо представить бизнес-процесс в чётких и удобных терминах. А те таблицы, которые Вы называете - это справочники, их может быть сколько угодно, они практически не влияют на сложность запроса. s_ustinovобразуют "кольцо". Это явный признак избыточности данных (денормализованная база). Хм. Имхо, недостаточно обоснованное утверждение, назовём так. Прямо таки хочется спросить, как избавиться от избыточности данных и нормализовать следующую базу: Код: plaintext 1. 2. 3. 4. 5. s_ustinovУ вас проблема со схемой БД - именно об этом свидетельствуют "кольца" Хм. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 17:32 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
softwarerХм. Имхо, недостаточно обоснованное утверждение, назовём так. https://ru.wikipedia.org/wiki/%D0%A2%D1%80%D0%B5%D1%82%D1%8C%D1%8F_%D0%BD%D0%BE%D1%80%D0%BC%D0%B0%D0%BB%D1%8C%D0%BD%D0%B0%D1%8F_%D1%84%D0%BE%D1%80%D0%BC%D0%B0]Запоминающееся и, по традиции, наглядное резюме определения 3NF Кодда было дано Биллом Кентом: каждый неключевой атрибут «должен предоставлять информацию о ключе, полном ключе и ни о чём, кроме ключа »[1]. То есть атрибут должен зависеть только от ключа. Не допускается зависимость одного неключевого атрибута от другого неключевого атрибута. На картинке в таблице documents_associates атрибут person_id зависит от (однозначно определяется) атрибута operation_id. И при этом operation_id не является первичным ключом documents_associates. И как раз "петли" и показывают "визуально" наличие таких нарушений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 18:17 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
s_ustinovНа картинке в таблице documents_associates атрибут person_id зависит от (однозначно определяется) атрибута operation_id. Вы так думаете? :) Я вот не вижу оснований для такого утверждения. И даже уверен, что нет никаких проблем построить контрпример. s_ustinovИ как раз "петли" и показывают "визуально" наличие таких нарушений. Я Вам чуть выше нарисовал петлю. И жду указаний на избыточные данные и инструкций по денормализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 18:24 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
softwarers_ustinovНа картинке в таблице documents_associates атрибут person_id зависит от (однозначно определяется) атрибута operation_id. Вы так думаете? :) Я вот не вижу оснований для такого утверждения. И даже уверен, что нет никаких проблем построить контрпример. Я уверен , так как могу построить запрос, однозначно определяющий person_id для любого operation_id, не используя таблицу documents_associates. А это и есть зависимость одного атрибута от другого. Любопытно будет посмотреть на контрпример. softwarers_ustinovИ как раз "петли" и показывают "визуально" наличие таких нарушений. Я Вам чуть выше нарисовал петлю. И жду указаний на избыточные данные и инструкций по денормализации. Не очень понятно, где в вашем примере "петля" - вы ведь, насколько понимаю, нарисовали данные из одной таблички. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 18:36 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurelvmag, я долго ломала голову, что первично, мне кажется, что первично действие, возможно я ошибаюсь. Не знаю, в таблице "Документы" можно сделать ссылку на что угодно... По вашей логике кадровик сидит в курилке курит и вдруг видит дрейфующего по аллее прапорщика Сидорова, который пришпандорил себе на китель майорские погоны... ну да, действие совершено, нужно подрываться и срочно готовить приказ о присвоении прапорщику Сидорову очередное воинское звание майор... Документ (грубо) состоит из: шапки и тела документа (возьмите за образец что угодно для наглядности например накладную, счет, акт...). В главную таблицу docs пишут шапку (номер, дата документа, ...) а в подчиненную строки этого документа - в вашем случае это подчиненная таблица "действия"... То, что у вас все наоборот (действие первично) говорит о том, что у вас очень разнородные документы вплоть до полной несовместимости, например, как совместить присвоение звания и отпуск (разное количество и назначение атрибутов) ? Если бы вы сразу сказали, что у вас кадровая задача, я бы вам сразу посоветовал уйти от реляционной БД и посмотреть в сторону БД для хранения документов типа 1С кадры и ей подобных, там именно складируются разнородные документы, на базе которых написаны соответствующие обработки и кстати там такая же структура всех документов - шапка + тело документа... НО ОНИ ВСЕ РАЗНЫЕ ПО СТРУКТУРЕ И В ШАПКЕ И В ТЕЛЕ... OkeTurelя кадровик, а специализированных кадровых систем типа 1-С или Паруса у нас нет Остается только посочувствовать... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 19:14 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
s_ustinovНе очень понятно, где в вашем примере "петля" - вы ведь, насколько понимаю, нарисовали данные из одной таблички. Хм. А Вы посмотреть в эти данные не пробовали? Могу ещё написать ddl этой таблицы, если так не очевидно: Код: sql 1. 2. 3. 4. 5. 6. По-прежнему жду указаний по нормализации этой петли :) s_ustinovЯ уверен , так как могу построить запрос, однозначно определяющий person_id для любого operation_id, не используя таблицу documents_associates. А кто Вам сказал, что person_id, лежащий в таблице documents_associates, каким-либо образом зависит от person_id, который Вы можете определить через operation_id? Положите в эту структуру информацию "Иванов выписал живительных пиздюлей Петрову" - вот и будет тот контрпример, который Вы не чаяли увидеть ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 19:41 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
vmag, только хотел пригласить Вас в студию.. )) да чо ждать-то жисть - покажет обязательно обязательно избыточность может быть - ОЧЕНЬ полезна )) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 19:42 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
OkeTurel, у вас к таблице persons прицеплено по кону персоны наверное 20 таблиц без малейшего ущерба для понимания вы можете скрыть эту таблицу(правой мышкой) --- тогда вы увидите реальную схему ваших остальных таблиц, а не паутину ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 20:02 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
softwarers_ustinovНе очень понятно, где в вашем примере "петля" - вы ведь, насколько понимаю, нарисовали данные из одной таблички. Хм. А Вы посмотреть в эти данные не пробовали? Могу ещё написать ddl этой таблицы, если так не очевидно: Код: sql 1. 2. 3. 4. 5. 6. По-прежнему жду указаний по нормализации этой петли :) Насколько помню, во "Введении" что то написано о нормализации в таких ситуациях... Будет время, прочитаю - напишу. softwarers_ustinovЯ уверен , так как могу построить запрос, однозначно определяющий person_id для любого operation_id, не используя таблицу documents_associates. А кто Вам сказал, что person_id, лежащий в таблице documents_associates, каким-либо образом зависит от person_id, который Вы можете определить через operation_id? Положите в эту структуру информацию "Иванов выписал живительных пиздюлей Петрову" - вот и будет тот контрпример, который Вы не чаяли увидеть Я исхожу из того, что имена атрибутам выдаются все же осмысленно. Например, чуть выше используются названия "id" и "parent_id" В нормальных базах для записи информации типа "Иванов выписал живительных пиздюлей Петрову" используются поля с названиями "ID выписывающего пиздюли" и "ID получающего пиздюли". Я все таки верю в людей... Возможно, зря... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 21:02 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
ПЕНСИОНЕРКАOkeTurel, у вас к таблице persons прицеплено по кону персоны наверное 20 таблиц без малейшего ущерба для понимания вы можете скрыть эту таблицу(правой мышкой) --- тогда вы увидите реальную схему ваших остальных таблиц, а не паутинусхема - в Мозгу и из Мозга.. и тд лична не нужны бумазьки, карандаши и авторучки правильно Уровень - Чуйки с Уважением к ВАМ ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 21:24 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
s_ustinovВ нормальных базах для записи информации типа "Иванов выписал живительных пиздюлей Петрову" используются поля с названиями "ID выписывающего пиздюли" и "ID получающего пиздюли". А длчя записи информации "Иванов подарил цветочки Петрову" - в этих нормальных базах делают отдельную таблицу с отдельными атрибутами? А для "Петров ответил Иванову на форуме" - третью? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 21:28 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
Кот Матроскинs_ustinovВ нормальных базах для записи информации типа "Иванов выписал живительных пиздюлей Петрову" используются поля с названиями "ID выписывающего пиздюли" и "ID получающего пиздюли". А длчя записи информации "Иванов подарил цветочки Петрову" - в этих нормальных базах делают отдельную таблицу с отдельными атрибутами? А для "Петров ответил Иванову на форуме" - третью? Неееее... Для таких задач создают ОДНУ таблицу: CREATE TABLE actions ( [id_action] [int] IDENTITY(1,1) NOT NULL, [Что Дулин сделал для Михалыча] [nvarchar](max) ); А потом заносят в неё мега ценную информацию: INSERT INTO actions ([Что Дулин сделал для Михалыча]) VALUES ('Подарил очень красивую красную розу'); или INSERT INTO actions ([Что Дулин сделал для Михалыча]) VALUES ('Признался в неземной любви'); ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 22:09 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
s_ustinovКот Матроскинпропущено... А длчя записи информации "Иванов подарил цветочки Петрову" - в этих нормальных базах делают отдельную таблицу с отдельными атрибутами? А для "Петров ответил Иванову на форуме" - третью? Неееее... Для таких задач создают ОДНУ таблицу: Для каких "таких"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 22:24 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
Кот Матроскинs_ustinovпропущено... Неееее... Для таких задач создают ОДНУ таблицу: Для каких "таких"? Для таких: Кот МатроскинА длчя записи информации "Иванов подарил цветочки Петрову" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 22:38 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
s_ustinov, Т.е. Вы все верите, верите в людей, рассчитываете что они будут только морды друг другу бить, и тут раз - кто-то кому-то дарит цветочки. И все, базу на выброс? Непрактично как-то :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.02.2017, 23:23 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
Кот Матроскин, Не так всё было. :)) Я верю в людей, верю в то, что дети сегодня заснут пораньше... И тут бац! Предлагают хранить в базе информацию "Иванов подарил цветочки Петрову"... Ну вот как так можно? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2017, 00:33 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
vmag, я вчера вечером подумала и теперь согласна с Вами. Я переделаю базу "от документа", т.е. первичным будет документ, пляшем от документа, на нем висят дейтсвия. Кстати, по-моему и в Парусе сделано "от документа". Спасибо за совет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2017, 09:31 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
ПЕНСИОНЕРКА, совершенно верно, у меня на персон_ид висят образование, аттестация, семейное положение, больничные, контроль флюорографии и санминимума, ассоциированные персоны (мамы-папы), наказания и награждения. Да, скрыла, стало понятней. Спасибо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2017, 09:35 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#18+
softwarer, все в общих чертах понятно, и я решила вообще уйти от реаляционной модели и сделать как в 1-С, как мне советовал vmag. У меня получалась реляция, потому что я придавала большое значение таблице "персоны" и считала ее главной и думала - надо, чтобы на ней все висело. Думаю, надо сделать "Персоны" простым справочником, который, может, и связан-то ни с чем не будет, ну, будет ИД, но этот ИД в таком большом количестве документов будет (как шапок документов, так и табличной части), что нет смысла там связи будет делать. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 02.02.2017, 10:59 |
|
||
|
Проектирование без избыточности
|
|||
|---|---|---|---|
|
#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?all=1&fid=32&tid=1540198]: |
0ms |
get settings: |
10ms |
get forum list: |
14ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
61ms |
get topic data: |
12ms |
get forum data: |
3ms |
get page messages: |
86ms |
get tp. blocked users: |
2ms |
| others: | 231ms |
| total: | 427ms |

| 0 / 0 |

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