Новые сообщения [новые:0]
Дайджест
Горячие темы
Избранное [новые:0]
Форумы
Пользователи
Статистика
Статистика нагрузки
Мод. лог
Поиск
|
28.09.2011, 15:38
|
|||
---|---|---|---|
Как лучше организовать хранение истории сущности? |
|||
#18+
День добрый! Посоветуйте, пожалуйста, как лучше организовать хранение истории всех изменений некоей сущности? Я вижу такие варианты: 1) Для каждой Entity - таблица где хранятся все ее состояния [проще сделать, сложнее выводить т.к. придется либо кодом проходить по всем полям и искать что изменилось, что убого, либо делать дополнительный View и туда класть изменения средствами БД] 2) Для каждой Entity - таблица где хранится разница с предыдущим состоянием (т.е. хранение изменений) [проще для GUI, но полноценной истории нет, если одно из изменений потеряно то дело плохо] 3) Универсальная таблица где хранятся все изменения или состояния в каком-то универсальном виде (например строка с разделителями которая содержит JSON с измененными полями и их значениями) [нереляционно как-то] Что подсказывает Ваш опыт? ... |
|||
:
Нравится:
Не нравится:
|
|||
|
28.09.2011, 15:49
|
|||
---|---|---|---|
Как лучше организовать хранение истории сущности? |
|||
#18+
DymytryДень добрый! Посоветуйте, пожалуйста, как лучше организовать хранение истории всех изменений некоей сущности? Я вижу такие варианты: 1) Для каждой Entity - таблица где хранятся все ее состояния [проще сделать, сложнее выводить т.к. придется либо кодом проходить по всем полям и искать что изменилось, что убого, либо делать дополнительный View и туда класть изменения средствами БД] 2) Для каждой Entity - таблица где хранится разница с предыдущим состоянием (т.е. хранение изменений) [проще для GUI, но полноценной истории нет, если одно из изменений потеряно то дело плохо] 3) Универсальная таблица где хранятся все изменения или состояния в каком-то универсальном виде (например строка с разделителями которая содержит JSON с измененными полями и их значениями) [нереляционно как-то] Что подсказывает Ваш опыт? Опыт подсказывает, что вы предложили варианты решения, которые должны выбираться в соответствии с требованиями. А требований вы озвучили аж одно: "организовать хранение". И ни словом не обмолвились, для чего собираетесь хранить (как использовать) и какие есть нюансы (требования) этого использования. Поэтому для Вас по требованиям подходят все три варианта, можете думать про ограничения "время", "деньги", "качество". :). Если, конечно же, вы не поделитесь дополнительными требованиями. И подскажу - аргументы "убого" обсуждать тяжело, ибо у всех участников будут разные системы координат для оценки "убогости". :) ... |
|||
:
Нравится:
Не нравится:
|
|||
|
28.09.2011, 15:55
|
|||
---|---|---|---|
Как лучше организовать хранение истории сущности? |
|||
#18+
АнатоЛой, требования размытые: организовать логирование и показ изменений некоторых сущностей. То есть хранить и выводить таблицу Автор - Что Изменил (...) - Дата ИЛИ Автор - Значения полей - Дата. Я не могу решить какой вариант лучше и как это лучше организовать, поэтому и спрашиваю людей которые возможно набили на этом шишки. Что же здесь непонятного? :) ... |
|||
:
Нравится:
Не нравится:
|
|||
|
28.09.2011, 16:16
|
|||
---|---|---|---|
Как лучше организовать хранение истории сущности? |
|||
#18+
Dymytry, создай таблицу-копию с полем version_id ... |
|||
:
Нравится:
Не нравится:
|
|||
|
28.09.2011, 16:41
|
|||
---|---|---|---|
Как лучше организовать хранение истории сущности? |
|||
#18+
DymytryАнатоЛой, требования размытые: организовать логирование и показ изменений некоторых сущностей. То есть хранить и выводить таблицу Автор - Что Изменил (...) - Дата ИЛИ Автор - Значения полей - Дата. Я не могу решить какой вариант лучше и как это лучше организовать, поэтому и спрашиваю людей которые возможно набили на этом шишки. Что же здесь непонятного? :) 1. Вот теперь понятно больше. А то может Вы просто забыли нам про требования рассказать :). 2. Выберите сначала какой вариант вывода результата лучше. Или нужно оба? Какой будет использоваться чаще? 1) Автор - Что Изменил (...) - Дата 2) Автор - Значения полей - Дата. Если не можете определиться сами - сделайте пару примеров в ворде и покажите постановщику ваших "размытых требований". 3. Оценить затраты на реализацию предложенных Вами вариантов мы не можем: ничего не знаем про проект, технологии и т.д. и т.п., поэтому этот критерий вам оценивать самим. 4. Теперь отстранённо просто про варианты: 4.1. Вариант "отдельная таблица на сущность с полным состоянием на момент времени" - перечень полей понятен - те же, что у сущности + пара новых "служебных". 1) желательно именно отдельная - не придётся переделывать существующий функционал. 2) "убогого" в решении ничего не вижу - прост в реализации - это не убог. Простой выбор, когда именно мы несём вычислительные затраты на получение отчёта по истории изменений: в этом варианте напрягаем комп сравнением изменений как раз в момент, когда нужен отчёт - но удваиваем ввод-вывод по БД при изменении . 3) если понадобится функционал "выдай мне состояние всех атрибутов сущности на момент X" - вуаля, всё хранится в готовом виде. 4.2. "отдельная таблица на сущность с разницей от предыдущего состояния" - непонятен перечень полей для такой таблицы. можно пример? но минус уже виден - разницу нужно посчитать в момент изменения - и если она уже не считается в процессе для других целей, то это доп.нагрузка на основной процесс (и такая нагрузка для некоторых будет выглядеть "убого" :) ). 4.3. "А-ля JSON" имеет право на жизнь - всё зависит от уже используемых в проекте технологий. Недостаток - при обработке запись полностью извлекается из БД, если: пользователя интересует не только простыня изменений, а чтобы ответ на вопрос: "Кто последним поменял ОКПО у контрагента Ч?" выдавался парой строк по заданным пользователем параметрам к отчёту изменений, а не поиском пальцем слова "ОКПО" в 5 листах распечатки по одному контрагенту. Ваш нереляционный вариант с JSON и историей изменений может быть и более "реляционным": History_of_Changes(id, entity_name, entity_id, field_name, old_value, new_value), где x_value - имеет достаточного запаса по типу данных для логирования изменений. "-" - нужно оценивать возможный перерасход места в БД из-за "больших" размеров типов old_value и new_value. Ещё опыт подсказывает, что если есть свой фреймворк и метаописание сущностей, то необходимость логирования той или иной сущности указывайте в метаописании - и по-любому логируйте изменения самих метаописаний. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
28.09.2011, 16:58
|
|||
---|---|---|---|
Как лучше организовать хранение истории сущности? |
|||
#18+
DymytryАнатоЛой, требования размытые: организовать логирование и показ изменений некоторых сущностей. То есть хранить и выводить таблицу Автор - Что Изменил (...) - Дата ИЛИ Автор - Значения полей - Дата. Я не могу решить какой вариант лучше и как это лучше организовать, поэтому и спрашиваю людей которые возможно набили на этом шишки. Что же здесь непонятного? :) Имхо, проще всего как-то так (разумеется, есть ряд ограничений): Код: plaintext 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. 123. 124. 125. 126. 127. 128. 129. 130. 131. 132. 133. 134. 135. 136. 137. 138. 139. 140. 141. 142. 143. 144. 145. 146. 147. 148. 149. 150. 151. 152. 153. 154. 155. 156. 157. 158. 159. 160. 161. 162. 163. 164. 165. 166. 167. 168. 169. 170. 171. 172. 173. 174. 175. 176.
Триггер генерится скриптом, которому передается имя таблицы. Допиливать по вкусу. ... |
|||
:
Нравится:
Не нравится:
|
|||
|
30.09.2011, 16:08
|
|||
---|---|---|---|
Как лучше организовать хранение истории сущности? |
|||
#18+
Dymytry...2) Для каждой Entity - таблица где хранится разница с предыдущим состоянием (т.е. хранение изменений) [проще для GUI, но полноценной истории нет, если одно из изменений потеряно то дело плохо]... сталкивался с таким "журналированием изменений"... упрощенно - сущность - поле - старое значение - новое - время изменения по сути прикручивается чтоб собирались данные по любым таблицам БД... не такой-то и большой объем... на практике, поднакопились данные за несколько лет... и когда надо было восстановить ситуацию, нужно было смотреть в виде "таблицы истории" для определеных записей сущности... это все выполнялось неприлично длительное время... не могу сказать чтоб были кривые запросы и медленные сервера... зачастую забивали на этот "секс" и старались обходиться без лазания по такому "журналу" ... |
|||
:
Нравится:
Не нравится:
|
|||
|
|
start [/forum/search_topic.php?author=%D0%BF%D0%BE%D1%81%D1%82%D0%BE%D1%8F%D0%BD%D0%BD%D1%8B%D0%B9+%D0%BC%D0%B5%D0%BC%D0%B1%D0%B5%D1%80&author_mode=last_posts&do_search=1]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
get settings: |
9ms |
get forum list: |
12ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
55ms |
get topic data: |
12ms |
get forum data: |
2ms |
get page messages: |
43ms |
get tp. blocked users: |
2ms |
others: | 440ms |
total: | 604ms |
0 / 0 |