powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Логическое удаление записей
81 сообщений из 81, показаны все 4 страниц
Логическое удаление записей
    #33621738
_spy_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Хотелось бы узнать мнение на тему, кто как организует логическое удаление записей в БД (когда они удаляются на уровне пользователей, но физически продолжают присутствовать в БД) и какие в связи с этим преимущества и недостатки. Сейчас я вижу 2 варианта:
1. Пометка записи на удаление, т.е. введение поля статуса записи.
2. Введение в схему БД дополнительных таблиц для удаленных записей со структурой, совпадающей с оригинальной и перенос туда записей при удалении.
По 1-му подходу я вижу следующие недостатки: некоторое увеличение времени запросов к данным, т.к. приходится отфильтровывать "удаленные" записи, а также усложнение в случае наличия уникальных ключей, когда значение ключа занимается удаленной записью и не может быть использовано в актуальной, т.е. ключ надо расширять на 2 поля.
По 2-му подходу недостаток - в усложнении структуры данных и усложнении операции логического удаления (нужно помнить, что если у записи есть ссылки в дочерних таблицах, то их тоже нужно переносить в соответствующие зеркальные таблицы удаленных записей).
Кто поделится мыслями или опытом по данной проблеме?
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33621875
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
При наличии статусного поля время можно сделать практически неизменным с помощью партиционирования. Хотя не факт, что стоит так делать - имхо это зависит в первую очередь от ожидаемой пропорции актуальных и удаленных записей. Делая партиционирование по статусу, мы ускоряем select за счет торможения delete-а.

Второй вариант - максимум, можно рассматривать как решение там, где нет партиционирования. Хотя все равно некрасиво.

Логику работы с дочерними записями в любом случае придется тщательно прописывать. Даже при простановке статуса он же должен быть каскадно проставлен зависимым записям итп.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33622553
_spy_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerДаже при простановке статуса он же должен быть каскадно проставлен зависимым записям итп
Ну как вариант не ставить статус для зависимых, а действовать в зависимости от статуса главной записи - например написать соответствующие view.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33622563
Estets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_spy_ softwarerДаже при простановке статуса он же должен быть каскадно проставлен зависимым записям итп
Ну как вариант не ставить статус для зависимых, а действовать в зависимости от статуса главной записи - например написать соответствующие view.
Такой вариант у нас часто используется, единственная проблема не забывать делать проверку везде, где обрабатывается перечень.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33622584
_spy_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
EstetsТакой вариант у нас часто используется, единственная проблема не забывать делать проверку везде, где обрабатывается перечень.
Ну как раз если организовать все запросы через фильтрующее представление, то эта проблема обходится
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33622854
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_spy_Ну как вариант
Обратите внимание на основную фразу: логику обработки зависимостей в любом случае придется тщательно прописывать. Как именно - отдельный обсуждаемый вопрос.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33622890
_spy_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerОбратите внимание на основную фразу: логику обработки зависимостей в любом случае придется тщательно прописывать. Как именно - отдельный обсуждаемый вопрос.
Согласен, поэтому в том моем посте я цитировал только вашу фразу насчет реализации этой логики
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33623849
Серега
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
А зачем хранить "удаленные" записи? Если хранить их без взаимосвязей, то разобраться в них будет просто невозможно. Если со связями, то вполне могут возникнуть взаимные коллизии.
ИМХО.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33623912
_spy_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Удаленные данные хранятся для анализа и статистики (а также на случай возможного восстановления). Т.е. они могут быть недоступны обычным пользователям, которые будут считать, что данные удалены, но доступны привилегированным пользователям, которые смогут видеть всю историю и строить статистические отчеты.
В том-то и дело, что при логическом удалении должны сохраняться все взаимосвязи.
Хотелось бы услышать попдробнее насчет возможных взаимных коллизий.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33623973
Серега
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_spy_Хотелось бы услышать попдробнее насчет возможных взаимных коллизий.
Была группа товара "Автомобили". Удалили все товары этой группы, а саму группу переименовали в "Лифчики". Можно так? Почему нет? Вот и увидит превилигированный пользователь в "Лифчиках" "ВАЗ-2110". Оно надо? А если подобная практика достаточно часта, то он там и "Гематоген" может увидеть и "черта лысого". Разбираться заморишся.
И это самая простая (одноступенчатая) коллизия.

Я помню, пробовал заниматься такой же вещью. За год работы ни разу этим не воспользовался, зато объем "логов" стал почти на порядок больше данных. Прибил, ибо нафик не надо. Может кроме случаев, оговоренных в законодательсве.

Мусор надо выкидывать, ИМХО.

А восстанавливать нужно из бэкапов, которые делать регулярно автоматом.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33624022
_spy_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
авторБыла группа товара "Автомобили". Удалили все товары этой группы, а саму группу переименовали в "Лифчики". Можно так? Почему нет? Вот и увидит превилигированный пользователь в "Лифчиках" "ВАЗ-2110". Оно надо? А если подобная практика достаточно часта, то он там и "Гематоген" может увидеть и "черта лысого". Разбираться заморишся.
Ну это все решается на уровне бизнес-логики приложения. Переименовать можно и при наличии записей в группе, тогда ВАЗ в "Лифчиках" увидят все пользователи. А можно сделать так, что при удалении всех записей в группе автоматом удаляется и сама группа. Подразумевается все ж таки, что семантика групп не меняется, если говорить только о коллизиях такого рода.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33624051
Серега
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_spy_Ну это все решается на уровне бизнес-логики приложения.
Если есть охота решать - решай. Только по объему это "решание" возможно будет сопоставимо с основным функционалом. Я бы все таки посоветовал честно ответить самому себе на вопрос - так ли нужны "анализ и статистика" по удаленным (читай ненужным) данным. Если действительно нужны - то желаю удачи.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33625357
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Ненужных данных в системе практически не бывает. Зато идиотов-пользователей - сколько угодно и еще больше. И как человек, который некоторое время регулярно разбирался с тем, что пользователи натворили в базе, могу сказать: любого прога, который попробует безвозвратно удалять любую запись, успевшую поучаствовать в бизнес-процессах, нужно срочно и серьезно лечить.

Байка на тему. Некий пользователь пишет письмо в техподдержку - мол, не могу найти в системе приложение такое-то к договору такому-то. Девочка из поддержки ему терпеливо отвечает - мол, жмете сюда, вводите вот это, жмете сюда и получаете что хотите. Я не знаю, что ел на завтрак этот пользователь, но получив это письмо, он жмет куда указано, находит это приложение, удаляет его, после чего пишет второе письмо - мол, ни фига так не находится, ты не хочешь выполнять свои обязанности и помогать мне решить важную для бизнеса задачу, в общем, готовься увидеть небо в алмазах.

Я в принципе допускаю, что данный конкретный случай был провокацией на тему "не прибьет ли эта девочка этого пользователя". Вот только таких не один и не два. Их почти за каждым десктопом.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33625422
Фотография vadiminfo
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_spy_Ну как вариант не ставить статус для зависимых, а действовать в зависимости от статуса главной записи - например написать соответствующие view.
Т.е. тада надо будет написать запросы на соединение даже если главная табла не нужна? А када нужна - тада для этих табл другие view, чтобы избежать этих соединений? А када удаление из дочерних таблов то все то же?


Практика первого варианта есть в старом досовом клиппере. Там все что удалено помечается.

Второй вариант похож на аудит (скорее всего триггерный). Ить тада можно еще записывать и кто и что не тока удалил, но и изменил. Я такое делал. Но там были просто "особые" данные изменение которых китайцы считали серьезным преступлением. Но всю БД так аудить накладновато будет.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33625811
_spy_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vadiminfoТ.е. тада надо будет написать запросы на соединение даже если главная табла не нужна? А када нужна - тада для этих табл другие view, чтобы избежать этих соединений? А када удаление из дочерних таблов то все то же?
Да, все же вариант с каскадной простановкой статусов при логическом удалении главной записи видится более предпочтительным.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33629650
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.
--create sequence sdel
--/

drop view ttable
/
drop table ttable$
/

--таблица, хранящая как "живые", так и "мертвые" данные
create table ttable$(
    table_id number,
    descr varchar2( 255 ),
    dead$ timestamp, --number,   --индикатор смерти. Во многиз случаях можно (и лучше) использовать тип timestamp
--уникальные ключи можно создавать так
constraint pk_ttable$ unique(table_id, dead$)
using index
local
tablespace indx
--если не требуется управлять (большинство случаев), то можно
--иметь и такие PK.
--Но при большом количестве "мертвых" данных будет деградировать
--производительность. Поэтому вариант, предложенный выше, лучше.
--constraint pk_ttable$ primary key(table_id)
)
partition by list(dead$)(
    --раздел живых данных
    partition life
    values(null)    --dead$ is null
    --tablespace one
    ,
    --раздел смерти
    partition death
    values(default) --dead$ is not null
    storage(buffer_pool recycle)    --меньший приоритет в кеше
    --tablespace other
)
enable row movement --чтобы при попытке удаления можно было переместить данные в раздел смерти
--tablespace users
/


--вьюха, представляющая живую часть
create or replace view ttable
as
select * from ttable$ partition(life)
where dead$ is null --чтобы срабатывало check option
with check option
/
 
--при попытке удаления, данные перемещаются в раздел смерти
create or replace trigger trig_ttable_iod
instead of delete on ttable
begin
    update ttable$ partition (life)
    --set dead$ = sdel.NEXTVAL    --чтобы работали уникальные ключи
    set dead$ = current_timestamp   --если используется тип timestamp
    where table_id = :old.table_id
    ;
end;
/

--если сильно захотеть, можно еще сделать тригер instead of update,
--копирующий в раздел смерти обновляемые строки


--тестовый пример
insert into ttable(table_id, descr)
values( 1 , 'aaa')
/
insert into ttable(table_id, descr)
values( 2 , 'aaa')
/
delete from ttable
/
insert into ttable(table_id, descr)
values( 1 , 'aaa')
/
insert into ttable(table_id, descr)
values( 2 , 'aaa')
/
delete from ttable
/
insert into ttable(table_id, descr)
values( 1 , 'aaa')
/
insert into ttable(table_id, descr)
values( 2 , 'aaa')
/
commit
/
Но реально сейчас для таблиц, которые меняются юзерами в основном построчно, ( а не массово - пакетными задаными ), используем лог изменений. Это одна отдельная нескоростная таблица на все, из которой можно вытащить любую историю, кто, что, когда и откуда.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33629763
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_spy_ vadiminfoТ.е. тада надо будет написать запросы на соединение даже если главная табла не нужна? А када нужна - тада для этих табл другие view, чтобы избежать этих соединений? А када удаление из дочерних таблов то все то же?
Да, все же вариант с каскадной простановкой статусов при логическом удалении главной записи видится более предпочтительным.

Если будешь реализовывать через VIEW, то изменение статуса (например атрибут DELETED as DATE_TIME is not NULL), то менять каскадно вообщем-то ничего и не придется. Пользователь просто не увидит этих данных, т.к. они связаны.
А вообще-то системе можно разрешить и "удалять" записи. Вызывая в триггере PRE/POST-DELETE либо прекращение операции удаления, с изменением атрибута DELETED (PRE), либо дублирование записи (POST) и удаление оригинальной. Это зависит от выбранной СУБД.
Правда обычно добавляют и атрибут DELETED_BY.

Единственное с чем соглашусь, есть класс задач (очень маленький и специфичный) где это нужно. А в большенстве случаев можно прожить и без оной задумки...
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33629878
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nik_xЕсли будешь реализовывать через VIEW, то изменение статуса (например атрибут DELETED as DATE_TIME is not NULL), то менять каскадно вообщем-то ничего и не придется. Пользователь просто не увидит этих данных, т.к. они связаны.
Я так понимаю, Вы имеете в виду следующее: если в мастер-таблице есть признак удаления и есть вьюха живых записей, то каскадного логического удаления дочерних записей не потребуется, поскольку пользователь просто "не дойдет" до этих записей по интерфейсу программы.

Если так - не согласен. Причина этого очень проста: практически в любой нетривиальной системе существуют бизнес-функции, использующие позиции документа в отрыве от их заголовков. Скажем, отчеты наподобие оборотно-сальдовой ведомости вполне могут быть построены именно таким образом. Соответственно, в этом случае Ваш подход требует притягивания заголовков и проверки в них статуса записи везде, где используются позиции. Что есть неудобно для разработчика, неоптимально для сервера и прежде всего элементарно ненадежно.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33629903
Estets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerЕсли так - не согласен. Причина этого очень проста: практически в любой нетривиальной системе существуют бизнес-функции, использующие позиции документа в отрыве от их заголовков. Скажем, отчеты наподобие оборотно-сальдовой ведомости вполне могут быть построены именно таким образом. Соответственно, в этом случае Ваш подход требует притягивания заголовков и проверки в них статуса записи везде, где используются позиции. Что есть неудобно для разработчика, неоптимально для сервера и прежде всего элементарно ненадежно.
Угу а если физически удалять запись, то нужно следить чтоб везде удалялись хвосты иначе, см выше "в любой нетривиальной системе существуют бизнес-функции..."
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33629907
nik_x
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
- Да не согласен я.
- С кем? С энгельсом или с Каутским?
- С обоими, - ответил Шариков.
- Это замечательно, клянусь богом. "Всех, кто скажет, что другая..." А
что бы вы со своей стороны могли предложить?
- Да что тут предлагать?.. А то пишут, пишут... Конгресс, немцы
какие-то... Голова пухнет. Взять все, да и поделить...

Булгаков.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33630068
_spy_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
EstetsУгу а если физически удалять запись, то нужно следить чтоб везде удалялись хвосты иначе, см выше "в любой нетривиальной системе существуют бизнес-функции..."
Если физически удалять запись, то хвосты удалятся каскадом, если нормально схему спроектировать.


To Ненавижу регистрацию
Спасибо за пример.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33630320
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
EstetsУгу а если физически удалять запись
То во-первых, я выше аргументировал, почему так в большинстве случаев делать нельзя. Во-вторых, внешние ключи в этом случае уберегут от излишней забывчивости всех, кроме следующих Вашему дизайну без constraint-ов. В-третьих же таки Вы правы и именно это я и доказываю: к "хвосту" в любой реальной системе следует относиться тщательно и аккуратно, иначе будут проблемы.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33631694
Estets
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerТо во-первых, я выше аргументировал, почему так в большинстве случаев делать нельзя. Во-вторых, внешние ключи в этом случае уберегут от излишней забывчивости всех, кроме следующих Вашему дизайну без constraint-ов. В-третьих же таки Вы правы и именно это я и доказываю: к "хвосту" в любой реальной системе следует относиться тщательно и аккуратно, иначе будут проблемы.
Вы за Энгельса будете или за Каутского? ;)
Согласен, лишних данных в системе не бывает. У нас физически удаляются только следующие данные:
1) Настройки (метаинформация) - поскольку доступ к ним имеет только администратор и ему и отвечать за внесенные исправления.
2) Агрегированная информация - например расситанные и сохраненные данные для отчетов, т.к. в случае необходимости можно эти данные расчитать еще раз.
3) Информация из внешних источников - опять-же если удаленная информация потребуется вновь, то ее можно будет восстановить.

А по поводу "каскадного удаления" vs "каскадного проставления признака неактуальный", то если это делать триггерами затраты на программирование примерно одинаковые.

Хотя замечу, что у нас нет каскадного обновления статусов записей, и вполне возможен вариант когда есть актуальный перечень, для неактуалной накладной. НО я ни разу не сталкивался с данной проблемой т.к. связанные перечни обрабатываются в связке с основным документом и проверяется "неудаленность" как позиции в перечне (так как она сама мола быть удалена) так и основного документа.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33631847
nnov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
_spy_Хотелось бы узнать мнение на тему, кто как организует логическое удаление записей в БД (когда они удаляются на уровне пользователей, но физически продолжают присутствовать в БД) и какие в связи с этим преимущества и недостатки. Сейчас я вижу 2 варианта:
1. Пометка записи на удаление, т.е. введение поля статуса записи.
2. Введение в схему БД дополнительных таблиц для удаленных записей со структурой, совпадающей с оригинальной и перенос туда записей при удалении.

Могу предложить третий вариант, этот вариант использовался в банковсой системе которую я 2 года назад обслуживал, а сейчас я его реализовал в своей системе документооборота.
Принцип вытекает из второго варианта, но только я не статус записи ввел
а время действия документа Date_Begin и Date_End и состояние
Пока запись актуальна Date_End = '01.01.2099:00:00:00' при удалении или любом изменении Date_End = Now
все изменения делаются только процедурами, так легче и гибче можно отслеживать права. Процедура при любом изменении записи, делает ее копию с новым состоянием (включая все подчиненные таблицы) и проставляет даты начала конца.
Этот подход позволяет видеть данные на любой момент времени, обеспечивает непротиворечивость отчетности со временем, ну и естественно всю историю изменений.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33632107
_spy_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
To nnov
Спасибо за вариант.
В принципе, такая подробная "историчность" и версионность данных не требуется. Однако поле с датой удаления - это нужная информация, тем более, что я думаю как раз на поле с датой удаления расширять уникальные ключи.
Кроме того, думаю сделать отдельную таблицу дополнительной информации об удаленных объектах, где будут поля
ID объекта
Тип объекта
Пользователь, удаливший запись
Причина удаления

Эта таблица не будет использоваться при работе обычных пользователей, она будет доступна только пользователям, имеющим доступ к удаленным записям.
Таким образом, получается где-то комбинированный подход - с одной стороны для логического удаления используется статус, с другой стороны, есть отдельная таблица с дополнительной информацией об удаленных объектах.
Хотелось бы узнать мнения...
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33632268
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Кстати,по поводу таблички с дополнительными сведениями: у меня есть режим работы (фактически роль) "Разрешение работы с указанием причины". Суть вот в чем:иногда кто-то кого-то заменяет при уходе в отпуск,но ходить под чужим паролем неверно и всегда давать такую роль тоже не верно.На период отпуска человека новому дается вышеуказанный режим работы на необходимые объекты. При выполнении каких-либо действий система предупреждает человека об опасности его действий и спрашивает,готов ли он продолжить.Если готов,то просит ввести причину этих действий (обычный текст),который пишется в аналогичную табличку с доп.сведениями.Если потом работа проверяется и в причине удаления всех счетов контрагента причина пишется как "А пошли вы все в *?;№№№#$",то ему вламывают.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33632294
bas
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nnovПока запись актуальна Date_End = '01.01.2099:00:00:00'

Ага, а потом говрят про боязнь 2000 года (в вашем случае будет 2100 год), тогда уж лучше это поле NULL оставлять или ну хотя бы 2999 год ставить...
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33632411
_spy_
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
basАга, а потом говрят про боязнь 2000 года (в вашем случае будет 2100 год), тогда уж лучше это поле NULL оставлять или ну хотя бы 2999 год ставить...
Хотел бы я писать программы, которые работали бы хотябы до 2099 года))
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33632468
nnov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
bas
Ага, а потом говрят про боязнь 2000 года (в вашем случае будет 2100 год), тогда уж лучше это поле NULL оставлять или ну хотя бы 2999 год ставить...
А можно привести пример программы которая проработала хотя-бы 20 лет
А вот NULL ни в коем случае нельзя, потому как все данные показываются с фильтром "текущая дата" > Date_Begin and "текущая дата" < Date_End
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33632833
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nnovА можно привести пример программы которая проработала хотя-бы 20 лет
Сколько угодно и гораздо больше. Например, поставь Windows XP, загляни в каталог %WINDIR%\system32 и увидишь там файлик edlin.exe, в котором с 85-го года вряд ли поменялся хотя бы один байт.

nnovА вот NULL ни в коем случае нельзя,
Как раз NULL там и нужен.

nnovпотому как все данные показываются с фильтром "текущая дата" > Date_Begin and "текущая дата" < Date_End
То есть Вы предлагаете из-за кривого следствия сообразно уродовать причину.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33632920
nnov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerСколько угодно и гораздо больше. Например, поставь Windows XP, загляни в каталог %WINDIR%\system32 и увидишь там файлик edlin.exe, в котором с 85-го года вряд ли поменялся хотя бы один байт.

Самому то не смешно...

softwarer
Как раз NULL там и нужен.

И зачем же он там, просветите, что вы получети при его использовании кроме гемороя.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33633224
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nnovИ зачем же он там, просветите, что вы получети при его использовании кроме гемороя.
Если коротко, то отсутствие геморроя. Например, легко и просто различаются открытые и закрытые периоды, код становится легко читаемым и не содержит магических констант. Главное же - код становится надежнее; я на практике чужого большого проекта, доставшегося мне на поддержку, убедился, что ошибки "обработки магических констант как обычных" гораздо чаще проходят сквозь тестирование и приводят к гораздо более неприятным последствиям, нежели отсутствие особой обработки null-а там, где она нужна.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33633275
nnov
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarerЕсли коротко, то отсутствие геморроя. Например, легко и просто различаются открытые и закрытые периоды, код становится легко читаемым и не содержит магических констант. Главное же - код становится надежнее; я на практике чужого большого проекта, доставшегося мне на поддержку, убедился, что ошибки "обработки магических констант как обычных" гораздо чаще проходят сквозь тестирование и приводят к гораздо более неприятным последствиям, нежели отсутствие особой обработки null-а там, где она нужна.
Про какие магические константы идет речь не понял, в поле проставляется дата-время, и в плане обработки это гораздо лучше, NULL вообще имеет много минусов, нельзя сравнивать и производить вычисления, неэффективная индексация (а внекоторых СУБД вообще низя). А в данном конкретном случае будет вообще двойная работа. При построеной мною схеме, я всегда и везде подставляю одинаковое условие Date_Begin < DATETIME < Date_End причем по умолчанию подставляется текущее датавремя, а если нужно получить отчет на 10.07.2004 то просто указываем дату, и я не меняя никаких запросов процедур и т.д. в тойже логике получаю срез документов на указаную дату.
Если бы стоял NULL нужно усложнять запросы при обращении к прошлым периодам.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33635482
PridobreY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Может будет интересно...
Про даты и версии.
Сначало о терминологии.
Версионность - возможность видеть объект (запись, группу записей) на момент времени отличный от текущего,
как правило, в прошедшем времени.
Логирование - возможность видеть кем, когда и как объект был изменен (удален, добавлен).

Теперь применительно к данным.
Исходя из бизнес-требований и т.п. к нужным объектам применяем соответствующее решение.
К примеру, к таким объектам как документы (меняют свой статус в бизнес-процессе),
информация о юр.,физ. лице, приминительна версионность.
К объектам попроще, где версионность не нужна, но есть вероятность доступа к ним "кривых рук",
а достоверность их важна, и порой трудно найти крайнего, применяется логирование.
Возможно прменение и версионности и логирования к одному объекту.

Немного о реализации.
Есть таблица с основными данными, есть с версионными. Таблица с версионными данными имеет поле с датой
актуальности этих данных.
Для версионного объекта, версия создается в момент сохранения (нового, редактируемого) объекта.
Для объекта, имеющего ссылку на версионный, реализация может быть сделана одним из двух способов,
опять же, в зависимости от требований.
Это 1 - выбор версии при сохранении объекта,
либо 2 - выбор версии, при просмотре объекта.
Как пример, версионный объект "Юр.лицо" в документе (ссылка на юр.лицо из документа).
В первом случае, мы всегда будем видеть документ, таким-каким он был.
Логирование, это лишь теневая таблица, в которой регистрируются все изменения,
плюс информация о том, кто когда и откуда их сделал.

Касаемо темы, про удаление.
В зависимости от требований, реализуется соответствующим способом.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33635600
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Есть таблица с основными данными, есть с версионными.

Алгоритм разделения данных на основные и версионные - в студию.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33635659
Фотография Shtock
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Полностью согласен с PridobreY: у меня алгоритм чисто эмпирический-спрашиваю у пользователя,нужна ли им история для возможности отката или отчетности (за прошлые периоды),или только для битья по рукам.
Пример: справочник видов ЦБ - за него бьют по рукам. Картотека клиентов-версионная.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33635664
PridobreY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> Есть таблица с основными данными, есть с версионными.

Алгоритм разделения данных на основные и версионные - в студию.

Это не алгоритм. Это проектирование.

Простой пример. Контрагент.
Основные - ПК (перв.ключ)
Внутренний код
Краткое наименование
Версионные - ПК
ПК_Осн.
Дата актуальности
Полное название
Тип (ОАО, ЗАО,....)
и т.д.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33635896
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Это не алгоритм. Это проектирование.

Уважаемый, Вы буквосочетаниями для какой цели изъясняетесь? Вопрос был абсолютно конкретный.

> Простой пример

Мне не примеры нужны (тем более примеры с ошибками), а алгоритм. На основании чего и как делается вывод об "обычности" данных и "версионности"?
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33635956
PridobreY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> Это не алгоритм. Это проектирование.

Уважаемый, Вы буквосочетаниями для какой цели изъясняетесь? Вопрос был абсолютно конкретный.

> Простой пример

Мне не примеры нужны (тем более примеры с ошибками), а алгоритм. На основании чего и как делается вывод об "обычности" данных и "версионности"?

1. Где в примерах ошибки?
2. Если Вас интересует алгоритм проектирования, пожалуйста. Если значение атрибута (свойство) объекта может изменяться с течением времени, и нужно на конкретную дату видеть его таким, каким оно было на эту дату, тогда версионный атрибут, если оно не изменяется, или его изменение не влияет на бизнесправила, тогда простой.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636124
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Если значение атрибута (свойство) объекта может изменяться
> с течением времени

А теперь расскажите, какие атрибуты не могут изменяться с течением времени.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636136
Фотография proposed amendment
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> Если значение атрибута (свойство) объекта может изменяться
> с течением времени

А теперь расскажите, какие атрибуты не могут изменяться с течением времени.

ЕГРН например... да мало ли... дата регистрации, дата рождения...

и, уж наверняка, дата смерти...
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636159
PridobreY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> Если значение атрибута (свойство) объекта может изменяться
> с течением времени

А теперь расскажите, какие атрибуты не могут изменяться с течением времени.

Уважаемый guest_20040621, не нужно выдергивать фразу из предложения, и задавать по ней вопрос. Если Вас что-то по данной теме интересует, формулируйте вопрос конкретней, а не разводите полемику.

p.s.
с течением времени, не может изменитсья, к примеру, дата рождения (исключая ошибочный ввод)
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636200
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Если Вас что-то по данной теме интересует

Дружище, сильно вряд ли Вы скажете что-то такое, чего я бы не знал.

> формулируйте вопрос конкретней

Некуда конкретней.

> а не разводите полемику

Т. е. Вам ахинею нести можно, а мне вопросы задавать нельзя?

> с течением времени, не может изменитсья, к примеру, дата рождения
> (исключая ошибочный ввод)

Неправда. Никто не может гарантировать, что через год не введут биометрические карты и дата рождения будет фиксироваться с точностью до минуты или секунды. Еще варианты?
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636217
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621Неправда. Никто не может гарантировать, что через год не введут биометрические карты и дата рождения будет фиксироваться с точностью до минуты или секунды.
И каким именно образом это сделает эти данные версионными? Ну и заодно любопытно было бы посмотреть на машину времени, которая определит эти данные например для меня :)
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636219
PridobreY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621Дружище, сильно вряд ли Вы скажете что-то такое, чего я бы не знал.
От чего такая уверенность?
guest_20040621Т. е. Вам ахинею нести можно, а мне вопросы задавать нельзя?
И где я нес ахинею? Хотя Вам никто не запрещает...
guest_20040621Неправда. Никто не может гарантировать, что через год не введут биометрические карты и дата рождения будет фиксироваться с точностью до минуты или секунды. Еще варианты?
Читайте выше "Исходя из бизнес-требований..."
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636227
PridobreY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer guest_20040621Неправда. Никто не может гарантировать, что через год не введут биометрические карты и дата рождения будет фиксироваться с точностью до минуты или секунды.
И каким именно образом это сделает эти данные версионными? Ну и заодно любопытно было бы посмотреть на машину времени, которая определит эти данные например для меня :)

А вдруг изобретут! И будут разные релизы этой машины, и надо будет править дату, после каждого релиза, и хранить эту историю :) )
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636228
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> И каким именно образом это сделает эти данные версионными?

Никаким, естественно. В данном случае меняться будут не данные, а метаданные. В контексте вопроса - версионность будет у метаданных, а не у данных.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636234
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Читайте выше "Исходя из бизнес-требований..."

Что это за алгоритм "бизнес-требование"? Своими словами, пожалуйста.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636237
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
PridobreYА вдруг изобретут! И будут разные релизы этой машины, и надо будет править дату, после каждого релиза, и хранить эту историю :) )
Это уже другая сущность. Не атрибут "дата рождения" в сущности "человек", а атрибут "измеренная дата" в сущности "результаты экспериментов по измерению дат рождения".

guest_20040621> И каким именно образом это сделает эти данные версионными?

Никаким, естественно. В данном случае меняться будут не данные, а метаданные. В контексте вопроса - версионность будет у метаданных, а не у данных.

OK, давайте посмотрим контекст вопроса.

guest_20040621
> Если значение атрибута (свойство) объекта может изменяться
> с течением времени

А теперь расскажите, какие атрибуты не могут изменяться с течением времени.
Итак, судя по всему, Вы отождествляете понятия "значение атрибута (свойство)" и "метаданные"?
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636256
PridobreY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> Читайте выше "Исходя из бизнес-требований..."

Что это за алгоритм "бизнес-требование"? Своими словами, пожалуйста.
Бизнес-требования это не алгоритм, а документ, который содержит информацию (требования к бизнес-процессам в частности.), используемую при проектировании информационной системы.

softwarerЭто уже другая сущность. Не атрибут "дата рождения" в сущности "человек", а атрибут "измеренная дата" в сущности "результаты экспериментов по измерению дат рождения".
Согласен. В моем случае, должна быть версионной сущность "человек", с версионным атрибутом "точная дата рождения".
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636267
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Вы отождествляете понятия "значение атрибута (свойство)" и "метаданные"?

Нет. Контекст - [2507333].
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636283
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Бизнес-требования это не алгоритм, а документ

Т. е. любая бумажка - основание для разделения данных на "обычные" и "версионные"? ;)))

Я бы на вопрос ответил таким образом: постоянными можно считать независимые (степень независимости можно обсуждать) данные, точность измерения (или область значений) которых заранее известна (либо известен алгоритм их получения) и единицы измерения - стандартны. Все остальные данные - увы - по своей природе версионны.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636363
Гость74
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Страховое свидетельство (Пенсионного фонда) подлежит обмену в случаях:
Изменения фамилии, имени, отчества, ДАТЫ РОЖДЕНИЯ, МЕСТА РОЖДЕНИЯ или поля
застрахованного лица;
установления неточности или ошибочности содержащихся в нем сведений. (с)

Написано это на зеленой карточке, которая есть у каждого.
Причем если ошиблись в дате рождения при составлении свидетельства,
то это попадает под "установления неточности или ошибочности содержащихся
в нем сведений"
Осюда логически заключаем, что дату рождения поменять можно!
Убили веру в константы на корню! :-)))))))
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636370
Фотография proposed amendment
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Гость74Страховое свидетельство (Пенсионного фонда) подлежит обмену в случаях:
Изменения фамилии, имени, отчества, ДАТЫ РОЖДЕНИЯ, МЕСТА РОЖДЕНИЯ или поля
застрахованного лица;
установления неточности или ошибочности содержащихся в нем сведений. (с)

Написано это на зеленой карточке, которая есть у каждого.
Причем если ошиблись в дате рождения при составлении свидетельства,
то это попадает под "установления неточности или ошибочности содержащихся
в нем сведений"
Осюда логически заключаем, что дату рождения поменять можно!
Убили веру в константы на корню! :-)))))))

это потому, что такой важный вопрос как поддержание целостности и непротиворечивости данных отдали на откуп профанам и делетантам из МинЗдрава, конечно они такого нагородили...

даже ежу понятно и очевидно, что неточности при указании в даты рождения должны устраняться ТОЛЬКО СТОРНИРОВАНИЕМ

неточности места указания места рождения устраняются сторнированием даты рождения (возраста) до нуля, с последующим вводом нового места рождения и фиксироваться соответсвующей проводкой по счетам родильного дома...
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636396
PridobreY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> Бизнес-требования это не алгоритм, а документ

Т. е. любая бумажка - основание для разделения данных на "обычные" и "версионные"? ;)))

Я бы на вопрос ответил таким образом: постоянными можно считать независимые (степень независимости можно обсуждать) данные, точность измерения (или область значений) которых заранее известна (либо известен алгоритм их получения) и единицы измерения - стандартны. Все остальные данные - увы - по своей природе версионны.

Отвечать можно по разному. Бизнес-требования это не любая бумажка, это требования к информационной системе, предъявляемые заказчиком, либо сформированными на основе анализа функций проектируемой системы.

В разных проектах, системах один и тот же объект (сущность), набор его атрибутов (свойств) может быть в одном случае постоянным, в другом версионным. Так же, как и кол-во атрибутов объекта. Где-то достаточно названия организации, где-то нужна более детальная информация (адреса, счета и т.п.). Всё зависит от требований к системе (автоматизируемой системы).

guest_20040621степень независимости можно обсуждать
Делается это на этапе анализа.

guest_20040621Все остальные данные - увы - по своей природе версионны
Это не значит, что в каждой системе нужно поддерживать версионность этих данных. Всё нужно в меру. Никому не нужной функциональностью, лишь можно навредить. В случае организации версионности, это дополнительные расходы для хранения информации, вычислительной мощности, обработки информации и поддержки реализуемого функционала.

p.s.
Эта любовь к алгоритмам неспроста...
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636399
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> Вы отождествляете понятия "значение атрибута (свойство)" и "метаданные"?

Нет. Контекст - [2507333].
Это часть контекста. Как и более свежие цитаты, приведенные мной. Впрочем, и в указанном контексте я что-то не заметил упоминаний о метаданных, зато есть фразы:

Версионность - возможность видеть объект (запись, группу записей) на момент времени отличный от текущего,

К примеру, к таким объектам как документы (меняют свой статус в бизнес-процессе),

Таблица с версионными данными имеет поле с датой актуальности этих данных.
Для версионного объекта, версия создается в момент сохранения (нового, редактируемого) объекта.


вполне явно показывающие, что речь идет о версионности "обычных данных".
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636444
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> вполне явно показывающие, что речь идет о версионности "обычных
> данных".

Ключевое слово "объект".
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636449
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Бизнес-требования это не любая бумажка

Знаете, т. н. "бизнес-требования" - тупой термин, придуманный тупыми маркетологами, который в общем случае не несет никакой смысловой нагрузки. Делит пальму первенства по тупости с термином "бизнес-логика".

> требования к информационной системе, предъявляемые заказчиком

Вы сами вспомните, как называется этот документ? ;) Ни при чем здесь никакие "бизнес-требования".

> либо сформированными на основе анализа функций проектируемой системы.

;)))

> В разных проектах, системах один и тот же объект (сущность)

Дружище, термин "объект" в общем случае не имеет ничего общего с термином "сущность". Вы о чем говорите и что имеете в виду?

> В случае организации версионности, это дополнительные расходы

Очень незначительные. В любом смысле.

> Эта любовь к алгоритмам неспроста

Нет никакой любви. Если беретесь что-то формулировать, делайте это нормальным образом. Если оперируете определениями - ссылайтесь на источник.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636454
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
nnovПока запись актуальна Date_End = '01.01.2099:00:00:00'
запись актуальна если нет замещающей ее записи. Иначе при вводе новой записи требуется дополнительная логика по замене данных в записях, которые становятся неактуальными. А при отмене - откат назад, восстановление предыдущего состояния. Хорошо когда это одна запись... и нечем заняться... Так и рождаются монстры с гемморойной логикой.
Типичный пример курсы валют:
Код: plaintext
1.
select top  1  ratevalue from currencyrates where rdate <= @date and curid = @cur
order by rdate desc
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636456
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621Ключевое слово "объект".
После которого в скобках указано, что именно понимается под "объектом".
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636459
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmзапись актуальна если нет замещающей ее записи.
Нельзя ли описать, какую именно "замещающую ее запись" Вы бы внесли в реестр недвижимости Нью-Йорка 11 сентября небезызвестного года?
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636466
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer iscrafmзапись актуальна если нет замещающей ее записи.
Нельзя ли описать, какую именно "замещающую ее запись" Вы бы внесли в реестр недвижимости Нью-Йорка 11 сентября небезызвестного года?
в данном контексте
Код: plaintext
1.
2.
update restitems 
set status = -  1 
where city = 'NY' and recode = 'WTC'
:(
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636469
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
только к замещающим записям это не имеет отношение.
Если бы WTC переехал, тогда запись бы была другой
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636472
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> После которого в скобках указано, что именно понимается под "объектом".

Спасибо, я умею читать; все сказанное в силе.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636480
Фотография softwarer
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafmНельзя ли описать, какую именно "замещающую ее запись" Вы бы внесли в реестр недвижимости Нью-Йорка 11 сентября небезызвестного года?
в данном контексте
Код: plaintext
1.
2.
update restitems 
set status = -  1 
where city = 'NY' and recode = 'WTC'
:([/quot]
Стоп-стоп-стоп. Прежде всего, я что-то не вижу здесь внесения замещающей записи - следовательно, "актуальная запись" продолжает существовать. Зато я вижу здесь факт "неверсионного изменения" - нигде не указано, что статус сменился именно 11.09. Практически Вы потеряли информацию.

iscrafmтолько к замещающим записям это не имеет отношение.
Хм. Тут уже вопросы к Вашей формулировке. Вы сказали, "запись перестает быть актуальной..." Я привел пример события, при котором запись явно перестала быть актуальной. Если эта ситуация решается другим способом - значит, Ваша формулировка неполна.

В целом, Ваш подход безусловно заслуживает большой медали Общества Любителей Нормализованных БД. Но на практике он имеет и свойственные нормализации недостатки; например, любой запрос, в котором требуется вывести период действия значения, без аналитических функций нормально не расписывается (собственно, в ANSI SQL, если не ошибаюсь, такой запрос вообще НЕ УДАСТСЯ написать).
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636489
PridobreY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> Бизнес-требования это не любая бумажка

Знаете, т. н. "бизнес-требования" - тупой термин, придуманный тупыми маркетологами, который в общем случае не несет никакой смысловой нагрузки. Делит пальму первенства по тупости с термином "бизнес-логика".

одни буквы...

guest_20040621> требования к информационной системе, предъявляемые заказчиком

Вы сами вспомните, как называется этот документ? ;) Ни при чем здесь никакие "бизнес-требования".

> либо сформированными на основе анализа функций проектируемой системы.

;)))

Это называется "Постановка задачи", на основаниии которой пишется "Техническое задание". Интересно, как Вы сами проектируете и разрабатываете системы, без подобного документа. В его отсутствии или присутствии в виде формальности (неточности трактований требований), растет кол-во требований, переодически противоречащих предыдущим, время разработки проекта стремится к бесконечности, а сам исполнитель начинает нести убытки. Я говорю о достаточно больших проектах.

guest_20040621> В разных проектах, системах один и тот же объект (сущность)

Дружище, термин "объект" в общем случае не имеет ничего общего с термином "сущность". Вы о чем говорите и что имеете в виду?
И какие это такие, общие случаи?
Тот кто хотел, понял что я имел ввиду. В скобках уточнение..

guest_20040621> В случае организации версионности, это дополнительные расходы

Очень незначительные. В любом смысле.
Это Вы заказчику пропойте. :)
А как эксплуатация начнется, послушайте их.

guest_20040621> Эта любовь к алгоритмам неспроста

Нет никакой любви. Если беретесь что-то формулировать, делайте это нормальным образом. Если оперируете определениями - ссылайтесь на источник.
Зачем кудато ссылаться, если сказано что под термином имеется ввиду.

p.s.
Кроме Ваших, необоснованных реплик, по существу темы ничего и не слышно.
Конструктивней надо.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33636495
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
softwarer
Стоп-стоп-стоп. Прежде всего, я что-то не вижу здесь внесения замещающей записи - следовательно, "актуальная запись" продолжает существовать. Зато я вижу здесь факт "неверсионного изменения" - нигде не указано, что статус сменился именно 11.09. Практически Вы потеряли информацию.

ниже написал, что к замещающим записям это не имеет отношение. Впрочем Вы сами думаю увидели следующее сообщение. А насчет версионности :) Лень мне было дописывать еще set-ы, думал сами догадаетесь. Никакая информация конечно же не теряется.


softwarer
В целом, Ваш подход безусловно заслуживает большой медали Общества Любителей Нормализованных БД.

Спасибо за медаль А что такое нормализованная БД? Шутка.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33637278
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> И какие это такие, общие случаи?

Н-да... одно непонятно: почему Вы имеете наглость что-то кому-то объяснять. Дружище, на Вашем месте я бы молчал и слушал. Вы вообще что-нибудь о проектировании читали?

> Тот кто хотел, понял что я имел ввиду. В скобках уточнение.

;)) Чего уточнение? Термина "объект"? Не смешите мои тапочки.

> Зачем кудато ссылаться, если сказано что под термином имеется ввиду.

Дружище, Вы разговариваете набором букв, Вы это понимаете? "Объект" имеет вполне себе конкретный смысл, а вот "запись" - это Ваша отсебятина, которая вообще ничего общего с проектированием не имеет. Что с помощью чего Вы уточнили? Читайте больше, что-ли...

> по существу темы ничего и не слышно.

Очень даже слышно. Вы написали абсолютную хрень, я Вам рассказал, почему это так. Чего более конкретного Вы хотите?

Учитесь, молодой человек; не пишите ахинеи; не давайте глупых советов.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33637389
PridobreY
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621> И какие это такие, общие случаи?

Н-да... одно непонятно: почему Вы имеете наглость что-то кому-то объяснять. Дружище, на Вашем месте я бы молчал и слушал. Вы вообще что-нибудь о проектировании читали?

> Тот кто хотел, понял что я имел ввиду. В скобках уточнение.

;)) Чего уточнение? Термина "объект"? Не смешите мои тапочки.

> Зачем кудато ссылаться, если сказано что под термином имеется ввиду.

Дружище, Вы разговариваете набором букв, Вы это понимаете? "Объект" имеет вполне себе конкретный смысл, а вот "запись" - это Ваша отсебятина, которая вообще ничего общего с проектированием не имеет. Что с помощью чего Вы уточнили? Читайте больше, что-ли...

> по существу темы ничего и не слышно.

Очень даже слышно. Вы написали абсолютную хрень, я Вам рассказал, почему это так. Чего более конкретного Вы хотите?

Учитесь, молодой человек; не пишите ахинеи; не давайте глупых советов.

Ни такой уж я и молодой, а Вам, тем более не дружище. Хрень идет только от Вас, и ничего путного Вы не сказали. Если Вам не нравится терминология, предложите совю правильную модераторам, для публикации в правилах форума.
p.s.
И не забудьте про "тупых" маркетологов.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33637825
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Ни такой уж я и молодой

Тем более должно быть стыдно.

> Если Вам не нравится терминология

Мне, уважаемый, терминология нравится. Не нравится, когда вместо стандартной используют доморощенную.

> предложите совю правильную модераторам

Консультации, чтение вслух стандартов, - на возмездной основе.

> И не забудьте про "тупых" маркетологов.

А что с ними не так?

P.S. Про не-дружищ оригинален был товарищ Выбегалло. Жаль, давненько его не слышно. ;) Амвросий Амбруазович, хватит дуться. ;)
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33638807
sp
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
и зачем так сложно когда делается это просто
Код: plaintext
select ratevalue from currencyrates where beginrdate <= @date and @date < endrdate curid = @cur

iscrafm nnovПока запись актуальна Date_End = '01.01.2099:00:00:00'
запись актуальна если нет замещающей ее записи. Иначе при вводе новой записи требуется дополнительная логика по замене данных в записях, которые становятся неактуальными. А при отмене - откат назад, восстановление предыдущего состояния. Хорошо когда это одна запись... и нечем заняться... Так и рождаются монстры с гемморойной логикой.
Типичный пример курсы валют:
Код: plaintext
1.
select top  1  ratevalue from currencyrates where rdate <= @date and curid = @cur
order by rdate desc
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33638809
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
затем, что не нужно делать никаких изменений кроме добавления новой записи. Попробуйте :) Проверено.
Алгоритмы должны быть просты и прозрачны. Дата окончания действия курса - лишнее.
p.s. Каждый день надеюсь не будете менять "< endrdate ".
Успехов!
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33638817
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
В продолжении темы.
Проектировать БД можно по правилам, можно без правил, а можно "под потребности".
Задавал вопрос уважаемый softwarer : " например, любой запрос, в котором требуется вывести период действия значения, без аналитических функций нормально не расписывается ". Ответ на него прост. Нужно смотреть на назначение БД. Приведенный выше вопрос можно поставить по другому. А зачем мне такая аналитика нужна? Да, меня интересует конкрентный документ, но совсем не интересует с какого и по какое он действовал. Гораздо более востребованная информация - действовал ли документ в заданный период. А если нужно построить временные ряды, то ничто не мешает потратить немного времени и расчитать их при помощи процедуры, так как его востребованность гораздо ниже. А еще лучше показать все это в кубе или в графике.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33656875
Wireless
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Наилучший вариант хранения данных - при помощи пары дат -
дата начала, дата окончания действия.

Если использовать только одну дату, то значительно повышается сложность извлечения данных на определенную дату.

Я после некоторого анализа когда проектировалась наша биллинговая система выбрал именно вариант с двумя датами. Причем было два типа версионных таблиц -
1. Содержащие большое количество атрибутов, которые редко относительно изменяются. В этом случае в таблицу просто добавляются dton,dtoff и соответствующим образом оформляются все запросы, обращающиеся к этой таблице.
2. Содержащие атрибуты, которые часто меняются. И, кроме того, нужно знать индививдуально какой атрибут с какой по какую дату имеет/имел такое значение. В этом случае в таблице храниться код_атрибута, датаот, датапо, значение, ну и может какие то еще атрибуты как то кто и когда изменял и пр.

Такой же подход встречал в некоторых других серьезных коммерческих продуктах.

В принципе, все версионные данные желательно хранить в таблицах второго типа - получается более универсальнее и правильнее. Но возникают например трудности на уровне описания ER-диаграм БД - они получаются очень непоказательными.

Подумывал над созданием некой надстройки в БД для хранения всех версионных (кстате, думаю правильней их называть историческими) данных - например, завести таблицу, содержащую
1. код категории (к какой таблице принадлежали бы эти данные, будь они оформлены неисторическими),
2. код подраздела (код атрибута),
3 и 4. дата от, дата по,
5. значение (может быть серия значений разных типов, или применение каких-либо объектно-ориентированных возможностей БД для хранения значений разных типов).
6. Поля описывающие кто,
7. и когда менял

Далее завести определенный уровень абстракции операций над историческими данными - добавление, удаление, изменение. В принципе, у меня уже есть определенные наработки, но сейчас ломать всю систему под это уже тяжело. Версионные данные в нашей системе хранятся в таблицах типа 1 и 2, как описано выше.

Проблемы с производительностью могут решаться правильным секционированием и субсекционированием таблиц и настройке соответствующим образом фраз хранения для каждой партиции, в соответствиии с характером тех или иных данных.

Думаю, в очень крупных информационных системах (1000 и больше сущностей) такой или похожий уровень абстракции должен быть сделан обязательно - трудности при проектировании (если правильно все сделать, они не такие уж и большие) потом с лихвой окупятся при эксплуатации и развитии системы.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33657645
sam11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Несколько примеров из 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.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33657742
va_kochnev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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 при желании можно найти самые причудливые реализации.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33657749
va_kochnev
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
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 при желании можно найти самые причудливые реализации.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33660747
sam11
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Ну ведь HR - это не исконно Оракловые модули. И вообще, HR, очень сильно отличается от остального. Я, кстати, такой вариант (с "магическими" константами) считаю плохим.

With Best Regards. Sam.
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33738647
Sgt.Pepper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafm nnovПока запись актуальна Date_End = '01.01.2099:00:00:00'
запись актуальна если нет замещающей ее записи. Иначе при вводе новой записи требуется дополнительная логика по замене данных в записях, которые становятся неактуальными. А при отмене - откат назад, восстановление предыдущего состояния. Хорошо когда это одна запись... и нечем заняться... Так и рождаются монстры с гемморойной логикой.
Типичный пример курсы валют:
Код: plaintext
1.
select top  1  ratevalue from currencyrates where rdate <= @date and curid = @cur
order by rdate desc

а если нужно весь справочник на дату вернуть (т.е. curid in (all records)) - курсором побежим?..
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33739707
Фотография iscrafm
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Sgt.Pepperа если нужно весь справочник на дату вернуть (т.е. curid in (all records)) - курсором побежим?..
:) конечно же нет, построим запрос по другому
...
Рейтинг: 0 / 0
Логическое удаление записей
    #33747739
Sgt.Pepper
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
iscrafm
:) конечно же нет, построим запрос по другому

есть идеи как это изящно сделать?
...
Рейтинг: 0 / 0
81 сообщений из 81, показаны все 4 страниц
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Логическое удаление записей
Найденые пользователи ...
Разблокировать пользователей ...
Читали форум (0):
Пользователи онлайн (0):
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]