powered by simpleCommunicator - 2.0.61     © 2026 Programmizd 02
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Форумы / Проектирование БД [игнор отключен] [закрыт для гостей] / Оптимальная структура таблицы для хранения истории...
95 сообщений из 95, показаны все 4 страниц
Оптимальная структура таблицы для хранения истории...
    #35729501
Фотография bootty
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
... изменений чего-либо.

Вариант номер раз (примерно как здесь )
Код: plaintext
1.
2.
3.
4.
UID:UID уникальный ключ 
BeginPeriod: date/datetime not null. Начало актуальности сведений.
EndPeriod: date/datetime Конец актуальности сведений.
<Измерения> Разрезы, в которых ведутся сведения
<Ресурсы> Сведения

Пример:
Сотрудник ZZZ <ресурс 1> имеет доступ <измерение 1> к таблице XXX <ресурс 1> с <BeginPeriod> по <EndPeriod>.

Вариант номер два (если брать за основу первый вариант, то так)
Код: plaintext
1.
2.
3.
UID:UID уникальный ключ 
BeginDate: date/datetime not null. Начало актуальности сведений.
<Измерения> Разрезы, в которых ведутся сведения
<Ресурсы> Сведения

Пример:
Сотрудник ZZZ <ресурс 1> получил доступ <измерение> к таблице XXX <ресурс 2> с <BeginDate>.
Сотрудник ZZZ <ресурс 1> лишился доступа <измерение> к таблице XXX <ресурс 2> с <BeginDate>.

Какая структура из этих двух на ваш взгляд удобнее в использовании и почему?
На мой взгляд, первая структура удобнее для выборок, но при этом требует очень внимательного отношения к заполнению (не всегда и не везде есть триггеры). Так, например, недопустимы два и более незакрытых периода для тождественных наборов ресурсов.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35729540
egorych
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
рекомендую ознакомиться с холиварчегом на заданную тему: тынц!
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35729550
vinger4
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Почему не хотите время тянуть в первичный ключ?
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35729589
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
vinger4Почему не хотите время тянуть в первичный ключ?потому что это неправильно.
Подумайте о двух изменениях, сделанных в одну секунду.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35729704
Фотография bootty
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
egorychрекомендую ознакомиться с холиварчегом на заданную тему: тынц!
Благодарю, попробую осилить :)

vinger4Почему не хотите время тянуть в первичный ключ?
Потому что в таблице должны храниться результаты измерений множества ресурсов. Для значительной части ресурсов это будет просто дата, без времени (даже из примера видно, логично давать доступ с какой-то даты, без учета времени). Так же существует отличная от нуля вероятность, что произойдет попытка записать два события в один момент времени.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35729854
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35729862
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Naf Шаблон: Периодические сведения
С уважением, Naf
гоню, с этого же и началось :-)
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35729982
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Какая структура из этих двух на ваш взгляд удобнее в использовании и почему?

Никакая из приведенных. Во-первых, следует различать не только номинальную актуальность данных. Во-вторых, база данных - это связанные данные; концентрироваться стоит не на регистрации дат и их количестве, что тривиально, а на связанных изменениях. В-третьих, следует понимать, что извлечение истории изменений как правило происходит гораздо реже, чем использование актуальных данных.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35730144
Фотография bootty
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621Во-первых, следует различать не только номинальную актуальность данных.
Какие еще бывают актуальности?

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

guest_20040621В-третьих, следует понимать, что извлечение истории изменений как правило происходит гораздо реже, чем использование актуальных данных.
Правильно ли понимаю, что Вами предлагается отдельно иметь актуальное состояние + отдельно историю изменений?
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35730175
Фотография proposed amendment
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
boottyВас не затруднит развернуть мысль? Не совсем понятно, куда клоните.

вероятно что-то в духе

UpdateID
UpdateDate
UserName
TableName
FieldName
UpdatedValue
ValueDataType
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35730200
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Первая удобнее в запросах, почему, уже обсасывали не раз.
Но вторая удобнее для пользователя, если в каждый момент времени он либо предоставляет, либо отнимает доступ (возможно, это даже разные люди). Так например, по ошибке в БД может отсутствовать запись о предоставлении доступа.
Тогда при первом варианте реализации пользователь не сможет провести операцию отъёма доступа, которого нет в БД.
При втором варианте реализации он просто сделает нужную запись. Проблемой отсутствия записи о предоставлении доступа будут заниматься другие люди.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35730234
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Какие еще бывают актуальности?

Естественный жизненный цикл сущности и регистрация его фрагмента в базе данных.

> Не совсем понятно, куда клоните.

Была лавка "Рога и копыта". Благополучно закончилась. Что Вы намерены делать с данными, связанными с этой лавкой?

> отдельно иметь актуальное состояние + отдельно историю изменений?

Не обязательно. Как история будет храниться, регистрироваться и извлекаться - дело десятое. Важно, чтобы актуальные данные можно было получить быстро и просто.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35730247
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Belyvinger4Почему не хотите время тянуть в первичный ключ?потому что это неправильно.
Подумайте о двух изменениях, сделанных в одну секунду.

Если подумать, то разрулить можно. Есть несколько стратегий. Например, 1) запрещать изменения одной секундой, 2) затирать предыдущие данные и т.п. Всё равно от PK в таких таблицах мало толку, так лучше использовать какой нибудь более осмысленный ключ.


2 bootty , уточните семантику дат. Это фактические даты предоставления/лишения доступа или просто системные даты изменения атрибутов записи? Т.е. это история изменений записи БД, или изменений объекта документирования/управления?
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35730258
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
guest_20040621
> отдельно иметь актуальное состояние + отдельно историю изменений?

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

Настоящий уровень абстракции не позволяет судить о производительности. Так что не стоит бежать впереди паровоза.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35730285
Фотография bootty
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
proposed amendmentboottyВас не затруднит развернуть мысль? Не совсем понятно, куда клоните.

вероятно что-то в духе

UpdateID
UpdateDate
UserName
TableName
FieldName
UpdatedValue
ValueDataType
Вообще не в ту сторону думал, если честно. Поэтому интересно услышать автора...
Если есть ValueDataType (что все же скорее является признаком FieldName), то можно и OldValue :)

guest_20040621> Не совсем понятно, куда клоните.

Была лавка "Рога и копыта". Благополучно закончилась. Что Вы намерены делать с данными, связанными с этой лавкой?
В общем случае ничего. А зачем? :)

expla 2 bootty , уточните семантику дат. Это фактические даты предоставления/лишения доступа или просто системные даты изменения атрибутов записи? Т.е. это история изменений записи БД, или изменений объекта документирования/управления?
Первое, т.е. не системные даты.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35730318
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
bootty
expla 2 bootty , уточните семантику дат. Это фактические даты предоставления/лишения доступа или просто системные даты изменения атрибутов записи? Т.е. это история изменений записи БД, или изменений объекта документирования/управления?
Первое, т.е. не системные даты.

Тогда наверное для GUI подойдёт вариант номер два , а для отчётов и пр. фоновых процессов можно сделать материализованное представление первичных данных в форме вариант номер раз .
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35730328
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
поскольку доступ может быть предоставлен как на определенный срок, так и до отмены, то изначальная дилемма бессмысленна
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35730407
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dogenпоскольку доступ может быть предоставлен как на определенный срок, так и до отмены, то изначальная дилемма бессмысленна

Срок предоставления доступа это плановый показатель, фактическое изъятие доступа нужно фиксировать отдельно. Тогда в вариант номер два в записи типа "получил доступ" нужно предусмотреть атрибут - срок предоставления. Когда сотрудник фактически лишится доступа, нужно быдет завести запись типа "лишился доступа". При этом даты могут и не совпадать как в большую так и в меньшую стороны.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35730595
Фотография bootty
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dogenпоскольку доступ может быть предоставлен как на определенный срок, так и до отмены, то изначальная дилемма бессмысленнаПричинно-следственную связь не объясните? :)
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35730769
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> В общем случае ничего.

Тогда не употребляйте буквосочетания "история изменений" и "база данных". Потому как в общем случае в любой момент времени имеете кашу вместо данных.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35730773
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
explaЕсли подумать, то разрулить можно. Есть несколько стратегий. Например, 1) запрещать изменения одной секундой, 2) затирать предыдущие данные и т.п. Всё равно от PK в таких таблицах мало толку, так лучше использовать какой нибудь более осмысленный ключ.Да... цирк уехал, а клоуны остались.

Разрулить,конечно, это все можно. И даже такими бредовыми способами как предложено, вот только зачем?
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35730904
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
BelyexplaЕсли подумать, то разрулить можно. Есть несколько стратегий. Например, 1) запрещать изменения одной секундой, 2) затирать предыдущие данные и т.п. Всё равно от PK в таких таблицах мало толку, так лучше использовать какой нибудь более осмысленный ключ.Да... цирк уехал, а клоуны остались.

Разрулить,конечно, это все можно. И даже такими бредовыми способами как предложено, вот только зачем?

Если не знаете, то какая вам разница? Лично я успешно пользуюсь вторым способом, в силу того, что бизнес логика это допускает.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35730953
explaПервая удобнее в запросах, почему, уже обсасывали не раз.
Но вторая удобнее для пользователя, если в каждый момент времени он либо предоставляет, либо отнимает доступ (возможно, это даже разные люди). Так например, по ошибке в БД может отсутствовать запись о предоставлении доступа.
Тогда при первом варианте реализации пользователь не сможет провести операцию отъёма доступа, которого нет в БД.
При втором варианте реализации он просто сделает нужную запись. Проблемой отсутствия записи о предоставлении доступа будут заниматься другие люди.

Если в Базе Данных не было записи о предоставлении доступа сотруднику (который хотят отменить), то как нужный метод проверял наличие данного доступа у нужного сотрудника?
По листочку из тетрадки? А если такого проверяющего доступ метода нет, то зачем тогда нужно отменять доступ, если этот доступ все равно никаким методом не проверяется?
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35731015
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
НеизвестныйexplaПервая удобнее в запросах, почему, уже обсасывали не раз.
Но вторая удобнее для пользователя, если в каждый момент времени он либо предоставляет, либо отнимает доступ (возможно, это даже разные люди). Так например, по ошибке в БД может отсутствовать запись о предоставлении доступа.
Тогда при первом варианте реализации пользователь не сможет провести операцию отъёма доступа, которого нет в БД.
При втором варианте реализации он просто сделает нужную запись. Проблемой отсутствия записи о предоставлении доступа будут заниматься другие люди.

Если в Базе Данных не было записи о предоставлении доступа сотруднику (который хотят отменить), то как нужный метод проверял наличие данного доступа у нужного сотрудника?
По листочку из тетрадки? А если такого проверяющего доступ метода нет, то зачем тогда нужно отменять доступ, если этот доступ все равно никаким методом не проверяется?

Не стал вчитываться... Суть в том, что в БД может храниться не первоисточник, а его реплика. Например есть внешняя АС управления турникетами на проходных предприятия. И есть система кадрового учёта, которая напрямую не связана с первой системой. Понятно, есть процесс provisioning и т.п.. В этом случае доступ сотруднику может быть предоставлен не через отдел кадров, а как то иначе, или записи потеряются, так что в кадровой системе не будет записи о предоставлении доступа (это конечно не правильно, но такова жизнь, и есть конторы, которые платят за то, чтобы так не было). Зато перед увольнением кадровик через свою систему может завести заявку на отключение всех возможных доступов, даже тех, что вообще не зарегистрированы ни в кадрах ни в СБ и проверять тут ничего не нужно.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35731037
explaНе стал вчитываться... Суть в том, что в БД может храниться не первоисточник, а его реплика. Например есть внешняя АС управления турникетами на проходных предприятия. И есть система кадрового учёта, которая напрямую не связана с первой системой. Понятно, есть процесс provisioning и т.п.. В этом случае доступ сотруднику может быть предоставлен не через отдел кадров, а как то иначе, или записи потеряются, так что в кадровой системе не будет записи о предоставлении доступа (это конечно не правильно, но такова жизнь, и есть конторы, которые платят за то, чтобы так не было). Зато перед увольнением кадровик через свою систему может завести заявку на отключение всех возможных доступов, даже тех, что вообще не зарегистрированы ни в кадрах ни в СБ и проверять тут ничего не нужно.

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

Хорошая точка зрения. Безотносительно кризиса.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35731062
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Неизвестный,

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

Хорошая точка зрения. Безотносительно кризиса.

Некошерно.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35731683
Фотография bootty
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621Тогда не употребляйте буквосочетания "история изменений" и "база данных". Потому как в общем случае в любой момент времени имеете кашу вместо данных.Судя по Вашему тону, у Вас есть другая еврсия ответа на заданный Вами же вопрос. Судя по этому же тону, Вы очень гордитесь Вашей еврсией, но проблема в том, что "передача знаний должна быть ограничена и оплачиваема".
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35731728
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Судя по Вашему тону, у Вас есть другая еврсия ответа на заданный Вами же вопрос.

И не одна. С помощью наводящих вопросов хотелось помочь задавшему вопрос самостоятельно найти варианты правильных ответов. Если задавший вопрос не хочет думать головой - это его проблемы. Значит, он так и останется конкурентом китайских пионеров.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35731838
Фотография bootty
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
guest_20040621С помощью наводящих вопросов хотелось помочь задавшему вопрос самостоятельно найти варианты правильных ответов. Если задавший вопрос не хочет думать головой - это его проблемы.Задавший вопрос сейчас не готов выйти на предлагаемый уровень абстракции, его интересует решение конкретной и не очень глобальной задачи. Если "ментор" не хочет/не может задать доступные для понимания наводящие вопросы, а начинает пространные теоретические рассуждения, то это, конечно, тоже проблема задавшего вопрос, но самого "ментора" такое поведение не украшает.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35732382
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
explaDogenпоскольку доступ может быть предоставлен как на определенный срок, так и до отмены, то изначальная дилемма бессмысленна

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

Выдан доступ - событие, прекращен доступ - событие. Их надо регистрировать. "Интервал доступа" - хрень, которая никому не нужна.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35732448
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dogen

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

"Интервал доступа" не хрень, а состояние. В зависимости от задачи может быть полезен как тот, так и другой формализм.

"Интервал доступа" может быть полезен в материализованном виде. Например, в конторе кто то спёр ноутбук со стола, мы ведём следствие. Нужно определить, кто (who) имел доступ в кабинет :room в день [:start, :end], когда ноутбук исчез. Вот тут и будут полезны "интервалы доступа" - access. Простой запрос позволяет получить ответ на этот вопрос.

Код: plaintext
1.
2.
3.
4.
select distinct who
from access a
where
  room = :room and
  :start <= revoke and grant <= :end;

Можно найти ещё много ситуаций.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35732466
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
boottyDogenпоскольку доступ может быть предоставлен как на определенный срок, так и до отмены, то изначальная дилемма бессмысленнаПричинно-следственную связь не объясните? :)я не думал, что вопрос всего лишь о примитивной регистрации выданного доступа :) не вчитался, уж простите
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35732477
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
expla
"Интервал доступа" не хрень, а состояние. В зависимости от задачи может быть полезен как тот, так и другой формализм.

Можно найти ещё много ситуаций.

Можно, не спорю. Но придется тогда рассматривать все возможные случаи потери данных об отобранном или выданном доступе и вероятность наступления таких случаев... Если в общем случае, то лучше не умножать сущностей. Выдали права, забрали, приказы с датами... а для наличия доступа сущность надо бы заводить только если это оправдано в конкретной реализации.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35732538
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Dogen,

"придется тогда рассматривать все возможные случаи потери данных "

здесь случаев, согласитесь, всего 4 (все Ок, нет одного из событий или нет всех событий). Почему бы их и не рассмореть? Наконец, можно использовать какую либо общую стратегию исправления/обхода ошибок, для обработки всех ситуаций.

"Выдали права, забрали, приказы с датами... "

просто автоматизировать систему которая работает как компьютер. Попробуйте автоматизировать хаос.

"сущность надо бы заводить только если это оправдано в конкретной реализации"

естественно. В противном случае это деньги на ветер, а потом эта сущность сама умрёт, ибо всё что не живёт - умирает.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35732623
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
explaПростой запрос позволяет получить ответ на этот вопрос.а такой запрос считается сложным, чтоли?

Код: 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.
with ev as
(
-- Тестовые данные
SELECT 'GRANT'  access_act, to_date('10.10.2008','DD.MM.YYYY') as dt, 'u1' as usr from dual union all
SELECT 'REVOKE' access_act, to_date('14.10.2008','DD.MM.YYYY') as dt, 'u1' as usr from dual union all
SELECT 'GRANT'  access_act, to_date('22.10.2008','DD.MM.YYYY') as dt, 'u1' as usr from dual union all
SELECT 'GRANT'  access_act, to_date('11.11.2008','DD.MM.YYYY') as dt, 'u2' as usr from dual union all
SELECT 'GRANT'  access_act, to_date('09.10.2008','DD.MM.YYYY') as dt, 'u3' as usr from dual union all
SELECT 'REVOKE' access_act, to_date('20.10.2008','DD.MM.YYYY') as dt, 'u3' as usr from dual union all
SELECT 'GRANT'  access_act, to_date('12.12.2008','DD.MM.YYYY') as dt, 'u3' as usr from dual
)

-- кто имел доступ на указанную дату
SELECT usr
FROM ev
WHERE ev.access_act = 'GRANT'
  and (ev.usr,ev.dt) in
  (SELECT ev1.usr, max(ev1.dt) FROM ev ev1
   WHERE ev1.dt <= to_date('01.11.2008','DD.MM.YYYY') GROUP BY ev1.usr)
union
-- Кто новый получил доступ в интервале
SELECT usr
FROM ev 
WHERE ev.access_act = 'GRANT'
  and ev.dt between to_date('01.11.2008','DD.MM.YYYY') and to_date('01.12.2008','DD.MM.YYYY')
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35732803
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bely,

если вам платят за объём кода, то я за вас спокоен.

Для особо одарённых - "простой" означает, что проше быть не может.

На таком тривиальном примере сложно оценить прелесть подхода. Добавьте для приличия ещё каие нибудь условия, типа "сотрудник был на работе", "дверь в комнату была не под охраной" и т.п..
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35733072
Фотография bootty
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Dogenя не думал, что вопрос всего лишь о примитивной регистрации выданного доступа :) не вчитался, уж проститеВопрос в структуре для хранения истории событий. Разрешение/запрещение доступа, изменение цены товара, изменение какого-либо признака сущности с какого-то момента.

А здесь почему-то все прицепились к одному конкретному примеру...
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35733135
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
boottyА здесь почему-то все прицепились к одному конкретному примеру...

Так это твоя забота направлять дискуссию в нужное русло. Нарисуй другой пример, все прицепятся к нему.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35733179
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
boottyDogenя не думал, что вопрос всего лишь о примитивной регистрации выданного доступа :) не вчитался, уж проститеВопрос в структуре для хранения истории событий.

Сформулировал задачу?
События не имеют протяжённости во времени (в отличии от их последствий), так что Вариант номер раз в такой постановке не катит. Если интересуют и события и состояния, количество вариантов возрастает.
Ещё, в природе не существует событий, как не существует точек, это математическая абстракция. Так что твоя модель может быть не вполне адекватной в каждом конкретном случае.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35733417
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
explaесли вам платят за объём кода, то я за вас спокоен. мне платят за то, что такие задачи не вызывают у меня проблем.
explaДля особо одарённых - "простой" означает, что проше быть не может.Простой код - не значит самый быстрый.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35733539
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
BelyexplaДля особо одарённых - "простой" означает, что проше быть не может.Простой код - не значит самый быстрый.

Я про это и не говорил, но раз уж вы напросились, могу утверждать, что на выбраной мною платформе ваш код проиграет в производительности. И вполне вероятно, что на выбранных мною задачах подобного класса, ваша работа будет стоить дороже работы студента со стажем программирования запросов в один год и займёт больше времени.
Естественно, вы на своей платформе можете показать обратный результат и работать за еду.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35734449
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
explaИ вполне вероятно, что на выбранных мною задачах подобного класса, ваша работа будет стоить дороже работы студента со стажем программирования запросов в один год и займёт больше времени.
Естественно, вы на своей платформе можете показать обратный результат и работать за еду. Какой-то Вы на жись обиженный...
Работа студента будет дешевле ингода, но вот быстрее - сомнительно :)

И хватает на еду не только мне, но и семье. И на хлеб и на масло :)
Чего и вам желаю.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35734565
Фотография bootty
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
explaСобытия не имеют протяжённости во времени (в отличии от их последствий), так что Вариант номер раз в такой постановке не катит. Если интересуют и события и состояния, количество вариантов возрастает.Интересуют и события, и состояния. Предполагаю, чаще будет требоваться знать состояние.
explaЕщё, в природе не существует событий, как не существует точек, это математическая абстракция. Так что твоя модель может быть не вполне адекватной в каждом конкретном случае.Ок, другой пример:
Номенклатура ZZZZZZ <ресурс 1> имеет цену <измерение 1> с <BeginDate>.
Насколько адекватно, на Ваш взгляд?
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35734632
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
bootty,

номенклатура такая же абстракция, как и событие, так что ИМХО, здесь всё в порядке. И вообще, с утра как то не придумывается, где может быть плохо. Наверное, даже и не может, потому как БД уже имеет дело с абстракцией реального мира.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35734660
ййййййййй
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
explaНеизвестный,

В кризис можно и за еду поработать... И не надо меня переубеждать. Ник expla всегда прав, а у его владельца своя голова есть и она не всегда разделяет мнение ника.
Плохой хозяин у Вашей головы.
За еду нельзя работать, даже в кризис.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35734669
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bely
Работа студента будет дешевле ингода, но вот быстрее - сомнительно :)


Вам платят меньше чем студентам?

Bely
И хватает на еду не только мне, но и семье. И на хлеб и на масло :)
Чего и вам желаю.


Вот уж не надо! Я предпочитаю питаться более разнообразно.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35734692
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
йййййййййПлохой хозяин у Вашей головы.
За еду нельзя работать, даже в кризис.

Это Вы гастарбайтерам на закрытой стройке расскажите.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35734748
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
explaВам платят меньше чем студентам? Когда заканчиваются доводы с трассировками и примерами, начинаются понты и словоблудье.

по существу есть что сказать? С примерами и трассировками?
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35734911
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bely,

я вас за язык не тянул.

вам очевидные вещи нужно продемонстрировать?

Код: 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.
drop table expla1_tmp;
drop table expla2_tmp;
create table expla1_tmp
(
  oid number,
  frd date,
  tod date
);

create table expla2_tmp
(
  oid number,
  frd date,
  op char( 1 )
);


insert into expla1_tmp
(select level, sysdate - level, sysdate - level +  1 
from dual
connect by level <  1000000 );

insert into expla2_tmp
select oid, frd, 'B'
from expla1_tmp
union all
select oid, tod, 'E'
from expla1_tmp
;

commit;
set timing on
select oid
  from
    expla1_tmp
  where
    sysdate- 5  between frd and tod;

select oid
  from
    expla2_tmp m
  where
    op = 'B'
    and (oid, frd) in
    ( select i.oid, max(i.frd)
        from
          expla2_tmp i
        where
          i.frd <= sysdate- 5 
        group by i.oid
    )
union
select oid
  from
    expla2_tmp m
  where
    op = 'B'
    and frd between sysdate- 5  and sysdate- 4 ;


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
SQL> set timing on
SQL> select oid
  2    from
  3      expla1_tmp
  4    where
  5      sysdate-5 between frd and tod;

no rows selected

Elapsed: 00:00:00.57
SQL> 

Завершение второго запроса пока ожидаю....

Ещё нужны доводы?
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35735100
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Те же яйца только с индексом... и свой запрос исправил (не оттуда его скопировал).


Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
create index expla1_ix_tmp
on expla1_tmp(oid, frd, tod);

create index expla2_ix_tmp
on expla2_tmp(oid, frd);


set timing on
select oid
  from
     expla1_tmp
  where
    sysdate- 5  <= tod and frd <= sysdate- 4 ;

Код: 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.
       OID
----------
         4
         5

Elapsed: 00:00:01.04

SQL> 
SQL> select oid
  2    from
  3      expla2_tmp m
  4    where
  5      op = 'B'
  6      and (oid, frd) in
  7      ( select i.oid, max(i.frd)
  8          from
  9            expla2_tmp i
 10          where
 11            i.frd <= sysdate-5
 12          group by i.oid
 13      )
 14  union
 15  select oid
 16    from
 17      expla2_tmp m
 18    where
 19      op = 'B'
 20      and frd between sysdate-5 and sysdate-4;

       OID
----------
         4
         5

Elapsed: 00:00:31.64

20:5 и 31:1 - неплохой результат.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35735378
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
boottyВопрос в структуре для хранения истории событий . Разрешение/запрещение доступа, изменение цены товара, изменение какого-либо признака сущности с какого-то момента.

А здесь почему-то все прицепились к одному конкретному примеру...
Не побоюсь сказать банальность, но ответ содержится в вопросе.

Что касается необходимости отражать в структуре БД состояния - для обсуждения этого аспекта вы слишком узко (или наоборот, неконкретно? :) ) ставите вопросы.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35735386
Фотография Dogen
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
йййййййййЗа еду нельзя работать, даже в кризис.

Когда как, товарищ. Рады за то, что вы можете делать такие заявления.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35736516
Фотография bootty
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
DogenЧто касается необходимости отражать в структуре БД состояния - для обсуждения этого аспекта вы слишком узко (или наоборот, неконкретно? :) ) ставите вопросы.Согласен, виноват. Но ниже уже было другое:boottyИнтересуют и события, и состояния. Предполагаю, чаще будет требоваться знать состояние.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35736953
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
expla,
Более реальные тестовые данные.
Но до тех пор, пока FULL TABLE SCAN будет выгоднее досьупа по индексу, тестировать бесполезно.

Код: 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.
drop index index expla1_ix_tmp
/
drop index index expla2_ix_tmp
/
drop table expla1_tmp
/
drop table expla2_tmp
/

--truncate table expla1_tmp
--/
--truncate table expla2_tmp
--/
create table expla1_tmp
(
  oid number,
  frd date,
  tod date
)
/
create table expla2_tmp
(
  oid number,
  frd date,
  op char( 1 )
)
/


-- создаем тестовые данные так, что объектов 100 видов,
-- длительность предоставления доступа - 50 дней.
insert into expla1_tmp
select mod(level, 100 ), sysdate - level, sysdate - level +  50 
from dual
connect by level <  1000000 
/
insert into expla2_tmp
select oid, frd, 'B'
from expla1_tmp
union all
-- Добавляем только случившиеся отключения доступа --
select oid, tod, 'E'
from expla1_tmp
where tod < sysdate
/

create index expla1_ix_tmp
on expla1_tmp(oid, frd, tod)
/

create index expla2_ix_tmp
on expla2_tmp(oid, frd)
/

-- Собираем статистику, не забываем про CBO --
analyze table  expla1_tmp  compute statistics
/
analyze table expla2_tmp  compute statistics
/
analyze index expla1_ix_tmp  compute statistics
/
analyze index expla2_ix_tmp  compute statistics
/


теперь, собственно запросы.

Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
SQL> set autotrace on
SQL> select oid
   2     from
   3        expla1_tmp
   4     where
   5       sysdate- 50000  <= tod and frd <= sysdate- 50000 + 60 ;

       OID
----------
         40 
......
         49 

 110  rows selected.


Execution Plan
----------------------------------------------------------
    0       SELECT STATEMENT Optimizer=CHOOSE (Cost= 788  Card= 2500  Bytes=
           40000 )

    1      0    TABLE ACCESS (FULL) OF 'EXPLA1_TMP' (Cost= 788  Card= 2500  By
          tes= 40000 )





Statistics
----------------------------------------------------------
           0   recursive calls
           0   db block gets
        3345   consistent gets
        3330   physical reads
           0   redo size
        1410   bytes sent via SQL*Net to client
         572   bytes received via SQL*Net from client
          18   SQL*Net roundtrips to/from client
           0   sorts (memory)
           0   sorts (disk)
         110   rows processed

SQL> 
SQL> 

SQL> 
SQL> select oid  
   2   from  expla2_tmp m  
   3   where  op = 'B'
   4     and (oid, frd) in  ( select i.oid, max(i.frd)  from expla2_tmp i 
   5                          where  i.frd <= sysdate- 5000   group by i.oid) 
   6   union all  
   7   select oid from  expla2_tmp m1
   8   where m1.op = 'B' and m1.frd between sysdate- 5000  and sysdate- 5000 + 60 
   9   ;

       OID
----------
          0 
          1 
          2 
.....
         98 
         99 

 110  rows selected.


Execution Plan
----------------------------------------------------------
    0       SELECT STATEMENT Optimizer=CHOOSE (Cost= 2605  Card= 2501  Bytes
          = 25032 )

    1      0    UNION-ALL
    2      1      TABLE ACCESS (BY INDEX ROWID) OF 'EXPLA2_TMP' (Cost= 4  Ca
          rd= 1  Bytes= 10 )

    3      2        NESTED LOOPS (Cost= 1404  Card= 1  Bytes= 32 )
    4      3          VIEW OF 'VW_NSO_1' (Cost= 1202  Card= 100  Bytes= 2200 )
    5      4            SORT (GROUP BY) (Cost= 1202  Card= 100  Bytes= 900 )
    6      5              TABLE ACCESS (FULL) OF 'EXPLA2_TMP' (Cost= 1195  C
          ard= 99997  Bytes= 899973 )

    7      3          INDEX (RANGE SCAN) OF 'EXPLA2_IX_TMP' (NON-UNIQUE) (
          Cost= 3  Card= 1 )

    8      1      FILTER
    9      8        TABLE ACCESS (FULL) OF 'EXPLA2_TMP' (Cost= 1201  Card= 25 
           00  Bytes= 25000 )





Statistics
----------------------------------------------------------
           0   recursive calls
           0   db block gets
       10175   consistent gets
        9278   physical reads
           0   redo size
        1410   bytes sent via SQL*Net to client
         572   bytes received via SQL*Net from client
          18   SQL*Net roundtrips to/from client
           1   sorts (memory)
           0   sorts (disk)
         110   rows processed

SQL> 
SQL> 
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35737037
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Belyexpla,
Более реальные тестовые данные.
Но до тех пор, пока FULL TABLE SCAN будет выгоднее досьупа по индексу, тестировать бесполезно.


Сделай стенд, чтобы полезно было. А то выходит, что ты гол в свои ворота забил.

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

Что время то не замерил? Пока я вижу Cost 2605:788 - многообещающее начало.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35737170
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
explaСделай стенд, чтобы полезно было. А то выходит, что ты гол в свои ворота забил. Не у всех есть куча времени, чтобы его тратить на исследования.
У меня его пока нет.

explaИндекс тут не используется не только и не столько из-за того что "выгоднее", а по фундаментальной причине.Это что за "фундаментальная причина" по которой в такой таблице не используется индекс?

explaЧто время то не замерил? Пока я вижу Cost 2605:788 - многообещающее начало. А что, consistent gets и physical reads - не подходят?
Время может от чего угодно зависеть, в том числе от текущей нагрузки на сервер, чертыханий на клиента, закупоренности сетки итд.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35737253
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bely,

1) понимаю... ведь тебе кучу кода писать приходится.

2) например так
Код: plaintext
1.
2.
alter table expla1_tmp modify (oid not null);
alter table expla2_tmp modify (oid not null);

3)
кого бодает consistent gets, physical reads кроме разработчика и DBA?

physical reads не сложно свести к 0.

что бы нивелировать влияние случайных факторов, к результату эксперимента применяют методы статистической обработки.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35737531
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
expla1) понимаю... ведь тебе кучу кода писать приходится.

[quot expla]кого бодает consistent gets, physical reads кроме разработчика и DBA?Мэээ... ну так мы на SQL.ru вроде а не на BLONDINKA.ru

вобщем - вот тестовые данные.
Добавлена строка сообщения, чтобы таблица не состояла из одних полей по которым идет поиск.
Кроме этого - переделан индекс по таблице с одной датой.

Код: 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.
drop table expla1_tmp
/
drop table expla2_tmp
/

create table expla1_tmp
(
  oid number NOT NULL,
  frd date NOT NULL,
  tod date NOT NULL,
  msg varchar2( 600 )
)
/
create table expla2_tmp
(
  oid number NOT NULL,
  frd date NOT NULL,
  op char( 1 ) NOT NULL,
  msg varchar2( 600 )
)
/


-- создаем тестовые данные так, что объектов 100 видов,
-- длительность предоставления доступа - 50 дней.
insert into expla1_tmp
select mod(level, 100 ), sysdate - level, sysdate - level +  50 
, 'Сообщение о предоставлении доступа к объекту:('||mod(level, 100 )||')'
from dual
connect by level <  1000000 
/
insert into expla2_tmp
select oid, frd, 'B', 'Сообщение о предоставлении доступа к объекту:('||oid||')'
from expla1_tmp
union all
-- Добавляем только случившиеся отключения доступа --
select oid, tod, 'E', 'Сообщение о снятии доступа к объекту:('||oid||')'
from expla1_tmp
where tod < sysdate
/

create index expla1_ix_tmp
on expla1_tmp(oid, frd, tod)
/

create index expla2_ix_tmp
on expla2_tmp(frd, oid)
/

-- Собираем статистику, не забываем про CBO --
analyze table  expla1_tmp  compute statistics
/
analyze table expla2_tmp  compute statistics
/
analyze index expla1_ix_tmp  compute statistics
/
analyze index expla2_ix_tmp  compute statistics
/

Далее запросы - поиск в диапазоне.
Код: plaintext
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.
39.
40.
41.
42.
43.
44.
45.
46.
47.
48.
49.
50.
51.
52.
53.
54.
55.
56.
57.
58.
59.
60.
61.
62.
63.
64.
65.
66.
67.
68.
69.
70.
71.
72.
73.
74.
75.
76.
77.
78.
79.
80.
81.
82.
83.
84.
85.
86.
87.
88.
89.
90.
91.
92.
93.
94.
95.
96.
97.
98.
99.
100.
101.
102.
103.
104.
105.
106.
107.
108.
109.
110.
111.
112.
113.
114.
115.
116.
117.
SQL> 
SQL> set autotrace on
SQL> select *  from  expla1_tmp
   2   where   sysdate- 500000  <= tod and frd <= sysdate- 500000 + 60 ;

       OID FRD       TOD
---------- --------- ---------
MSG
--------------------------------------------------------------------------------
         40   10 -MAR- 40   29 -APR- 40 
Сообщение о предоставлении доступа к объекту:( 40 )
......

         49   22 -NOV- 39   11 -JAN- 40 
Сообщение о предоставлении доступа к объекту:( 49 )


 110  rows selected.


Execution Plan
----------------------------------------------------------
    0       SELECT STATEMENT Optimizer=CHOOSE (Cost= 3502  Card= 2500  Bytes
          = 260000 )

    1      0    TABLE ACCESS (FULL) OF 'EXPLA1_TMP' (Cost= 3502  Card= 2500  B
          ytes= 260000 )





Statistics
----------------------------------------------------------
           0   recursive calls
           0   db block gets
       15724   consistent gets
       15706   physical reads
           0   redo size
       13091   bytes sent via SQL*Net to client
         572   bytes received via SQL*Net from client
          18   SQL*Net roundtrips to/from client
           0   sorts (memory)
           0   sorts (disk)
         110   rows processed

SQL> 
SQL> 

SQL> 
SQL> select * from  expla2_tmp m  
   2   where  op = 'B'  
   3     and (oid, frd) in  ( select i.oid, max(i.frd)  from expla2_tmp i 
   4                          where  i.frd <= sysdate- 500000   group by i.oid) 
   5   union all
   6   select * from  expla2_tmp m1
   7   where m1.op = 'B' and m1.frd between sysdate- 500000  and sysdate- 500000 + 60 
   8   ;

       OID FRD       O
---------- --------- -
MSG
--------------------------------------------------------------------------------
          0   19 -APR- 95  B
Сообщение о предоставлении доступа к объекту:( 0 )
......................

         40   10 -MAR- 40  B
Сообщение о предоставлении доступа к объекту:( 40 )


 110  rows selected.


Execution Plan
----------------------------------------------------------
    0       SELECT STATEMENT Optimizer=CHOOSE (Cost= 6431  Card= 2501  Bytes
          = 225112 )

    1      0    UNION-ALL
    2      1      TABLE ACCESS (BY INDEX ROWID) OF 'EXPLA2_TMP' (Cost= 4  Ca
          rd= 1  Bytes= 90 )

    3      2        NESTED LOOPS (Cost= 367  Card= 1  Bytes= 112 )
    4      3          VIEW OF 'VW_NSO_1' (Cost= 66  Card= 100  Bytes= 2200 )
    5      4            SORT (GROUP BY) (Cost= 66  Card= 100  Bytes= 900 )
    6      5              INDEX (RANGE SCAN) OF 'EXPLA2_IX_TMP' (NON-UNIQU
          E) (Cost= 59  Card= 99997  Bytes= 899973 )

    7      3          INDEX (RANGE SCAN) OF 'EXPLA2_IX_TMP' (NON-UNIQUE) (
          Cost= 3  Card= 1 )

    8      1      FILTER
    9      8        TABLE ACCESS (BY INDEX ROWID) OF 'EXPLA2_TMP' (Cost= 60 
           64  Card= 2500  Bytes= 225000 )

   10      9          INDEX (RANGE SCAN) OF 'EXPLA2_IX_TMP' (NON-UNIQUE) (
          Cost= 31  Card= 9000 )





Statistics
----------------------------------------------------------
           0   recursive calls
           0   db block gets
        3423   consistent gets
        3078   physical reads
           0   redo size
       12574   bytes sent via SQL*Net to client
         572   bytes received via SQL*Net from client
          18   SQL*Net roundtrips to/from client
           1   sorts (memory)
           0   sorts (disk)
         110   rows processed

SQL> 

И еще - другая дата (для таблицы с одной датой)
Код: 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.
SQL> 
SQL> select * from  expla2_tmp m  
   2   where  op = 'B'  
   3     and (oid, frd) in  ( select i.oid, max(i.frd)  from expla2_tmp i 
   4                          where  i.frd <= sysdate- 900000   group by i.oid) 
   5   union all
   6   select * from  expla2_tmp m1
   7   where m1.op = 'B' and m1.frd between sysdate- 900000  and sysdate- 900000 + 60 
   8   ;

       OID FRD       O
---------- --------- -
MSG
--------------------------------------------------------------------------------
          0   19 -NOV- 56  B
Сообщение о предоставлении доступа к объекту:( 0 )
..............
         40   18 -JAN- 55  B
Сообщение о предоставлении доступа к объекту:( 40 )


 110  rows selected.


Execution Plan
----------------------------------------------------------
    0       SELECT STATEMENT Optimizer=CHOOSE (Cost= 6431  Card= 2501  Bytes
          = 225112 )

    1      0    UNION-ALL
    2      1      TABLE ACCESS (BY INDEX ROWID) OF 'EXPLA2_TMP' (Cost= 4  Ca
          rd= 1  Bytes= 90 )

    3      2        NESTED LOOPS (Cost= 367  Card= 1  Bytes= 112 )
    4      3          VIEW OF 'VW_NSO_1' (Cost= 66  Card= 100  Bytes= 2200 )
    5      4            SORT (GROUP BY) (Cost= 66  Card= 100  Bytes= 900 )
    6      5              INDEX (RANGE SCAN) OF 'EXPLA2_IX_TMP' (NON-UNIQU
          E) (Cost= 59  Card= 99997  Bytes= 899973 )

    7      3          INDEX (RANGE SCAN) OF 'EXPLA2_IX_TMP' (NON-UNIQUE) (
          Cost= 3  Card= 1 )

    8      1      FILTER
    9      8        TABLE ACCESS (BY INDEX ROWID) OF 'EXPLA2_TMP' (Cost= 60 
           64  Card= 2500  Bytes= 225000 )

   10      9          INDEX (RANGE SCAN) OF 'EXPLA2_IX_TMP' (NON-UNIQUE) (
          Cost= 31  Card= 9000 )





Statistics
----------------------------------------------------------
           0   recursive calls
           0   db block gets
         968   consistent gets
           8   physical reads
           0   redo size
       12574   bytes sent via SQL*Net to client
         572   bytes received via SQL*Net from client
          18   SQL*Net roundtrips to/from client
           1   sorts (memory)
           0   sorts (disk)
         110   rows processed

SQL> 

Заставить запрос ходить по индексу с двумя датами - мне так и не удалось.
Позже выложу еще запросы с поиском доступа н указанную дату, а не на диапазон.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35737708
expla
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bely,

Код: 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.
col msg noprint
set autotrace on
select /*+ index_ss(t expla1_ix_tmp) */ *
  from  expla1_tmp t
  where   sysdate-500000 <= tod and frd <= sysdate-500000+60;

       OID FRD      TOD                                                         
---------- -------- --------                                                    
         0 10.01.40 29.02.40                                                    
         1 09.01.40 28.02.40                                                    
...
        98 12.01.40 02.03.40                                                    
        99 11.01.40 01.03.40                                                    

110 rows selected.


Execution Plan
----------------------------------------------------------                      
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=112769 Card=250056 Bytes=26005824)                                                      
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'EXPLA1_TMP' (TABLE) (Cost=112769 Card=250056 Bytes=26005824)                                  
   2    1     INDEX (SKIP SCAN) OF 'EXPLA1_IX_TMP' (INDEX) (Cost=75176 Card=250056)                                                         
                                                                                
Statistics
----------------------------------------------------------                      
          0  recursive calls                                                    
          0  db block gets                                                      
        2253  consistent gets 
          0  physical reads                                                     
          0  redo size                                                          
      12727  bytes sent via SQL*Net to client                                   
        330  bytes received via SQL*Net from client                             
          9  SQL*Net roundtrips to/from client                                  
          0  sorts (memory)                                                     
          0  sorts (disk)                                                       
        110  rows processed                                                     

SQL> 
select * from  expla2_tmp m
    where  op = 'B'
      and (oid, frd) in  ( select i.oid, max(i.frd)  from expla2_tmp i
                           where  i.frd <= sysdate-500000  group by i.oid)
    union all
    select * from  expla2_tmp m1
    where m1.op = 'B' and m1.frd between sysdate-500000 and sysdate-500000+60
;

       OID FRD      O                                                           
---------- -------- -                                                           
        44 27.11.39 B                                                           
...
        40 10.03.40 B                                                           

110 rows selected.


Execution Plan
----------------------------------------------------------                      
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=783 Card=112 Bytes=11180)                                                               
   1    0   UNION-ALL                                                           
   2    1     TABLE ACCESS (BY INDEX ROWID) OF 'EXPLA2_TMP' (TABLE) (Cost=1 Card=1 Bytes=90)                                                
   3    2       NESTED LOOPS (Cost=764 Card=50 Bytes=5600)
   4    3         VIEW OF 'VW_NSO_1' (VIEW) (Cost=748 Card=100 Bytes=2200)                                                                  
   5    4           HASH (GROUP BY) (Cost=748 Card=100 Bytes=900)               
   6    5             INDEX (RANGE SCAN) OF 'EXPLA2_IX_TMP' (INDEX) (Cost=471 Card=999976 Bytes=8999784)                                    
   7    3         INDEX (RANGE SCAN) OF 'EXPLA2_IX_TMP' (INDEX) (Cost=1 Card=1)                                                             
   8    1     FILTER                                                            
   9    8       TABLE ACCESS (BY INDEX ROWID) OF 'EXPLA2_TMP' (TABLE)           
          (Cost=19 Card=62 Bytes=5580)                                          
  10    9         INDEX (RANGE SCAN) OF 'EXPLA2_IX_TMP' (INDEX) (Cost=1 Card=124)                                                           

Statistics
----------------------------------------------------------                      
          0  recursive calls                                                    
          0  db block gets                                                      
        3442  consistent gets                                                     
          0  physical reads                                                     
          0  redo size                                                          
      12220  bytes sent via SQL*Net to client                                   
        330  bytes received via SQL*Net from client                             
          9  SQL*Net roundtrips to/from client                                  
          0  sorts (memory)                                                     
          0  sorts (disk)                                                       
        110  rows processed                                                     

SQL> spool off


если переделать индекс

Код: plaintext
1.
2.
3.
4.
5.
6.
drop index expla1_ix_tmp
/
create index expla1_ix_tmp
on expla1_tmp(frd, tod, oid)
/
analyze index expla1_ix_tmp  compute statistics
/

То получаем

Код: 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.
select *
    from  expla1_tmp t
  where   sysdate-500000 <= tod and frd <= sysdate-500000+60;



110 rows selected.


Execution Plan
----------------------------------------------------------
   0      SELECT STATEMENT Optimizer=ALL_ROWS (Cost=921 Card=250056 Bytes=26005824)
   1    0   TABLE ACCESS (BY INDEX ROWID) OF 'EXPLA1_TMP' (TABLE) (Cost=921 Card=250056 Bytes=26005824)
   2    1     INDEX (RANGE SCAN) OF 'EXPLA1_IX_TMP' (INDEX) (Cost=331 Card=250056)

Statistics
----------------------------------------------------------
          1  recursive calls
          0  db block gets
        2114  consistent gets 
          0  physical reads
          0  redo size
      12728  bytes sent via SQL*Net to client
        330  bytes received via SQL*Net from client
          9  SQL*Net roundtrips to/from client
          0  sorts (memory)
          0  sorts (disk)
        110  rows processed

И, ИМХО, из-за замены union на union all в запрос таки ошибочка закралась, в случае i.frd = sysdate-500000 запись задвоится.

3442:2114.... Я доволен.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35740226
RodionAT
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
Предлагаю таблицу:
ИмяТаблицы, ИмяПоля, ДатаИзменения, Значение поля, Комментарии

А уж дальше извлекать данные по конкретному полю конкретной таблицы процедурами или функциями.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35740239
Naf
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RodionATПредлагаю таблицу:
ИмяТаблицы, ИмяПоля, ДатаИзменения, Значение поля, Комментарии

А уж дальше извлекать данные по конкретному полю конкретной таблицы процедурами или функциями.
НЕ НАДО! В 1С 7.7 так и было, ничего хорошего. Потом в 8 версии от этого ушли
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35740243
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RodionATПредлагаю таблицу:
ИмяТаблицы, ИмяПоля, ДатаИзменения, Значение поля, Комментарии

А уж дальше извлекать данные по конкретному полю конкретной таблицы процедурами или функциями.предлагаю запихнуть в такую таблицу миллионов 70 строк и посмотреть как быстро состарится полтьзователь от ожидания данных от отчетов, которые используют такую таблицу.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35740246
Фотография proposed amendment
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
RodionATПредлагаю таблицу:

боян первыйнах
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35768021
TsRV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Господа, не ломайте голову над велосипедом!

Период актуальности (время жизни и т.п. - называйте как хотите) - либо вектор, либо отрезок .
Два поля типа дата/время с возможностью нести Null-значения и все проблемы проектирования БД решены. Остальные мелочи - задача программного кода.


P.S.: На сегодня, конечно, есть теория гиперрациональных чисел, где время - это пространство... Но оно вам надо???
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35768130
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TsRVГоспода, не ломайте голову над велосипедом!

Период актуальности (время жизни и т.п. - называйте как хотите) - либо вектор, либо отрезок .
Два поля типа дата/время с возможностью нести Null-значения и все проблемы проектирования БД решены. Остальные мелочи - задача программного кода.


P.S.: На сегодня, конечно, есть теория гиперрациональных чисел, где время - это пространство... Но оно вам надо??? Это про Вас?
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35768349
TsRV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bely Это про Вас?

Bely, вы всегда усложняете себе жизнь из-за пары миллисекунд? Формула-1?
А Вы не задумывались, что когда-то преемнику Вашего "достояния" придется его разгребать???
Хорошо, если Вы пишете частные задачи и в них 3-4 таблицы!..

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

А быстродействие запроса - это еще спорный вопрос...
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35768351
TsRV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
TsRVBely Это про Вас?

Bely, вы всегда усложняете себе жизнь из-за пары миллисекунд? Формула-1?
А Вы не задумывались, что когда-то преемнику Вашего "достояния" придется его разгребать???
Хорошо, если Вы пишете частные задачи и в них 3-4 таблицы!..

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

А быстродействие запроса - это еще спорный вопрос...

Извиняюсь, варианты перепутал с пылу-жару...
Фотопленка - второй вариант. Первый предпочтительней.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35768773
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TsRVBely, вы всегда усложняете себе жизнь из-за пары миллисекунд? Формула-1?
А Вы не задумывались, что когда-то преемнику Вашего "достояния" придется его разгребать???
Хорошо, если Вы пишете частные задачи и в них 3-4 таблицы!..

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

А быстродействие запроса - это еще спорный вопрос...Судя по вашему ответу - вы с проблемой производительности при поиске по логу не сталкивались.
А у нас лог вот уже к полусотне миллионов строк подбирается.
И я не могу сказать пользователю, что отчет готовится медленно, но зато верно.
Приходится предпринимать меры, чтобы отчет готовился в ПРИЕМЛЕМОЕ время.
Да и размер табличек и индексов на таких объемах начинает становиться не таким безразличным.

PS: что касается кино и фото - если бы кино было бы настолько круто, то оно бы выдавило уже фото. Но у фотографий есть такие варианты использования, которые никогда нельзя будет выжать из кино. Подумайте о больших выдержках затвора...
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35768836
TsRV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
BelyА у нас лог вот уже к полусотне миллионов строк подбирается.

Не проще лог раскидать по периодам или вообще элементарно - в архив? Уверен, для оперативной работы необходимы лишь несколько сотен, может тысяч, последних записей...

BelyПодумайте о больших выдержках затвора...

Углубляться в мелочи можно до бесконечности. Об этом написано много специализированной литературы. В таком понимании мира - можно и бит разбить на составные части...


P.S.: Вы явно работаете не с тиражным ПО...
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35769076
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TsRVBelyА у нас лог вот уже к полусотне миллионов строк подбирается.Не проще лог раскидать по периодам или вообще элементарно - в архив? Уверен, для оперативной работы необходимы лишь несколько сотен, может тысяч, последних записей...Ну, сносить в архив дело хорошее, но вот только прозрачность теряется. И приходится генерить запросы вида
Код: plaintext
1.
2.
3.
4.
5.
6.
SELECT ... FROM log_1 
UNION ALL
SELECT ... FROM log_2
UNION ALL
SELECT ... FROM log_3 
UNION ALL
SELECT ... FROM log_arch
Что не добавляет прозрачности пониманию запросов и не всегда становится быстрее.

PS: судя по тому, что вы не сказали слово партиционирование, то оно вам не знакомо :)

TsRVBelyПодумайте о больших выдержках затвора...Углубляться в мелочи можно до бесконечности. Об этом написано много специализированной литературы. В таком понимании мира - можно и бит разбить на составные части... Чтобы понимать особенности - надо знать частности.
Все знают арифметику, но не все могут работать финансовыми директорами и бухгалтерами.

Почитайте еще вот это

TsRVP.S.: Вы явно работаете не с тиражным ПО...Я видел достаточно много тиражных систем, которые используют те же самые механизмы, что и наша нетиражная.
Так что это ровным счетом ничего не значит, кроме того, что у меня больше маневра - мы можем переделать нашу систему.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35769312
TsRV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
BelyНу, сносить в архив дело хорошее, но вот только прозрачность теряется. И приходится генерить запросы...
Bely, вы противоречите сами себе. А Ваши примеры реализации, описанные выше, не теряют прозрачности и не требуют генерации запросов?
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35769388
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TsRVBelyНу, сносить в архив дело хорошее, но вот только прозрачность теряется. И приходится генерить запросы...Bely, вы противоречите сами себе. А Ваши примеры реализации, описанные выше, не теряют прозрачности и не требуют генерации запросов?Вы правильно поняли. НЕ теряют прозрачности и НЕ требуют запросов с UNION -ами по нескольким таблицам.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35769419
TsRV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bely
SQL> select * from expla2_tmp m
2 where op = 'B'
3 and (oid, frd) in ( select i.oid, max(i.frd) from expla2_tmp i
4 where i.frd <= sysdate-900000 group by i.oid)
5 union all
6 select * from expla2_tmp m1
7 where m1.op = 'B' and m1.frd between sysdate-900000 and sysdate-900000+60
8 ;


Если это Вы считаете "прозрачным", то что для вас " НЕ прозрачное"?
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35769470
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TsRVЕсли это Вы считаете "прозрачным", то что для вас " НЕ прозрачное"? Здесь как раз запрос В ЛОБ.
Те, кто получил доступ ДО и те, кто получил доступ ВО ВРЕМЯ периода.

А теперь представьте, что надо сюда еще вклинить таблицу истории...

В заключении могу предложить поэкспериментировать с разными структурами, чтобы получить срез данных НА ОПРЕДЕЛЕННОЕ ВРЕМЯ для таблиц с одной и двумя датами.
Скорость выполнения Вас удивит.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35769605
TsRV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bely, а теперь попробуйте протестировать, допустим, следующую задачу: Для каждого кода выберем строку, максимально “приближенную” к требуемой дате

И поглядим, чьи решения универсальней и "шустрее"
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35769877
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TsRVBely, а теперь попробуйте протестировать, допустим, следующую задачу: Для каждого кода выберем строку, максимально “приближенную” к требуемой дате Ну точно "Астронавт проектирования".
Какой смысл в такой задаче?
Я не вижу ни одного реального применения для такого запроса.

А исследовать можно много чего .
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35769983
TsRV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bely, это аналитика. И подобные вариации у меня встречаются достаточно часто.
Видимо, Ваш проект не настолько интересен, как мои...
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35769996
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TsRVBely, это аналитика. И подобные вариации у меня встречаются достаточно часто.
Видимо, Ваш проект не настолько интересен, как мои... Видимо Вы не можете сформулировать сущность этого показателя.

Средняя температура по больнице никого не интересует.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35770012
TsRV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Причем тут температура и время? Вы не путаете топик?

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

Мне Вас жаль - скучно живете!
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35770052
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TsRVПричем тут температура и время? Вы не путаете топик?

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

Мне Вас жаль - скучно живете! Дык, вот он этот запрос.

Код: plaintext
SQL> select oid  \n   2   from  expla2_tmp m  \n   3   where  op = \'B\'\n   4     and (oid, frd) in  (select i.oid, max(i.frd)  from expla2_tmp i \n   5                          where  i.frd <= sysdate- 5000   group by i.oid) 
Только условия скорее всего развернуть надо.

А вот его сравнение с запросом по двум датам.

PS: точнее формулировать надо.
Для каждого кода выберем строку, максимально “приближенную” к требуемой дате
Вот даты:
1) 01.01.2009
2) 10.01.2009
Какая из них наиболее приближена к 02.01.2009 ?
а какая самая близкая из непрошедших?
это будут две разные даты...
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35770134
TsRV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Bely, у различных, даже однотипных, продуктов различные сроки годности (разделение на сорта, производителей и т.п. не учитываем), при этом дата их производства различна во времени:

Партия 1 : (==========)
Партия 2 : (==========)
Партия 3 : (==========)
Партия 3*: (=====)
... и т.д.

* - встречается, допустим, брак в упаковке, что приводит к сокращению сроков хранения (это расписано в ГОСТах).

Отстаиваемый Вами вариант историзма с одной "датой" в таких случаях негоден, потому как не хранит дату окончания срока годности...
У меня аналогичных задач встречается много, поэтому я всегда использую две даты в истории, даже если вторая, казалось бы, и ненужна...
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35770140
TsRV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Плин, пробелы покоцались :(

Партия 1 : ..(==========)
Партия 2 : ........(==========)
Партия 3 : ................................(==========)
Партия 3*: ...............................(=====)
... и т.д.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35770173
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> вариант историзма с одной "датой" в таких случаях негоден, потому как не хранит дату окончания
> срока годности...

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

Вам, юноша, следует хотя бы в общих чертах ознакомиться с историей вопроса, прежде чем рассказывать о своих ошибках.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35770186
Bely
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Участник
TsRVОтстаиваемый Вами вариант историзма с одной "датой" в таких случаях негоден, потому как не хранит дату окончания срока годности...Гм... а ничего, что у вас не история, а просто атрибуты у объекта?

История - это список всех изменений конкретного объекта.
У вас же ничего не меняется.

Для вашей задачи первая дата вобще не нужна. Нужна только одна дата - окончание срока годности. Дата когда было произведено ДЛЯ ИЗЛОЖЕННЫХ ВАМИ ЗАДАЧ - не нужны.
Соответственно - у вас не интервал годности, а просто два параметра.
Дата Выпуска.
Окончание срока годности.

PS: у меня в некоторых таблицах по 5-6 дат.
Это не значит, что я живу в 6 временных измерениях.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35770241
TsRV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
guest_20040621, вы в теме?

А что такое для колбасы срок годности, для имущества срок гарантийного использования, для самолета время полета в рейсе? Вам нужны еще примеры по использованию историзма???

Или в Вашем понимании историзм должен быть только где-то там, позади у чего-то, чего мы не знаем и уже никогда не увидим? Наверное, у Вас он есть только в логах?

Срок годности, история изменений... --- это все частные случаи!

И вот когда каждый из таких случаев программисты-одиночки не видят и начинают извращать по-своему - корпоративное приложение в целом получается одной большой кучей ***


==================
*** - скрипта
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35770341
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> вы в теме?

Больше, чем хотелось бы.

> А что такое для колбасы срок годности,

Атрибут.

> для имущества срок гарантийного использования,

Атрибут.

> для самолета время полета в рейсе

Атрибут.

> Вам нужны еще примеры по использованию историзма???

Ни один из приведенных примеров к истории изменений ни малейшего отношения не имеет.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35770459
TsRV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
1. Где-то уже писал: история - вектор/прямая/отрезок времени. Как вы это представляете одной датой? Или Вы рассматриваете только частность вектора? От даты А до следующей записи?
2. Вы хотите вести полный историзм с учетом сохранения изменений?

Вкратце:
Добавляем сущность : вставляем строку, генерим ID, date1 = date; date2 = null, обрабатываем остальные условности...
Изменяем сущность : date2=date-1, копируем сущность (в т.ч. ID!) - работаем уже с ней, date1=date, date2=null, обрабатываем остальные условности...
Удаляем сущность : date2=date-1, обрабатываем остальные условности...

Работает в любых случаях! Что еще универсальней, проще и быстрей можете предложить??????
Вы спорите по частным вопросам! Хватит плавать по дну!
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35770540
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Где-то уже писал:

И это не единственная Ваша ошибка. Писать (а тем более давать советы) нужно очень хорошо подумав.

> история - вектор/прямая/отрезок времени.

Применительно к базам данных история изменений - это регистрация состояний сущностей и связей в любой момент времени. Как следствие - возможность консистентного непротиворечивого полного снапшота на любую дату.
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35770790
TsRV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
guest_20040621бла-бла-бла...

Умный, разумный гость! Для начала зарегся, потом обсудим ваши эмоции...
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35770791
TsRV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
guest_20040621, кстати! По существу вопроса предложения есть???

Помнится, вопрос был поднят: " Оптимальная структура таблицы для хранения истории"...
Сначала дайте дельное слово, потом пытайтесь пыжиться, защищая его!!!!
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35770794
TsRV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
guest_20040621Применительно к базам данных...
Снова "частник"???

guest_20040621это регистрация состояний сущностей и связей в любой момент времени...
Как раз это мной и выведено сюда, на общее обозрение! У вас имеются на данное решение права???
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35770829
TsRV
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
Уффф, господа!

В чем проблемы? Если Вы решаете "глобальные" задачи на своих ноутбуках - то мне понятны ваши стремления!

Определите уровень решаемых ВАМИ задач!!!

------------------------------------------------------------
P.S.: Для проверки: гольный массив [ID, Parent_ID] - 0,175 млрд - 1,8 сек. (+/- 0,2 сек.)
...
Рейтинг: 0 / 0
Оптимальная структура таблицы для хранения истории...
    #35771083
guest_20040621
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Гость
> Как раз это мной и выведено сюда, на общее обозрение!

Хуже всего то, дружище, что Вы даже не понимаете, в чем Ваша ошибка.

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


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