|
|
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
Хотелось бы узнать мнение на тему, кто как организует логическое удаление записей в БД (когда они удаляются на уровне пользователей, но физически продолжают присутствовать в БД) и какие в связи с этим преимущества и недостатки. Сейчас я вижу 2 варианта: 1. Пометка записи на удаление, т.е. введение поля статуса записи. 2. Введение в схему БД дополнительных таблиц для удаленных записей со структурой, совпадающей с оригинальной и перенос туда записей при удалении. По 1-му подходу я вижу следующие недостатки: некоторое увеличение времени запросов к данным, т.к. приходится отфильтровывать "удаленные" записи, а также усложнение в случае наличия уникальных ключей, когда значение ключа занимается удаленной записью и не может быть использовано в актуальной, т.е. ключ надо расширять на 2 поля. По 2-му подходу недостаток - в усложнении структуры данных и усложнении операции логического удаления (нужно помнить, что если у записи есть ссылки в дочерних таблицах, то их тоже нужно переносить в соответствующие зеркальные таблицы удаленных записей). Кто поделится мыслями или опытом по данной проблеме? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2006, 20:14 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
При наличии статусного поля время можно сделать практически неизменным с помощью партиционирования. Хотя не факт, что стоит так делать - имхо это зависит в первую очередь от ожидаемой пропорции актуальных и удаленных записей. Делая партиционирование по статусу, мы ускоряем select за счет торможения delete-а. Второй вариант - максимум, можно рассматривать как решение там, где нет партиционирования. Хотя все равно некрасиво. Логику работы с дочерними записями в любом случае придется тщательно прописывать. Даже при простановке статуса он же должен быть каскадно проставлен зависимым записям итп. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.03.2006, 22:08 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
softwarerДаже при простановке статуса он же должен быть каскадно проставлен зависимым записям итп Ну как вариант не ставить статус для зависимых, а действовать в зависимости от статуса главной записи - например написать соответствующие view. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 10:31 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
_spy_ softwarerДаже при простановке статуса он же должен быть каскадно проставлен зависимым записям итп Ну как вариант не ставить статус для зависимых, а действовать в зависимости от статуса главной записи - например написать соответствующие view. Такой вариант у нас часто используется, единственная проблема не забывать делать проверку везде, где обрабатывается перечень. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 10:35 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
EstetsТакой вариант у нас часто используется, единственная проблема не забывать делать проверку везде, где обрабатывается перечень. Ну как раз если организовать все запросы через фильтрующее представление, то эта проблема обходится ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 10:40 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
_spy_Ну как вариант Обратите внимание на основную фразу: логику обработки зависимостей в любом случае придется тщательно прописывать. Как именно - отдельный обсуждаемый вопрос. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 11:40 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
softwarerОбратите внимание на основную фразу: логику обработки зависимостей в любом случае придется тщательно прописывать. Как именно - отдельный обсуждаемый вопрос. Согласен, поэтому в том моем посте я цитировал только вашу фразу насчет реализации этой логики ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 11:48 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
А зачем хранить "удаленные" записи? Если хранить их без взаимосвязей, то разобраться в них будет просто невозможно. Если со связями, то вполне могут возникнуть взаимные коллизии. ИМХО. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 15:18 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
Удаленные данные хранятся для анализа и статистики (а также на случай возможного восстановления). Т.е. они могут быть недоступны обычным пользователям, которые будут считать, что данные удалены, но доступны привилегированным пользователям, которые смогут видеть всю историю и строить статистические отчеты. В том-то и дело, что при логическом удалении должны сохраняться все взаимосвязи. Хотелось бы услышать попдробнее насчет возможных взаимных коллизий. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 15:41 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
_spy_Хотелось бы услышать попдробнее насчет возможных взаимных коллизий. Была группа товара "Автомобили". Удалили все товары этой группы, а саму группу переименовали в "Лифчики". Можно так? Почему нет? Вот и увидит превилигированный пользователь в "Лифчиках" "ВАЗ-2110". Оно надо? А если подобная практика достаточно часта, то он там и "Гематоген" может увидеть и "черта лысого". Разбираться заморишся. И это самая простая (одноступенчатая) коллизия. Я помню, пробовал заниматься такой же вещью. За год работы ни разу этим не воспользовался, зато объем "логов" стал почти на порядок больше данных. Прибил, ибо нафик не надо. Может кроме случаев, оговоренных в законодательсве. Мусор надо выкидывать, ИМХО. А восстанавливать нужно из бэкапов, которые делать регулярно автоматом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 15:59 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
авторБыла группа товара "Автомобили". Удалили все товары этой группы, а саму группу переименовали в "Лифчики". Можно так? Почему нет? Вот и увидит превилигированный пользователь в "Лифчиках" "ВАЗ-2110". Оно надо? А если подобная практика достаточно часта, то он там и "Гематоген" может увидеть и "черта лысого". Разбираться заморишся. Ну это все решается на уровне бизнес-логики приложения. Переименовать можно и при наличии записей в группе, тогда ВАЗ в "Лифчиках" увидят все пользователи. А можно сделать так, что при удалении всех записей в группе автоматом удаляется и сама группа. Подразумевается все ж таки, что семантика групп не меняется, если говорить только о коллизиях такого рода. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 16:11 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
_spy_Ну это все решается на уровне бизнес-логики приложения. Если есть охота решать - решай. Только по объему это "решание" возможно будет сопоставимо с основным функционалом. Я бы все таки посоветовал честно ответить самому себе на вопрос - так ли нужны "анализ и статистика" по удаленным (читай ненужным) данным. Если действительно нужны - то желаю удачи. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.03.2006, 16:19 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
Ненужных данных в системе практически не бывает. Зато идиотов-пользователей - сколько угодно и еще больше. И как человек, который некоторое время регулярно разбирался с тем, что пользователи натворили в базе, могу сказать: любого прога, который попробует безвозвратно удалять любую запись, успевшую поучаствовать в бизнес-процессах, нужно срочно и серьезно лечить. Байка на тему. Некий пользователь пишет письмо в техподдержку - мол, не могу найти в системе приложение такое-то к договору такому-то. Девочка из поддержки ему терпеливо отвечает - мол, жмете сюда, вводите вот это, жмете сюда и получаете что хотите. Я не знаю, что ел на завтрак этот пользователь, но получив это письмо, он жмет куда указано, находит это приложение, удаляет его, после чего пишет второе письмо - мол, ни фига так не находится, ты не хочешь выполнять свои обязанности и помогать мне решить важную для бизнеса задачу, в общем, готовься увидеть небо в алмазах. Я в принципе допускаю, что данный конкретный случай был провокацией на тему "не прибьет ли эта девочка этого пользователя". Вот только таких не один и не два. Их почти за каждым десктопом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2006, 19:02 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
_spy_Ну как вариант не ставить статус для зависимых, а действовать в зависимости от статуса главной записи - например написать соответствующие view. Т.е. тада надо будет написать запросы на соединение даже если главная табла не нужна? А када нужна - тада для этих табл другие view, чтобы избежать этих соединений? А када удаление из дочерних таблов то все то же? Практика первого варианта есть в старом досовом клиппере. Там все что удалено помечается. Второй вариант похож на аудит (скорее всего триггерный). Ить тада можно еще записывать и кто и что не тока удалил, но и изменил. Я такое делал. Но там были просто "особые" данные изменение которых китайцы считали серьезным преступлением. Но всю БД так аудить накладновато будет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.03.2006, 20:40 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
vadiminfoТ.е. тада надо будет написать запросы на соединение даже если главная табла не нужна? А када нужна - тада для этих табл другие view, чтобы избежать этих соединений? А када удаление из дочерних таблов то все то же? Да, все же вариант с каскадной простановкой статусов при логическом удалении главной записи видится более предпочтительным. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.03.2006, 16:39 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
softwarerПри наличии статусного поля время можно сделать практически неизменным с помощью партиционирования. Хотя не факт, что стоит так делать - имхо это зависит в первую очередь от ожидаемой пропорции актуальных и удаленных записей. Делая партиционирование по статусу, мы ускоряем select за счет торможения delete-а. Как-то я реализовавыл этот вариант. Остался тестовый код, может кому пригодится: Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 14:07 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
_spy_ vadiminfoТ.е. тада надо будет написать запросы на соединение даже если главная табла не нужна? А када нужна - тада для этих табл другие view, чтобы избежать этих соединений? А када удаление из дочерних таблов то все то же? Да, все же вариант с каскадной простановкой статусов при логическом удалении главной записи видится более предпочтительным. Если будешь реализовывать через VIEW, то изменение статуса (например атрибут DELETED as DATE_TIME is not NULL), то менять каскадно вообщем-то ничего и не придется. Пользователь просто не увидит этих данных, т.к. они связаны. А вообще-то системе можно разрешить и "удалять" записи. Вызывая в триггере PRE/POST-DELETE либо прекращение операции удаления, с изменением атрибута DELETED (PRE), либо дублирование записи (POST) и удаление оригинальной. Это зависит от выбранной СУБД. Правда обычно добавляют и атрибут DELETED_BY. Единственное с чем соглашусь, есть класс задач (очень маленький и специфичный) где это нужно. А в большенстве случаев можно прожить и без оной задумки... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 14:31 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
nik_xЕсли будешь реализовывать через VIEW, то изменение статуса (например атрибут DELETED as DATE_TIME is not NULL), то менять каскадно вообщем-то ничего и не придется. Пользователь просто не увидит этих данных, т.к. они связаны. Я так понимаю, Вы имеете в виду следующее: если в мастер-таблице есть признак удаления и есть вьюха живых записей, то каскадного логического удаления дочерних записей не потребуется, поскольку пользователь просто "не дойдет" до этих записей по интерфейсу программы. Если так - не согласен. Причина этого очень проста: практически в любой нетривиальной системе существуют бизнес-функции, использующие позиции документа в отрыве от их заголовков. Скажем, отчеты наподобие оборотно-сальдовой ведомости вполне могут быть построены именно таким образом. Соответственно, в этом случае Ваш подход требует притягивания заголовков и проверки в них статуса записи везде, где используются позиции. Что есть неудобно для разработчика, неоптимально для сервера и прежде всего элементарно ненадежно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 14:58 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
softwarerЕсли так - не согласен. Причина этого очень проста: практически в любой нетривиальной системе существуют бизнес-функции, использующие позиции документа в отрыве от их заголовков. Скажем, отчеты наподобие оборотно-сальдовой ведомости вполне могут быть построены именно таким образом. Соответственно, в этом случае Ваш подход требует притягивания заголовков и проверки в них статуса записи везде, где используются позиции. Что есть неудобно для разработчика, неоптимально для сервера и прежде всего элементарно ненадежно. Угу а если физически удалять запись, то нужно следить чтоб везде удалялись хвосты иначе, см выше "в любой нетривиальной системе существуют бизнес-функции..." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 15:05 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
- Да не согласен я. - С кем? С энгельсом или с Каутским? - С обоими, - ответил Шариков. - Это замечательно, клянусь богом. "Всех, кто скажет, что другая..." А что бы вы со своей стороны могли предложить? - Да что тут предлагать?.. А то пишут, пишут... Конгресс, немцы какие-то... Голова пухнет. Взять все, да и поделить... Булгаков. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 15:05 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
EstetsУгу а если физически удалять запись, то нужно следить чтоб везде удалялись хвосты иначе, см выше "в любой нетривиальной системе существуют бизнес-функции..." Если физически удалять запись, то хвосты удалятся каскадом, если нормально схему спроектировать. To Ненавижу регистрацию Спасибо за пример. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 15:49 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
EstetsУгу а если физически удалять запись То во-первых, я выше аргументировал, почему так в большинстве случаев делать нельзя. Во-вторых, внешние ключи в этом случае уберегут от излишней забывчивости всех, кроме следующих Вашему дизайну без constraint-ов. В-третьих же таки Вы правы и именно это я и доказываю: к "хвосту" в любой реальной системе следует относиться тщательно и аккуратно, иначе будут проблемы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 28.03.2006, 17:03 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
softwarerТо во-первых, я выше аргументировал, почему так в большинстве случаев делать нельзя. Во-вторых, внешние ключи в этом случае уберегут от излишней забывчивости всех, кроме следующих Вашему дизайну без constraint-ов. В-третьих же таки Вы правы и именно это я и доказываю: к "хвосту" в любой реальной системе следует относиться тщательно и аккуратно, иначе будут проблемы. Вы за Энгельса будете или за Каутского? ;) Согласен, лишних данных в системе не бывает. У нас физически удаляются только следующие данные: 1) Настройки (метаинформация) - поскольку доступ к ним имеет только администратор и ему и отвечать за внесенные исправления. 2) Агрегированная информация - например расситанные и сохраненные данные для отчетов, т.к. в случае необходимости можно эти данные расчитать еще раз. 3) Информация из внешних источников - опять-же если удаленная информация потребуется вновь, то ее можно будет восстановить. А по поводу "каскадного удаления" vs "каскадного проставления признака неактуальный", то если это делать триггерами затраты на программирование примерно одинаковые. Хотя замечу, что у нас нет каскадного обновления статусов записей, и вполне возможен вариант когда есть актуальный перечень, для неактуалной накладной. НО я ни разу не сталкивался с данной проблемой т.к. связанные перечни обрабатываются в связке с основным документом и проверяется "неудаленность" как позиции в перечне (так как она сама мола быть удалена) так и основного документа. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 11:39 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
_spy_Хотелось бы узнать мнение на тему, кто как организует логическое удаление записей в БД (когда они удаляются на уровне пользователей, но физически продолжают присутствовать в БД) и какие в связи с этим преимущества и недостатки. Сейчас я вижу 2 варианта: 1. Пометка записи на удаление, т.е. введение поля статуса записи. 2. Введение в схему БД дополнительных таблиц для удаленных записей со структурой, совпадающей с оригинальной и перенос туда записей при удалении. Могу предложить третий вариант, этот вариант использовался в банковсой системе которую я 2 года назад обслуживал, а сейчас я его реализовал в своей системе документооборота. Принцип вытекает из второго варианта, но только я не статус записи ввел а время действия документа Date_Begin и Date_End и состояние Пока запись актуальна Date_End = '01.01.2099:00:00:00' при удалении или любом изменении Date_End = Now все изменения делаются только процедурами, так легче и гибче можно отслеживать права. Процедура при любом изменении записи, делает ее копию с новым состоянием (включая все подчиненные таблицы) и проставляет даты начала конца. Этот подход позволяет видеть данные на любой момент времени, обеспечивает непротиворечивость отчетности со временем, ну и естественно всю историю изменений. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 12:19 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
To nnov Спасибо за вариант. В принципе, такая подробная "историчность" и версионность данных не требуется. Однако поле с датой удаления - это нужная информация, тем более, что я думаю как раз на поле с датой удаления расширять уникальные ключи. Кроме того, думаю сделать отдельную таблицу дополнительной информации об удаленных объектах, где будут поля ID объекта Тип объекта Пользователь, удаливший запись Причина удаления Эта таблица не будет использоваться при работе обычных пользователей, она будет доступна только пользователям, имеющим доступ к удаленным записям. Таким образом, получается где-то комбинированный подход - с одной стороны для логического удаления используется статус, с другой стороны, есть отдельная таблица с дополнительной информацией об удаленных объектах. Хотелось бы узнать мнения... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 13:19 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
Кстати,по поводу таблички с дополнительными сведениями: у меня есть режим работы (фактически роль) "Разрешение работы с указанием причины". Суть вот в чем:иногда кто-то кого-то заменяет при уходе в отпуск,но ходить под чужим паролем неверно и всегда давать такую роль тоже не верно.На период отпуска человека новому дается вышеуказанный режим работы на необходимые объекты. При выполнении каких-либо действий система предупреждает человека об опасности его действий и спрашивает,готов ли он продолжить.Если готов,то просит ввести причину этих действий (обычный текст),который пишется в аналогичную табличку с доп.сведениями.Если потом работа проверяется и в причине удаления всех счетов контрагента причина пишется как "А пошли вы все в *?;№№№#$",то ему вламывают. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 13:53 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
nnovПока запись актуальна Date_End = '01.01.2099:00:00:00' Ага, а потом говрят про боязнь 2000 года (в вашем случае будет 2100 год), тогда уж лучше это поле NULL оставлять или ну хотя бы 2999 год ставить... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 13:59 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
basАга, а потом говрят про боязнь 2000 года (в вашем случае будет 2100 год), тогда уж лучше это поле NULL оставлять или ну хотя бы 2999 год ставить... Хотел бы я писать программы, которые работали бы хотябы до 2099 года)) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 14:20 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
bas Ага, а потом говрят про боязнь 2000 года (в вашем случае будет 2100 год), тогда уж лучше это поле NULL оставлять или ну хотя бы 2999 год ставить... А можно привести пример программы которая проработала хотя-бы 20 лет А вот NULL ни в коем случае нельзя, потому как все данные показываются с фильтром "текущая дата" > Date_Begin and "текущая дата" < Date_End ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 14:28 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
nnovА можно привести пример программы которая проработала хотя-бы 20 лет Сколько угодно и гораздо больше. Например, поставь Windows XP, загляни в каталог %WINDIR%\system32 и увидишь там файлик edlin.exe, в котором с 85-го года вряд ли поменялся хотя бы один байт. nnovА вот NULL ни в коем случае нельзя, Как раз NULL там и нужен. nnovпотому как все данные показываются с фильтром "текущая дата" > Date_Begin and "текущая дата" < Date_End То есть Вы предлагаете из-за кривого следствия сообразно уродовать причину. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 15:41 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
softwarerСколько угодно и гораздо больше. Например, поставь Windows XP, загляни в каталог %WINDIR%\system32 и увидишь там файлик edlin.exe, в котором с 85-го года вряд ли поменялся хотя бы один байт. Самому то не смешно... softwarer Как раз NULL там и нужен. И зачем же он там, просветите, что вы получети при его использовании кроме гемороя. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 16:03 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
nnovИ зачем же он там, просветите, что вы получети при его использовании кроме гемороя. Если коротко, то отсутствие геморроя. Например, легко и просто различаются открытые и закрытые периоды, код становится легко читаемым и не содержит магических констант. Главное же - код становится надежнее; я на практике чужого большого проекта, доставшегося мне на поддержку, убедился, что ошибки "обработки магических констант как обычных" гораздо чаще проходят сквозь тестирование и приводят к гораздо более неприятным последствиям, нежели отсутствие особой обработки null-а там, где она нужна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 17:25 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
softwarerЕсли коротко, то отсутствие геморроя. Например, легко и просто различаются открытые и закрытые периоды, код становится легко читаемым и не содержит магических констант. Главное же - код становится надежнее; я на практике чужого большого проекта, доставшегося мне на поддержку, убедился, что ошибки "обработки магических констант как обычных" гораздо чаще проходят сквозь тестирование и приводят к гораздо более неприятным последствиям, нежели отсутствие особой обработки null-а там, где она нужна. Про какие магические константы идет речь не понял, в поле проставляется дата-время, и в плане обработки это гораздо лучше, NULL вообще имеет много минусов, нельзя сравнивать и производить вычисления, неэффективная индексация (а внекоторых СУБД вообще низя). А в данном конкретном случае будет вообще двойная работа. При построеной мною схеме, я всегда и везде подставляю одинаковое условие Date_Begin < DATETIME < Date_End причем по умолчанию подставляется текущее датавремя, а если нужно получить отчет на 10.07.2004 то просто указываем дату, и я не меняя никаких запросов процедур и т.д. в тойже логике получаю срез документов на указаную дату. Если бы стоял NULL нужно усложнять запросы при обращении к прошлым периодам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.03.2006, 17:38 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
Может будет интересно... Про даты и версии. Сначало о терминологии. Версионность - возможность видеть объект (запись, группу записей) на момент времени отличный от текущего, как правило, в прошедшем времени. Логирование - возможность видеть кем, когда и как объект был изменен (удален, добавлен). Теперь применительно к данным. Исходя из бизнес-требований и т.п. к нужным объектам применяем соответствующее решение. К примеру, к таким объектам как документы (меняют свой статус в бизнес-процессе), информация о юр.,физ. лице, приминительна версионность. К объектам попроще, где версионность не нужна, но есть вероятность доступа к ним "кривых рук", а достоверность их важна, и порой трудно найти крайнего, применяется логирование. Возможно прменение и версионности и логирования к одному объекту. Немного о реализации. Есть таблица с основными данными, есть с версионными. Таблица с версионными данными имеет поле с датой актуальности этих данных. Для версионного объекта, версия создается в момент сохранения (нового, редактируемого) объекта. Для объекта, имеющего ссылку на версионный, реализация может быть сделана одним из двух способов, опять же, в зависимости от требований. Это 1 - выбор версии при сохранении объекта, либо 2 - выбор версии, при просмотре объекта. Как пример, версионный объект "Юр.лицо" в документе (ссылка на юр.лицо из документа). В первом случае, мы всегда будем видеть документ, таким-каким он был. Логирование, это лишь теневая таблица, в которой регистрируются все изменения, плюс информация о том, кто когда и откуда их сделал. Касаемо темы, про удаление. В зависимости от требований, реализуется соответствующим способом. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 15:37 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
> Есть таблица с основными данными, есть с версионными. Алгоритм разделения данных на основные и версионные - в студию. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 16:06 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
Полностью согласен с PridobreY: у меня алгоритм чисто эмпирический-спрашиваю у пользователя,нужна ли им история для возможности отката или отчетности (за прошлые периоды),или только для битья по рукам. Пример: справочник видов ЦБ - за него бьют по рукам. Картотека клиентов-версионная. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 16:22 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Есть таблица с основными данными, есть с версионными. Алгоритм разделения данных на основные и версионные - в студию. Это не алгоритм. Это проектирование. Простой пример. Контрагент. Основные - ПК (перв.ключ) Внутренний код Краткое наименование Версионные - ПК ПК_Осн. Дата актуальности Полное название Тип (ОАО, ЗАО,....) и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 16:23 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
> Это не алгоритм. Это проектирование. Уважаемый, Вы буквосочетаниями для какой цели изъясняетесь? Вопрос был абсолютно конкретный. > Простой пример Мне не примеры нужны (тем более примеры с ошибками), а алгоритм. На основании чего и как делается вывод об "обычности" данных и "версионности"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 17:30 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Это не алгоритм. Это проектирование. Уважаемый, Вы буквосочетаниями для какой цели изъясняетесь? Вопрос был абсолютно конкретный. > Простой пример Мне не примеры нужны (тем более примеры с ошибками), а алгоритм. На основании чего и как делается вывод об "обычности" данных и "версионности"? 1. Где в примерах ошибки? 2. Если Вас интересует алгоритм проектирования, пожалуйста. Если значение атрибута (свойство) объекта может изменяться с течением времени, и нужно на конкретную дату видеть его таким, каким оно было на эту дату, тогда версионный атрибут, если оно не изменяется, или его изменение не влияет на бизнесправила, тогда простой. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 17:47 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
> Если значение атрибута (свойство) объекта может изменяться > с течением времени А теперь расскажите, какие атрибуты не могут изменяться с течением времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 19:03 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Если значение атрибута (свойство) объекта может изменяться > с течением времени А теперь расскажите, какие атрибуты не могут изменяться с течением времени. ЕГРН например... да мало ли... дата регистрации, дата рождения... и, уж наверняка, дата смерти... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 19:10 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Если значение атрибута (свойство) объекта может изменяться > с течением времени А теперь расскажите, какие атрибуты не могут изменяться с течением времени. Уважаемый guest_20040621, не нужно выдергивать фразу из предложения, и задавать по ней вопрос. Если Вас что-то по данной теме интересует, формулируйте вопрос конкретней, а не разводите полемику. p.s. с течением времени, не может изменитсья, к примеру, дата рождения (исключая ошибочный ввод) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 19:19 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
> Если Вас что-то по данной теме интересует Дружище, сильно вряд ли Вы скажете что-то такое, чего я бы не знал. > формулируйте вопрос конкретней Некуда конкретней. > а не разводите полемику Т. е. Вам ахинею нести можно, а мне вопросы задавать нельзя? > с течением времени, не может изменитсья, к примеру, дата рождения > (исключая ошибочный ввод) Неправда. Никто не может гарантировать, что через год не введут биометрические карты и дата рождения будет фиксироваться с точностью до минуты или секунды. Еще варианты? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 19:33 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
guest_20040621Неправда. Никто не может гарантировать, что через год не введут биометрические карты и дата рождения будет фиксироваться с точностью до минуты или секунды. И каким именно образом это сделает эти данные версионными? Ну и заодно любопытно было бы посмотреть на машину времени, которая определит эти данные например для меня :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 19:42 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
guest_20040621Дружище, сильно вряд ли Вы скажете что-то такое, чего я бы не знал. От чего такая уверенность? guest_20040621Т. е. Вам ахинею нести можно, а мне вопросы задавать нельзя? И где я нес ахинею? Хотя Вам никто не запрещает... guest_20040621Неправда. Никто не может гарантировать, что через год не введут биометрические карты и дата рождения будет фиксироваться с точностью до минуты или секунды. Еще варианты? Читайте выше "Исходя из бизнес-требований..." ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 19:44 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
softwarer guest_20040621Неправда. Никто не может гарантировать, что через год не введут биометрические карты и дата рождения будет фиксироваться с точностью до минуты или секунды. И каким именно образом это сделает эти данные версионными? Ну и заодно любопытно было бы посмотреть на машину времени, которая определит эти данные например для меня :) А вдруг изобретут! И будут разные релизы этой машины, и надо будет править дату, после каждого релиза, и хранить эту историю :) ) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 19:47 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
> И каким именно образом это сделает эти данные версионными? Никаким, естественно. В данном случае меняться будут не данные, а метаданные. В контексте вопроса - версионность будет у метаданных, а не у данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 19:47 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
> Читайте выше "Исходя из бизнес-требований..." Что это за алгоритм "бизнес-требование"? Своими словами, пожалуйста. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 19:49 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
PridobreYА вдруг изобретут! И будут разные релизы этой машины, и надо будет править дату, после каждого релиза, и хранить эту историю :) ) Это уже другая сущность. Не атрибут "дата рождения" в сущности "человек", а атрибут "измеренная дата" в сущности "результаты экспериментов по измерению дат рождения". guest_20040621> И каким именно образом это сделает эти данные версионными? Никаким, естественно. В данном случае меняться будут не данные, а метаданные. В контексте вопроса - версионность будет у метаданных, а не у данных. OK, давайте посмотрим контекст вопроса. guest_20040621 > Если значение атрибута (свойство) объекта может изменяться > с течением времени А теперь расскажите, какие атрибуты не могут изменяться с течением времени. Итак, судя по всему, Вы отождествляете понятия "значение атрибута (свойство)" и "метаданные"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 19:51 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Читайте выше "Исходя из бизнес-требований..." Что это за алгоритм "бизнес-требование"? Своими словами, пожалуйста. Бизнес-требования это не алгоритм, а документ, который содержит информацию (требования к бизнес-процессам в частности.), используемую при проектировании информационной системы. softwarerЭто уже другая сущность. Не атрибут "дата рождения" в сущности "человек", а атрибут "измеренная дата" в сущности "результаты экспериментов по измерению дат рождения". Согласен. В моем случае, должна быть версионной сущность "человек", с версионным атрибутом "точная дата рождения". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 20:06 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
> Вы отождествляете понятия "значение атрибута (свойство)" и "метаданные"? Нет. Контекст - [2507333]. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 20:12 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
> Бизнес-требования это не алгоритм, а документ Т. е. любая бумажка - основание для разделения данных на "обычные" и "версионные"? ;))) Я бы на вопрос ответил таким образом: постоянными можно считать независимые (степень независимости можно обсуждать) данные, точность измерения (или область значений) которых заранее известна (либо известен алгоритм их получения) и единицы измерения - стандартны. Все остальные данные - увы - по своей природе версионны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 20:27 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
Страховое свидетельство (Пенсионного фонда) подлежит обмену в случаях: Изменения фамилии, имени, отчества, ДАТЫ РОЖДЕНИЯ, МЕСТА РОЖДЕНИЯ или поля застрахованного лица; установления неточности или ошибочности содержащихся в нем сведений. (с) Написано это на зеленой карточке, которая есть у каждого. Причем если ошиблись в дате рождения при составлении свидетельства, то это попадает под "установления неточности или ошибочности содержащихся в нем сведений" Осюда логически заключаем, что дату рождения поменять можно! Убили веру в константы на корню! :-))))))) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 21:28 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
Гость74Страховое свидетельство (Пенсионного фонда) подлежит обмену в случаях: Изменения фамилии, имени, отчества, ДАТЫ РОЖДЕНИЯ, МЕСТА РОЖДЕНИЯ или поля застрахованного лица; установления неточности или ошибочности содержащихся в нем сведений. (с) Написано это на зеленой карточке, которая есть у каждого. Причем если ошиблись в дате рождения при составлении свидетельства, то это попадает под "установления неточности или ошибочности содержащихся в нем сведений" Осюда логически заключаем, что дату рождения поменять можно! Убили веру в константы на корню! :-))))))) это потому, что такой важный вопрос как поддержание целостности и непротиворечивости данных отдали на откуп профанам и делетантам из МинЗдрава, конечно они такого нагородили... даже ежу понятно и очевидно, что неточности при указании в даты рождения должны устраняться ТОЛЬКО СТОРНИРОВАНИЕМ неточности места указания места рождения устраняются сторнированием даты рождения (возраста) до нуля, с последующим вводом нового места рождения и фиксироваться соответсвующей проводкой по счетам родильного дома... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 21:41 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Бизнес-требования это не алгоритм, а документ Т. е. любая бумажка - основание для разделения данных на "обычные" и "версионные"? ;))) Я бы на вопрос ответил таким образом: постоянными можно считать независимые (степень независимости можно обсуждать) данные, точность измерения (или область значений) которых заранее известна (либо известен алгоритм их получения) и единицы измерения - стандартны. Все остальные данные - увы - по своей природе версионны. Отвечать можно по разному. Бизнес-требования это не любая бумажка, это требования к информационной системе, предъявляемые заказчиком, либо сформированными на основе анализа функций проектируемой системы. В разных проектах, системах один и тот же объект (сущность), набор его атрибутов (свойств) может быть в одном случае постоянным, в другом версионным. Так же, как и кол-во атрибутов объекта. Где-то достаточно названия организации, где-то нужна более детальная информация (адреса, счета и т.п.). Всё зависит от требований к системе (автоматизируемой системы). guest_20040621степень независимости можно обсуждать Делается это на этапе анализа. guest_20040621Все остальные данные - увы - по своей природе версионны Это не значит, что в каждой системе нужно поддерживать версионность этих данных. Всё нужно в меру. Никому не нужной функциональностью, лишь можно навредить. В случае организации версионности, это дополнительные расходы для хранения информации, вычислительной мощности, обработки информации и поддержки реализуемого функционала. p.s. Эта любовь к алгоритмам неспроста... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 22:16 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Вы отождествляете понятия "значение атрибута (свойство)" и "метаданные"? Нет. Контекст - [2507333]. Это часть контекста. Как и более свежие цитаты, приведенные мной. Впрочем, и в указанном контексте я что-то не заметил упоминаний о метаданных, зато есть фразы: Версионность - возможность видеть объект (запись, группу записей) на момент времени отличный от текущего, К примеру, к таким объектам как документы (меняют свой статус в бизнес-процессе), Таблица с версионными данными имеет поле с датой актуальности этих данных. Для версионного объекта, версия создается в момент сохранения (нового, редактируемого) объекта. вполне явно показывающие, что речь идет о версионности "обычных данных". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 22:22 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
> вполне явно показывающие, что речь идет о версионности "обычных > данных". Ключевое слово "объект". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 23:13 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
> Бизнес-требования это не любая бумажка Знаете, т. н. "бизнес-требования" - тупой термин, придуманный тупыми маркетологами, который в общем случае не несет никакой смысловой нагрузки. Делит пальму первенства по тупости с термином "бизнес-логика". > требования к информационной системе, предъявляемые заказчиком Вы сами вспомните, как называется этот документ? ;) Ни при чем здесь никакие "бизнес-требования". > либо сформированными на основе анализа функций проектируемой системы. ;))) > В разных проектах, системах один и тот же объект (сущность) Дружище, термин "объект" в общем случае не имеет ничего общего с термином "сущность". Вы о чем говорите и что имеете в виду? > В случае организации версионности, это дополнительные расходы Очень незначительные. В любом смысле. > Эта любовь к алгоритмам неспроста Нет никакой любви. Если беретесь что-то формулировать, делайте это нормальным образом. Если оперируете определениями - ссылайтесь на источник. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 23:27 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
nnovПока запись актуальна Date_End = '01.01.2099:00:00:00' запись актуальна если нет замещающей ее записи. Иначе при вводе новой записи требуется дополнительная логика по замене данных в записях, которые становятся неактуальными. А при отмене - откат назад, восстановление предыдущего состояния. Хорошо когда это одна запись... и нечем заняться... Так и рождаются монстры с гемморойной логикой. Типичный пример курсы валют: Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 23:38 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
guest_20040621Ключевое слово "объект". После которого в скобках указано, что именно понимается под "объектом". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 23:40 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
iscrafmзапись актуальна если нет замещающей ее записи. Нельзя ли описать, какую именно "замещающую ее запись" Вы бы внесли в реестр недвижимости Нью-Йорка 11 сентября небезызвестного года? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 23:43 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
softwarer iscrafmзапись актуальна если нет замещающей ее записи. Нельзя ли описать, какую именно "замещающую ее запись" Вы бы внесли в реестр недвижимости Нью-Йорка 11 сентября небезызвестного года? в данном контексте Код: plaintext 1. 2. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 23:54 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
только к замещающим записям это не имеет отношение. Если бы WTC переехал, тогда запись бы была другой ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 30.03.2006, 23:57 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
> После которого в скобках указано, что именно понимается под "объектом". Спасибо, я умею читать; все сказанное в силе. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2006, 00:12 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
iscrafmНельзя ли описать, какую именно "замещающую ее запись" Вы бы внесли в реестр недвижимости Нью-Йорка 11 сентября небезызвестного года? в данном контексте Код: plaintext 1. 2. Стоп-стоп-стоп. Прежде всего, я что-то не вижу здесь внесения замещающей записи - следовательно, "актуальная запись" продолжает существовать. Зато я вижу здесь факт "неверсионного изменения" - нигде не указано, что статус сменился именно 11.09. Практически Вы потеряли информацию. iscrafmтолько к замещающим записям это не имеет отношение. Хм. Тут уже вопросы к Вашей формулировке. Вы сказали, "запись перестает быть актуальной..." Я привел пример события, при котором запись явно перестала быть актуальной. Если эта ситуация решается другим способом - значит, Ваша формулировка неполна. В целом, Ваш подход безусловно заслуживает большой медали Общества Любителей Нормализованных БД. Но на практике он имеет и свойственные нормализации недостатки; например, любой запрос, в котором требуется вывести период действия значения, без аналитических функций нормально не расписывается (собственно, в ANSI SQL, если не ошибаюсь, такой запрос вообще НЕ УДАСТСЯ написать). ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2006, 00:29 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
guest_20040621> Бизнес-требования это не любая бумажка Знаете, т. н. "бизнес-требования" - тупой термин, придуманный тупыми маркетологами, который в общем случае не несет никакой смысловой нагрузки. Делит пальму первенства по тупости с термином "бизнес-логика". одни буквы... guest_20040621> требования к информационной системе, предъявляемые заказчиком Вы сами вспомните, как называется этот документ? ;) Ни при чем здесь никакие "бизнес-требования". > либо сформированными на основе анализа функций проектируемой системы. ;))) Это называется "Постановка задачи", на основаниии которой пишется "Техническое задание". Интересно, как Вы сами проектируете и разрабатываете системы, без подобного документа. В его отсутствии или присутствии в виде формальности (неточности трактований требований), растет кол-во требований, переодически противоречащих предыдущим, время разработки проекта стремится к бесконечности, а сам исполнитель начинает нести убытки. Я говорю о достаточно больших проектах. guest_20040621> В разных проектах, системах один и тот же объект (сущность) Дружище, термин "объект" в общем случае не имеет ничего общего с термином "сущность". Вы о чем говорите и что имеете в виду? И какие это такие, общие случаи? Тот кто хотел, понял что я имел ввиду. В скобках уточнение.. guest_20040621> В случае организации версионности, это дополнительные расходы Очень незначительные. В любом смысле. Это Вы заказчику пропойте. :) А как эксплуатация начнется, послушайте их. guest_20040621> Эта любовь к алгоритмам неспроста Нет никакой любви. Если беретесь что-то формулировать, делайте это нормальным образом. Если оперируете определениями - ссылайтесь на источник. Зачем кудато ссылаться, если сказано что под термином имеется ввиду. p.s. Кроме Ваших, необоснованных реплик, по существу темы ничего и не слышно. Конструктивней надо. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2006, 00:52 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
softwarer Стоп-стоп-стоп. Прежде всего, я что-то не вижу здесь внесения замещающей записи - следовательно, "актуальная запись" продолжает существовать. Зато я вижу здесь факт "неверсионного изменения" - нигде не указано, что статус сменился именно 11.09. Практически Вы потеряли информацию. ниже написал, что к замещающим записям это не имеет отношение. Впрочем Вы сами думаю увидели следующее сообщение. А насчет версионности :) Лень мне было дописывать еще set-ы, думал сами догадаетесь. Никакая информация конечно же не теряется. softwarer В целом, Ваш подход безусловно заслуживает большой медали Общества Любителей Нормализованных БД. Спасибо за медаль А что такое нормализованная БД? Шутка. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2006, 01:19 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
> И какие это такие, общие случаи? Н-да... одно непонятно: почему Вы имеете наглость что-то кому-то объяснять. Дружище, на Вашем месте я бы молчал и слушал. Вы вообще что-нибудь о проектировании читали? > Тот кто хотел, понял что я имел ввиду. В скобках уточнение. ;)) Чего уточнение? Термина "объект"? Не смешите мои тапочки. > Зачем кудато ссылаться, если сказано что под термином имеется ввиду. Дружище, Вы разговариваете набором букв, Вы это понимаете? "Объект" имеет вполне себе конкретный смысл, а вот "запись" - это Ваша отсебятина, которая вообще ничего общего с проектированием не имеет. Что с помощью чего Вы уточнили? Читайте больше, что-ли... > по существу темы ничего и не слышно. Очень даже слышно. Вы написали абсолютную хрень, я Вам рассказал, почему это так. Чего более конкретного Вы хотите? Учитесь, молодой человек; не пишите ахинеи; не давайте глупых советов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2006, 12:20 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
guest_20040621> И какие это такие, общие случаи? Н-да... одно непонятно: почему Вы имеете наглость что-то кому-то объяснять. Дружище, на Вашем месте я бы молчал и слушал. Вы вообще что-нибудь о проектировании читали? > Тот кто хотел, понял что я имел ввиду. В скобках уточнение. ;)) Чего уточнение? Термина "объект"? Не смешите мои тапочки. > Зачем кудато ссылаться, если сказано что под термином имеется ввиду. Дружище, Вы разговариваете набором букв, Вы это понимаете? "Объект" имеет вполне себе конкретный смысл, а вот "запись" - это Ваша отсебятина, которая вообще ничего общего с проектированием не имеет. Что с помощью чего Вы уточнили? Читайте больше, что-ли... > по существу темы ничего и не слышно. Очень даже слышно. Вы написали абсолютную хрень, я Вам рассказал, почему это так. Чего более конкретного Вы хотите? Учитесь, молодой человек; не пишите ахинеи; не давайте глупых советов. Ни такой уж я и молодой, а Вам, тем более не дружище. Хрень идет только от Вас, и ничего путного Вы не сказали. Если Вам не нравится терминология, предложите совю правильную модераторам, для публикации в правилах форума. p.s. И не забудьте про "тупых" маркетологов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2006, 12:42 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
> Ни такой уж я и молодой Тем более должно быть стыдно. > Если Вам не нравится терминология Мне, уважаемый, терминология нравится. Не нравится, когда вместо стандартной используют доморощенную. > предложите совю правильную модераторам Консультации, чтение вслух стандартов, - на возмездной основе. > И не забудьте про "тупых" маркетологов. А что с ними не так? P.S. Про не-дружищ оригинален был товарищ Выбегалло. Жаль, давненько его не слышно. ;) Амвросий Амбруазович, хватит дуться. ;) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 31.03.2006, 14:49 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
и зачем так сложно когда делается это просто Код: plaintext iscrafm nnovПока запись актуальна Date_End = '01.01.2099:00:00:00' запись актуальна если нет замещающей ее записи. Иначе при вводе новой записи требуется дополнительная логика по замене данных в записях, которые становятся неактуальными. А при отмене - откат назад, восстановление предыдущего состояния. Хорошо когда это одна запись... и нечем заняться... Так и рождаются монстры с гемморойной логикой. Типичный пример курсы валют: Код: plaintext 1. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2006, 00:15 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
затем, что не нужно делать никаких изменений кроме добавления новой записи. Попробуйте :) Проверено. Алгоритмы должны быть просты и прозрачны. Дата окончания действия курса - лишнее. p.s. Каждый день надеюсь не будете менять "< endrdate ". Успехов! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2006, 00:24 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
В продолжении темы. Проектировать БД можно по правилам, можно без правил, а можно "под потребности". Задавал вопрос уважаемый softwarer : " например, любой запрос, в котором требуется вывести период действия значения, без аналитических функций нормально не расписывается ". Ответ на него прост. Нужно смотреть на назначение БД. Приведенный выше вопрос можно поставить по другому. А зачем мне такая аналитика нужна? Да, меня интересует конкрентный документ, но совсем не интересует с какого и по какое он действовал. Гораздо более востребованная информация - действовал ли документ в заданный период. А если нужно построить временные ряды, то ничто не мешает потратить немного времени и расчитать их при помощи процедуры, так как его востребованность гораздо ниже. А еще лучше показать все это в кубе или в графике. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 01.04.2006, 00:36 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
Наилучший вариант хранения данных - при помощи пары дат - дата начала, дата окончания действия. Если использовать только одну дату, то значительно повышается сложность извлечения данных на определенную дату. Я после некоторого анализа когда проектировалась наша биллинговая система выбрал именно вариант с двумя датами. Причем было два типа версионных таблиц - 1. Содержащие большое количество атрибутов, которые редко относительно изменяются. В этом случае в таблицу просто добавляются dton,dtoff и соответствующим образом оформляются все запросы, обращающиеся к этой таблице. 2. Содержащие атрибуты, которые часто меняются. И, кроме того, нужно знать индививдуально какой атрибут с какой по какую дату имеет/имел такое значение. В этом случае в таблице храниться код_атрибута, датаот, датапо, значение, ну и может какие то еще атрибуты как то кто и когда изменял и пр. Такой же подход встречал в некоторых других серьезных коммерческих продуктах. В принципе, все версионные данные желательно хранить в таблицах второго типа - получается более универсальнее и правильнее. Но возникают например трудности на уровне описания ER-диаграм БД - они получаются очень непоказательными. Подумывал над созданием некой надстройки в БД для хранения всех версионных (кстате, думаю правильней их называть историческими) данных - например, завести таблицу, содержащую 1. код категории (к какой таблице принадлежали бы эти данные, будь они оформлены неисторическими), 2. код подраздела (код атрибута), 3 и 4. дата от, дата по, 5. значение (может быть серия значений разных типов, или применение каких-либо объектно-ориентированных возможностей БД для хранения значений разных типов). 6. Поля описывающие кто, 7. и когда менял Далее завести определенный уровень абстракции операций над историческими данными - добавление, удаление, изменение. В принципе, у меня уже есть определенные наработки, но сейчас ломать всю систему под это уже тяжело. Версионные данные в нашей системе хранятся в таблицах типа 1 и 2, как описано выше. Проблемы с производительностью могут решаться правильным секционированием и субсекционированием таблиц и настройке соответствующим образом фраз хранения для каждой партиции, в соответствиии с характером тех или иных данных. Думаю, в очень крупных информационных системах (1000 и больше сущностей) такой или похожий уровень абстракции должен быть сделан обязательно - трудности при проектировании (если правильно все сделать, они не такие уж и большие) потом с лихвой окупятся при эксплуатации и развитии системы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 10.04.2006, 19:08 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
Несколько примеров из Oracle E-Buisness Suite. 1. Использование дат. Таблица, содержащая список пользователей. 2 поля start_date и end_date , допускающие NULL-евые значения. Значение NULL означает неограниченность интервала в соответсвующую сторону. 2. Использование логического и физического удаления. Таблицы, хранящие информацию о формулах (производство). Заголовки формул -< Детали формул. В родительской таблице есть поле delete_mark принимающее значения 0 или 1. В детальной таблице записи удаляются физически без возможности восстановления. 3. Версионность объектов. Таблица, содержащая местоположения (locations). При внесении изменений в данные, пользователю предлагается возможность сохранить изменения в эту же запись, либо создать новую версию записи (используется поле object_version_number ) В дополнение ко всему, все таблицы содержат 4 WHO-столбца creation_date , created_by , last_update_date , last_updated_by P.S. Мое мнение, что все описанное в данной теме имеет право на существование и зависит от условия задачи. With Best Regard. Sam. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 10:54 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
sam11Несколько примеров из Oracle E-Buisness Suite. 1. Использование дат. Таблица, содержащая список пользователей. 2 поля start_date и end_date , допускающие NULL-евые значения. Значение NULL означает неограниченность интервала в соответсвующую сторону. Есть и такой вариант в OEBS: Таблица PER_ALL_PEOPLE_F (список сотрудников) имеет поля EFFECTIVE_START_DATE и EFFECTVE_END_DATE. Последний столбец содержит либо реальную дату, либо 31.12.4712 Думаю, что в OEBS при желании можно найти самые причудливые реализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 11:26 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
sam11Несколько примеров из Oracle E-Buisness Suite. 1. Использование дат. Таблица, содержащая список пользователей. 2 поля start_date и end_date , допускающие NULL-евые значения. Значение NULL означает неограниченность интервала в соответсвующую сторону. Есть и такой вариант в OEBS: Таблица PER_ALL_PEOPLE_F (список сотрудников) имеет поля EFFECTIVE_START_DATE и EFFECTVE_END_DATE. Последний столбец содержит либо реальную дату, либо 31.12.4712 Думаю, что в OEBS при желании можно найти самые причудливые реализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 11.04.2006, 11:28 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
Ну ведь HR - это не исконно Оракловые модули. И вообще, HR, очень сильно отличается от остального. Я, кстати, такой вариант (с "магическими" константами) считаю плохим. With Best Regards. Sam. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 12.04.2006, 12:15 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
iscrafm nnovПока запись актуальна Date_End = '01.01.2099:00:00:00' запись актуальна если нет замещающей ее записи. Иначе при вводе новой записи требуется дополнительная логика по замене данных в записях, которые становятся неактуальными. А при отмене - откат назад, восстановление предыдущего состояния. Хорошо когда это одна запись... и нечем заняться... Так и рождаются монстры с гемморойной логикой. Типичный пример курсы валют: Код: plaintext 1. а если нужно весь справочник на дату вернуть (т.е. curid in (all records)) - курсором побежим?.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 14:02 |
|
||
|
Логическое удаление записей
|
|||
|---|---|---|---|
|
#18+
Sgt.Pepperа если нужно весь справочник на дату вернуть (т.е. curid in (all records)) - курсором побежим?.. :) конечно же нет, построим запрос по другому ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 19.05.2006, 19:10 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1545242]: |
0ms |
get settings: |
10ms |
get forum list: |
22ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
163ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
137ms |
get tp. blocked users: |
2ms |
| others: | 201ms |
| total: | 556ms |

| 0 / 0 |
