|
Хранение в мета-таблице ссылок на таблицы и столбцы других таблиц
|
|||
---|---|---|---|
#18+
Задача : 1 ) Хранение в специальной таблице (назовём её meta ) ссылок на таблицы и столбцы других таблиц. 2 ) При переименовании таблиц и столбцов эти ссылки должны сохранять свою целостность (должны оставаться рабочими). 3 ) При восстановлении БД из дампа эти ссылки должны сохранять свою целостность (должны оставаться рабочими). На первый взгляд, со ссылками на таблицы задача решается с помощью столбца meta.table типа regclass : при переименовании таблиц мы всегда будет видеть в meta.table текущие (актуальные) имена таблиц. Но поскольку тип regclass фактически хранит идентификатор oid , то при восстановлении БД из дампа все такие ссылки потеряют актуальность (целостность). Что касается столбцов, то для них вообще ничего нет - даже псевдотипа regatt (столбцы не являются глобальными объектами PostgreSQL и в системных таблицах не имеют собственных oid ). Поскольку триггеров на ALTER TABLE не существует, то единственным вариантом вижу хранение имён таблиц и столбцов, а при их переименовании - аналогичное переименование строк-имён в таблице meta (UPDATE-запросом). Есть ли ещё какие варианты ? ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2020, 00:28 |
|
Хранение в мета-таблице ссылок на таблицы и столбцы других таблиц
|
|||
---|---|---|---|
#18+
Cyrax_02 Есть ли ещё какие варианты ? Вы зря на счет "триггеров на ALTER TABLE не существует" Можете попробовать через https://www.postgresql.org/docs/13/sql-createeventtrigger.html / https://www.postgresql.org/docs/13/event-trigger-definition.html конечно, он как раз для таких извращений и придуман. Так и 2 и 3 решится. PS: в сём омуте живут драконы (в смысле вероятнее всего ничего хорошего из вашей затеи в целом не получится без совершенно запредельного объема работы). Обьясните нафига вам это надо может все сильно проще можно сделать. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
16.11.2020, 09:30 |
|
Хранение в мета-таблице ссылок на таблицы и столбцы других таблиц
|
|||
---|---|---|---|
#18+
Maxim BogukОбьясните нафига вам это надо может все сильно проще можно сделать.Задача банальная: учёт изменения данных. Проще - это как? У меня просто никогда не бывает. Карма такая... Maxim BogukPS: в сём омуте живут драконы (в смысле вероятнее всего ничего хорошего из вашей затеи в целом не получится без совершенно запредельного объема работы ).Вот, состряпал: Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.
... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 00:15 |
|
Хранение в мета-таблице ссылок на таблицы и столбцы других таблиц
|
|||
---|---|---|---|
#18+
Если имена столбцов не содержат имён таблиц, то при переименовании столбцов нужно ещё добавить проверку таблицы (т.к. в разных таблицах могут быть одноимённые столбцы). И тогда второе регулярное выражение "по протяжённости" станет длиннее первого. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 00:49 |
|
Хранение в мета-таблице ссылок на таблицы и столбцы других таблиц
|
|||
---|---|---|---|
#18+
Окончательный вариант (с проверкой таблицы при переименовании столбца): Код: plsql 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23.
... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 01:06 |
|
Хранение в мета-таблице ссылок на таблицы и столбцы других таблиц
|
|||
---|---|---|---|
#18+
Cyrax_02, А добавление - удаление столбцов у вас не бывает? ps: для целей аудита - бессмысленно тот у кого есть права на alter у него вероятнее всего окажется достаточно прав чтобы триггер отключить. pps: "Задача банальная: учёт изменения данных." какое же это изменение данных если это изменение структуры а его отслеживают путем непускания кого попала в базу и внос любых изменений скриптами миграции которые под системой контроля версий живут. -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 01:25 |
|
Хранение в мета-таблице ссылок на таблицы и столбцы других таблиц
|
|||
---|---|---|---|
#18+
Такое Код: 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.
1. до конца не определился какие столбцы оставить, а какие убрать из information_schema.ddl_events 2. не учитывается работа с ролями\пользователями 3. на некоторых моментах идет двойная запись 4. действует на уровне бд в которой создано ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 09:07 |
|
Хранение в мета-таблице ссылок на таблицы и столбцы других таблиц
|
|||
---|---|---|---|
#18+
Maxim BogukА добавление - удаление столбцов у вас не бывает?Так при удалении/добавлении столбцов в таблице с историей ничего не меняется. Соответственно, ничего делать не нужно. Как я написал выше, задачей является учёт изменения данных , а не структуры таблиц/БД. авторps: для целей аудита - бессмысленно тот у кого есть права на alter у него вероятнее всего окажется достаточно прав чтобы триггер отключитьЧтобы триггер отключить, нужны права суперпользователя. Maxim Bogukpps: "Задача банальная: учёт изменения данных." какое же это изменение данных если это изменение структуры а его отслеживают путем непускания кого попала в базуНет, это именно отслеживание изменения данных. Для решения этой задачи необходимо обеспечить корректное хранение ссылок на таблицы и столбцы. Именно эта подзадача и озвучена в сабже. ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 12:00 |
|
Хранение в мета-таблице ссылок на таблицы и столбцы других таблиц
|
|||
---|---|---|---|
#18+
GuzyaТакое ... 1. до конца не определился какие столбцы оставить, а какие убрать из information_schema.ddl_events 2. не учитывается работа с ролями\пользователями 3. на некоторых моментах идет двойная запись 4. действует на уровне бд в которой создано Это уже задача аудита изменений структуры БД. Тем не менее, посетителям форума будет полезно. Нечто подобное реализуется здесь . ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 13:05 |
|
Хранение в мета-таблице ссылок на таблицы и столбцы других таблиц
|
|||
---|---|---|---|
#18+
Cyrax_02 Maxim BogukА добавление - удаление столбцов у вас не бывает? Как я написал выше, задачей является учёт изменения данных , а не структуры таблиц/БД. авторps: для целей аудита - бессмысленно тот у кого есть права на alter у него вероятнее всего окажется достаточно прав чтобы триггер отключитьЧтобы триггер отключить, нужны права суперпользователя. Maxim Bogukpps: "Задача банальная: учёт изменения данных." какое же это изменение данных если это изменение структуры а его отслеживают путем непускания кого попала в базуНет, это именно отслеживание изменения данных. Для решения этой задачи необходимо обеспечить корректное хранение ссылок на таблицы и столбцы. Именно эта подзадача и озвучена в сабже. 1)не понимаю как у вас переименование колонки в таблице (и тем более таблицы) выливается в изменение данных в ней? 2)для изменения структуры таблицы в нормальной схеме безопасности тоже требуется суперпользователь (чтобы посторонние не лазали с ddl поперед dba) В общем вариант я вам подсказал, подачу вы приняли... делаете вы что то очень странное (за 22года работы dba/db-dev с postgresql не видел такой задачи а видел я очень и очень много) но в принципе сделать это рабочим возможно. ps: сейчас подскажу схему как в вашу систему обмануть - удаляем колонку и добавляем с тем же именем заново... в итоге аудит ничего не увидел в истории ничего нет а в колонке все значения на null заменились почему то (я кстати с таким в реальности встречался после кривых миграций). -- Maxim Boguk лучшая поддержка PostgreSQL: dataegret.ru ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 13:28 |
|
Хранение в мета-таблице ссылок на таблицы и столбцы других таблиц
|
|||
---|---|---|---|
#18+
Maxim Boguk1)не понимаю как у вас переименование колонки в таблице (и тем более таблицы) выливается в изменение данных в ней? 2)для изменения структуры таблицы в нормальной схеме безопасности тоже требуется суперпользователь (чтобы посторонние не лазали с ddl поперед dba)Логика, реализующая задачу " поддерживать актуальность ссылок на таблицы и столбцы при переименовании таблиц и столбцов " совсем не должна реализовывать другие задачи. Учёт изменения данных, производимых пользователями, будет выполняться приложением явным образом. Соответственно, эти пользователи не будут иметь прямого доступа к БД. Не являюсь сторонником реализации всей бизнес-логики на уровне БД. авторВ общем вариант я вам подсказал, подачу вы приняли... делаете вы что то очень странное (за 22года работы dba/db-dev с postgresql не видел такой задачи а видел я очень и очень много) но в принципе сделать это рабочим возможно.Не может быть такого, чтобы вы не сталкивались с задачей хранения истории изменения данных в отдельных таблицах. А такая задача всегда требует хранения ссылок на таблицы и столбцы (сабж). авторps: сейчас подскажу схему как в вашу систему обмануть - удаляем колонку и добавляем с тем же именем заново... в итоге аудит ничего не увидел в истории ничего нет а в колонке все значения на null заменились почему то (я кстати с таким в реальности встречался после кривых миграций).Такого не будет, потому что при удалении и добавлении столбцов данные не меняются. Таблица с историей изменения данных не содержит и не должна содержать истории изменения структуры таблиц. Т.е. обмануть не получится... ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 14:31 |
|
Хранение в мета-таблице ссылок на таблицы и столбцы других таблиц
|
|||
---|---|---|---|
#18+
Cyrax_02 Maxim Boguk1)не понимаю как у вас переименование колонки в таблице (и тем более таблицы) выливается в изменение данных в ней? 2)для изменения структуры таблицы в нормальной схеме безопасности тоже требуется суперпользователь (чтобы посторонние не лазали с ddl поперед dba) авторВ общем вариант я вам подсказал, подачу вы приняли... делаете вы что то очень странное (за 22года работы dba/db-dev с postgresql не видел такой задачи а видел я очень и очень много) но в принципе сделать это рабочим возможно.Не может быть такого, чтобы вы не сталкивались с задачей хранения истории изменения данных в отдельных таблицах. А такая задача всегда требует хранения ссылок на таблицы и столбцы (сабж). авторps: сейчас подскажу схему как в вашу систему обмануть - удаляем колонку и добавляем с тем же именем заново... в итоге аудит ничего не увидел в истории ничего нет а в колонке все значения на null заменились почему то (я кстати с таким в реальности встречался после кривых миграций).Такого не будет, потому что при удалении и добавлении столбцов данные не меняются. Таблица с историей изменения данных не содержит и не должна содержать истории изменения структуры таблиц. Извиняюсь, ИМХО Вы - Китайский пионер, Сам создаю себе задачи и Сам успешно их решаю... ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 14:37 |
|
Хранение в мета-таблице ссылок на таблицы и столбцы других таблиц
|
|||
---|---|---|---|
#18+
Cyrax_02Таблица с историей изменения данных не содержит и не должна содержать истории изменения структуры таблиц. Тогда зачем нужен Event Trigger ??? Просто читаем из актуальную структуру из pg_catalog... ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 15:15 |
|
Хранение в мета-таблице ссылок на таблицы и столбцы других таблиц
|
|||
---|---|---|---|
#18+
Cyrax_02 Таблица с историей изменения данных не содержит и не должна содержать истории изменения структуры таблиц. Вы отслеживаете переименования таблиц и колонок, а это — изменения структуры. Напр., если я переименовал таблицу table1 в cities, данные не изменились, а структура БД — да. Изменение данных — это «в колонке num такой-то записи было 8 стало 6». ... |
|||
:
Нравится:
Не нравится:
|
|||
17.11.2020, 15:44 |
|
Хранение в мета-таблице ссылок на таблицы и столбцы других таблиц
|
|||
---|---|---|---|
#18+
fteТогда зачем нужен Event Trigger ??? Просто читаем из актуальную структуру из pg_catalog... Как вы предлагаете отслеживать переименование таблиц и столбцов без событийного триггера ??? Что касается pg_catalog , то он не содержит ни данных таблиц, ни предыдущих (до переименования) имён таблиц/столбцов. Ы2Вы отслеживаете переименования таблиц и колонок, а это — изменения структуры. Напр., если я переименовал таблицу table1 в cities, данные не изменились, а структура БД — да. Изменение данных — это «в колонке num такой-то записи было 8 стало 6». Переименовываем столбец num в num20 . Далее смотрим, что у нас в истории. А в истории по-прежнему «в колонке num такой-то записи = 6» . Некто из зала предлагает менять имена таблиц и столбцов в таблице истории данных одновременно с их фактическим переименованием. Чтобы после переименования в истории было не «в колонке num такой-то записи = 6» , а «в колонке num20 такой-то записи = 6» . Но ему возражают: отслеживание переименования таблиц и столбцов - это не история изменения данных, а история изменения структуры. А значит, нужно отслеживать все изменения структуры, а не только таблиц и столбцов, что нужно ограничивать права пользователей БД, нужно использовать систему контроля версий и т.д. и т.п. Но некто возражает: мол, достаточно отслеживать только имена таблиц и столбцов, т.к. для ведения таблицы истории данных не нужно отслеживать все изменения структуры. Ему снова возражают: мол, так никто не далает, вы предлагаете очень странные вещи. И начинают объяснять, что такое изменение данных, а что такое изменение структуры. Ведь некто этого абсолютно не понимает. АБСОЛЮТНО. P.S . Это уже классический троллинг. Иначе это объяснить нельзя... ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 08:56 |
|
Хранение в мета-таблице ссылок на таблицы и столбцы других таблиц
|
|||
---|---|---|---|
#18+
Cyrax_02Переименовываем столбец num в num20 . Далее смотрим, что у нас в истории. А в истории по-прежнему «в колонке num такой-то записи = 6» . Некто из зала предлагает менять имена таблиц и столбцов в таблице истории данных одновременно с их фактическим переименованием. Чтобы после переименования в истории было не «в колонке num такой-то записи = 6» , а «в колонке num20 такой-то записи = 6» . В истории зафиксирован момент изменения данных. Появились они, когда колонка называлась num. Затем структура изменилась, теперь колонка называется num20. Вы хотите пройтись по истории и везде переименовать num в num20? Ваше право. Хорошо ли это? Сомнительно. Cyrax_02Но ему возражают: отслеживание переименования таблиц и столбцов - это не история изменения данных, а история изменения структуры. А значит, нужно отслеживать все изменения структуры, а не только таблиц и столбцов. <…> Но некто возражает: мол, достаточно отслеживать только имена таблиц и столбцов, т.к. для ведения таблицы истории данных не нужно отслеживать все изменения структуры. И, на мой взгляд, зря возражает, т.к. при таком подходе у него могут появиться данные, о которых его история ничего не знает: добавили колонку с какими-то готовыми значениями, попользовались и удалили. Если данные не обновлялись , в истории их существование не отразится. Поэтому разумно протоколировать изменения как данных, так и структуры. Cyrax_02И начинают объяснять, что такое изменение данных, а что такое изменение структуры. Ведь некто этого абсолютно не понимает. АБСОЛЮТНО. Я не чтец в ваших мыслях, вижу лишь то, что вы пишите , не более. А пишите вы так, что создается впечатление , будто вы данные и структуру не вполне различаете. Возможно, вас спасло бы что-то вроде timetravel, чтобы можно было посмотреть состояние базы на произвольный момент в прошлом. ... |
|||
:
Нравится:
Не нравится:
|
|||
18.11.2020, 14:59 |
|
|
start [/forum/topic.php?fid=53&msg=40019206&tid=1994368]: |
0ms |
get settings: |
9ms |
get forum list: |
13ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
144ms |
get topic data: |
10ms |
get forum data: |
2ms |
get page messages: |
47ms |
get tp. blocked users: |
1ms |
others: | 15ms |
total: | 247ms |
0 / 0 |