|
|
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
... изменений чего-либо. Вариант номер раз (примерно как здесь ) Код: plaintext 1. 2. 3. 4. Пример: Сотрудник ZZZ <ресурс 1> имеет доступ <измерение 1> к таблице XXX <ресурс 1> с <BeginPeriod> по <EndPeriod>. Вариант номер два (если брать за основу первый вариант, то так) Код: plaintext 1. 2. 3. Пример: Сотрудник ZZZ <ресурс 1> получил доступ <измерение> к таблице XXX <ресурс 2> с <BeginDate>. Сотрудник ZZZ <ресурс 1> лишился доступа <измерение> к таблице XXX <ресурс 2> с <BeginDate>. Какая структура из этих двух на ваш взгляд удобнее в использовании и почему? На мой взгляд, первая структура удобнее для выборок, но при этом требует очень внимательного отношения к заполнению (не всегда и не везде есть триггеры). Так, например, недопустимы два и более незакрытых периода для тождественных наборов ресурсов. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 11:02 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
рекомендую ознакомиться с холиварчегом на заданную тему: тынц! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 11:17 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Почему не хотите время тянуть в первичный ключ? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 11:21 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
vinger4Почему не хотите время тянуть в первичный ключ?потому что это неправильно. Подумайте о двух изменениях, сделанных в одну секунду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 11:33 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
egorychрекомендую ознакомиться с холиварчегом на заданную тему: тынц! Благодарю, попробую осилить :) vinger4Почему не хотите время тянуть в первичный ключ? Потому что в таблице должны храниться результаты измерений множества ресурсов. Для значительной части ресурсов это будет просто дата, без времени (даже из примера видно, логично давать доступ с какой-то даты, без учета времени). Так же существует отличная от нуля вероятность, что произойдет попытка записать два события в один момент времени. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 11:59 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Шаблон: Периодические сведения С уважением, Naf ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 12:42 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 12:43 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
> Какая структура из этих двух на ваш взгляд удобнее в использовании и почему? Никакая из приведенных. Во-первых, следует различать не только номинальную актуальность данных. Во-вторых, база данных - это связанные данные; концентрироваться стоит не на регистрации дат и их количестве, что тривиально, а на связанных изменениях. В-третьих, следует понимать, что извлечение истории изменений как правило происходит гораздо реже, чем использование актуальных данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 13:15 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
guest_20040621Во-первых, следует различать не только номинальную актуальность данных. Какие еще бывают актуальности? guest_20040621Во-вторых, база данных - это связанные данные; концентрироваться стоит не на регистрации дат и их количестве, что тривиально, а на связанных изменениях. Вас не затруднит развернуть мысль? Не совсем понятно, куда клоните. guest_20040621В-третьих, следует понимать, что извлечение истории изменений как правило происходит гораздо реже, чем использование актуальных данных. Правильно ли понимаю, что Вами предлагается отдельно иметь актуальное состояние + отдельно историю изменений? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 14:07 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
boottyВас не затруднит развернуть мысль? Не совсем понятно, куда клоните. вероятно что-то в духе UpdateID UpdateDate UserName TableName FieldName UpdatedValue ValueDataType ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 14:19 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Первая удобнее в запросах, почему, уже обсасывали не раз. Но вторая удобнее для пользователя, если в каждый момент времени он либо предоставляет, либо отнимает доступ (возможно, это даже разные люди). Так например, по ошибке в БД может отсутствовать запись о предоставлении доступа. Тогда при первом варианте реализации пользователь не сможет провести операцию отъёма доступа, которого нет в БД. При втором варианте реализации он просто сделает нужную запись. Проблемой отсутствия записи о предоставлении доступа будут заниматься другие люди. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 14:25 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
> Какие еще бывают актуальности? Естественный жизненный цикл сущности и регистрация его фрагмента в базе данных. > Не совсем понятно, куда клоните. Была лавка "Рога и копыта". Благополучно закончилась. Что Вы намерены делать с данными, связанными с этой лавкой? > отдельно иметь актуальное состояние + отдельно историю изменений? Не обязательно. Как история будет храниться, регистрироваться и извлекаться - дело десятое. Важно, чтобы актуальные данные можно было получить быстро и просто. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 14:39 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Belyvinger4Почему не хотите время тянуть в первичный ключ?потому что это неправильно. Подумайте о двух изменениях, сделанных в одну секунду. Если подумать, то разрулить можно. Есть несколько стратегий. Например, 1) запрещать изменения одной секундой, 2) затирать предыдущие данные и т.п. Всё равно от PK в таких таблицах мало толку, так лучше использовать какой нибудь более осмысленный ключ. 2 bootty , уточните семантику дат. Это фактические даты предоставления/лишения доступа или просто системные даты изменения атрибутов записи? Т.е. это история изменений записи БД, или изменений объекта документирования/управления? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 14:43 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
guest_20040621 > отдельно иметь актуальное состояние + отдельно историю изменений? Не обязательно. Как история будет храниться, регистрироваться и извлекаться - дело десятое. Важно, чтобы актуальные данные можно было получить быстро и просто. Настоящий уровень абстракции не позволяет судить о производительности. Так что не стоит бежать впереди паровоза. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 14:46 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
proposed amendmentboottyВас не затруднит развернуть мысль? Не совсем понятно, куда клоните. вероятно что-то в духе UpdateID UpdateDate UserName TableName FieldName UpdatedValue ValueDataType Вообще не в ту сторону думал, если честно. Поэтому интересно услышать автора... Если есть ValueDataType (что все же скорее является признаком FieldName), то можно и OldValue :) guest_20040621> Не совсем понятно, куда клоните. Была лавка "Рога и копыта". Благополучно закончилась. Что Вы намерены делать с данными, связанными с этой лавкой? В общем случае ничего. А зачем? :) expla 2 bootty , уточните семантику дат. Это фактические даты предоставления/лишения доступа или просто системные даты изменения атрибутов записи? Т.е. это история изменений записи БД, или изменений объекта документирования/управления? Первое, т.е. не системные даты. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 14:56 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
bootty expla 2 bootty , уточните семантику дат. Это фактические даты предоставления/лишения доступа или просто системные даты изменения атрибутов записи? Т.е. это история изменений записи БД, или изменений объекта документирования/управления? Первое, т.е. не системные даты. Тогда наверное для GUI подойдёт вариант номер два , а для отчётов и пр. фоновых процессов можно сделать материализованное представление первичных данных в форме вариант номер раз . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 15:08 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
поскольку доступ может быть предоставлен как на определенный срок, так и до отмены, то изначальная дилемма бессмысленна ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 15:12 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Dogenпоскольку доступ может быть предоставлен как на определенный срок, так и до отмены, то изначальная дилемма бессмысленна Срок предоставления доступа это плановый показатель, фактическое изъятие доступа нужно фиксировать отдельно. Тогда в вариант номер два в записи типа "получил доступ" нужно предусмотреть атрибут - срок предоставления. Когда сотрудник фактически лишится доступа, нужно быдет завести запись типа "лишился доступа". При этом даты могут и не совпадать как в большую так и в меньшую стороны. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 15:28 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Dogenпоскольку доступ может быть предоставлен как на определенный срок, так и до отмены, то изначальная дилемма бессмысленнаПричинно-следственную связь не объясните? :) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 16:35 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
> В общем случае ничего. Тогда не употребляйте буквосочетания "история изменений" и "база данных". Потому как в общем случае в любой момент времени имеете кашу вместо данных. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 17:24 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
explaЕсли подумать, то разрулить можно. Есть несколько стратегий. Например, 1) запрещать изменения одной секундой, 2) затирать предыдущие данные и т.п. Всё равно от PK в таких таблицах мало толку, так лучше использовать какой нибудь более осмысленный ключ.Да... цирк уехал, а клоуны остались. Разрулить,конечно, это все можно. И даже такими бредовыми способами как предложено, вот только зачем? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 17:24 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
BelyexplaЕсли подумать, то разрулить можно. Есть несколько стратегий. Например, 1) запрещать изменения одной секундой, 2) затирать предыдущие данные и т.п. Всё равно от PK в таких таблицах мало толку, так лучше использовать какой нибудь более осмысленный ключ.Да... цирк уехал, а клоуны остались. Разрулить,конечно, это все можно. И даже такими бредовыми способами как предложено, вот только зачем? Если не знаете, то какая вам разница? Лично я успешно пользуюсь вторым способом, в силу того, что бизнес логика это допускает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 18:25 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
explaПервая удобнее в запросах, почему, уже обсасывали не раз. Но вторая удобнее для пользователя, если в каждый момент времени он либо предоставляет, либо отнимает доступ (возможно, это даже разные люди). Так например, по ошибке в БД может отсутствовать запись о предоставлении доступа. Тогда при первом варианте реализации пользователь не сможет провести операцию отъёма доступа, которого нет в БД. При втором варианте реализации он просто сделает нужную запись. Проблемой отсутствия записи о предоставлении доступа будут заниматься другие люди. Если в Базе Данных не было записи о предоставлении доступа сотруднику (который хотят отменить), то как нужный метод проверял наличие данного доступа у нужного сотрудника? По листочку из тетрадки? А если такого проверяющего доступ метода нет, то зачем тогда нужно отменять доступ, если этот доступ все равно никаким методом не проверяется? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 18:53 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
НеизвестныйexplaПервая удобнее в запросах, почему, уже обсасывали не раз. Но вторая удобнее для пользователя, если в каждый момент времени он либо предоставляет, либо отнимает доступ (возможно, это даже разные люди). Так например, по ошибке в БД может отсутствовать запись о предоставлении доступа. Тогда при первом варианте реализации пользователь не сможет провести операцию отъёма доступа, которого нет в БД. При втором варианте реализации он просто сделает нужную запись. Проблемой отсутствия записи о предоставлении доступа будут заниматься другие люди. Если в Базе Данных не было записи о предоставлении доступа сотруднику (который хотят отменить), то как нужный метод проверял наличие данного доступа у нужного сотрудника? По листочку из тетрадки? А если такого проверяющего доступ метода нет, то зачем тогда нужно отменять доступ, если этот доступ все равно никаким методом не проверяется? Не стал вчитываться... Суть в том, что в БД может храниться не первоисточник, а его реплика. Например есть внешняя АС управления турникетами на проходных предприятия. И есть система кадрового учёта, которая напрямую не связана с первой системой. Понятно, есть процесс provisioning и т.п.. В этом случае доступ сотруднику может быть предоставлен не через отдел кадров, а как то иначе, или записи потеряются, так что в кадровой системе не будет записи о предоставлении доступа (это конечно не правильно, но такова жизнь, и есть конторы, которые платят за то, чтобы так не было). Зато перед увольнением кадровик через свою систему может завести заявку на отключение всех возможных доступов, даже тех, что вообще не зарегистрированы ни в кадрах ни в СБ и проверять тут ничего не нужно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 19:44 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
explaНе стал вчитываться... Суть в том, что в БД может храниться не первоисточник, а его реплика. Например есть внешняя АС управления турникетами на проходных предприятия. И есть система кадрового учёта, которая напрямую не связана с первой системой. Понятно, есть процесс provisioning и т.п.. В этом случае доступ сотруднику может быть предоставлен не через отдел кадров, а как то иначе, или записи потеряются, так что в кадровой системе не будет записи о предоставлении доступа (это конечно не правильно, но такова жизнь, и есть конторы, которые платят за то, чтобы так не было). Зато перед увольнением кадровик через свою систему может завести заявку на отключение всех возможных доступов, даже тех, что вообще не зарегистрированы ни в кадрах ни в СБ и проверять тут ничего не нужно. Вчитался. Переубеждать не буду, сейчас кризис, передача знаний должна быть ограничена и оплачиваема. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 20:06 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
> сейчас кризис, передача знаний должна быть ограничена и оплачиваема Хорошая точка зрения. Безотносительно кризиса. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 20:28 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Неизвестный, В кризис можно и за еду поработать... И не надо меня переубеждать. Ник expla всегда прав, а у его владельца своя голова есть и она не всегда разделяет мнение ника. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 20:28 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
guest_20040621> сейчас кризис, передача знаний должна быть ограничена и оплачиваема Хорошая точка зрения. Безотносительно кризиса. Некошерно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 23.12.2008, 20:30 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
guest_20040621Тогда не употребляйте буквосочетания "история изменений" и "база данных". Потому как в общем случае в любой момент времени имеете кашу вместо данных.Судя по Вашему тону, у Вас есть другая еврсия ответа на заданный Вами же вопрос. Судя по этому же тону, Вы очень гордитесь Вашей еврсией, но проблема в том, что "передача знаний должна быть ограничена и оплачиваема". ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2008, 10:55 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
> Судя по Вашему тону, у Вас есть другая еврсия ответа на заданный Вами же вопрос. И не одна. С помощью наводящих вопросов хотелось помочь задавшему вопрос самостоятельно найти варианты правильных ответов. Если задавший вопрос не хочет думать головой - это его проблемы. Значит, он так и останется конкурентом китайских пионеров. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2008, 11:08 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
guest_20040621С помощью наводящих вопросов хотелось помочь задавшему вопрос самостоятельно найти варианты правильных ответов. Если задавший вопрос не хочет думать головой - это его проблемы.Задавший вопрос сейчас не готов выйти на предлагаемый уровень абстракции, его интересует решение конкретной и не очень глобальной задачи. Если "ментор" не хочет/не может задать доступные для понимания наводящие вопросы, а начинает пространные теоретические рассуждения, то это, конечно, тоже проблема задавшего вопрос, но самого "ментора" такое поведение не украшает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2008, 11:46 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
explaDogenпоскольку доступ может быть предоставлен как на определенный срок, так и до отмены, то изначальная дилемма бессмысленна Срок предоставления доступа это плановый показатель, фактическое изъятие доступа нужно фиксировать отдельно. Тогда в вариант номер два в записи типа "получил доступ" нужно предусмотреть атрибут - срок предоставления. Когда сотрудник фактически лишится доступа, нужно быдет завести запись типа "лишился доступа". При этом даты могут и не совпадать как в большую так и в меньшую стороны. Выдать имярек доступ на такой-то срок или бессрочно - это, скудным умишком проникаю, данные из некоего распоряжения. Там их и надо фиксировать. Можно подумать насчет записей вроде "отобрать доступ", т.к. это распоряжение администратору безопасности системы (например), действия которого тоже надо протоколировать. Выдан доступ - событие, прекращен доступ - событие. Их надо регистрировать. "Интервал доступа" - хрень, которая никому не нужна. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2008, 14:16 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Dogen Выдан доступ - событие, прекращен доступ - событие. Их надо регистрировать. "Интервал доступа" - хрень, которая никому не нужна. "Интервал доступа" не хрень, а состояние. В зависимости от задачи может быть полезен как тот, так и другой формализм. "Интервал доступа" может быть полезен в материализованном виде. Например, в конторе кто то спёр ноутбук со стола, мы ведём следствие. Нужно определить, кто (who) имел доступ в кабинет :room в день [:start, :end], когда ноутбук исчез. Вот тут и будут полезны "интервалы доступа" - access. Простой запрос позволяет получить ответ на этот вопрос. Код: plaintext 1. 2. 3. 4. Можно найти ещё много ситуаций. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2008, 14:36 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
boottyDogenпоскольку доступ может быть предоставлен как на определенный срок, так и до отмены, то изначальная дилемма бессмысленнаПричинно-следственную связь не объясните? :)я не думал, что вопрос всего лишь о примитивной регистрации выданного доступа :) не вчитался, уж простите ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2008, 14:40 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
expla "Интервал доступа" не хрень, а состояние. В зависимости от задачи может быть полезен как тот, так и другой формализм. Можно найти ещё много ситуаций. Можно, не спорю. Но придется тогда рассматривать все возможные случаи потери данных об отобранном или выданном доступе и вероятность наступления таких случаев... Если в общем случае, то лучше не умножать сущностей. Выдали права, забрали, приказы с датами... а для наличия доступа сущность надо бы заводить только если это оправдано в конкретной реализации. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2008, 14:42 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Dogen, "придется тогда рассматривать все возможные случаи потери данных " здесь случаев, согласитесь, всего 4 (все Ок, нет одного из событий или нет всех событий). Почему бы их и не рассмореть? Наконец, можно использовать какую либо общую стратегию исправления/обхода ошибок, для обработки всех ситуаций. "Выдали права, забрали, приказы с датами... " просто автоматизировать систему которая работает как компьютер. Попробуйте автоматизировать хаос. "сущность надо бы заводить только если это оправдано в конкретной реализации" естественно. В противном случае это деньги на ветер, а потом эта сущность сама умрёт, ибо всё что не живёт - умирает. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2008, 14:59 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2008, 15:20 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Bely, если вам платят за объём кода, то я за вас спокоен. Для особо одарённых - "простой" означает, что проше быть не может. На таком тривиальном примере сложно оценить прелесть подхода. Добавьте для приличия ещё каие нибудь условия, типа "сотрудник был на работе", "дверь в комнату была не под охраной" и т.п.. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2008, 16:06 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Dogenя не думал, что вопрос всего лишь о примитивной регистрации выданного доступа :) не вчитался, уж проститеВопрос в структуре для хранения истории событий. Разрешение/запрещение доступа, изменение цены товара, изменение какого-либо признака сущности с какого-то момента. А здесь почему-то все прицепились к одному конкретному примеру... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2008, 17:15 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
boottyА здесь почему-то все прицепились к одному конкретному примеру... Так это твоя забота направлять дискуссию в нужное русло. Нарисуй другой пример, все прицепятся к нему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2008, 17:28 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
boottyDogenя не думал, что вопрос всего лишь о примитивной регистрации выданного доступа :) не вчитался, уж проститеВопрос в структуре для хранения истории событий. Сформулировал задачу? События не имеют протяжённости во времени (в отличии от их последствий), так что Вариант номер раз в такой постановке не катит. Если интересуют и события и состояния, количество вариантов возрастает. Ещё, в природе не существует событий, как не существует точек, это математическая абстракция. Так что твоя модель может быть не вполне адекватной в каждом конкретном случае. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2008, 17:38 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
explaесли вам платят за объём кода, то я за вас спокоен. мне платят за то, что такие задачи не вызывают у меня проблем. explaДля особо одарённых - "простой" означает, что проше быть не может.Простой код - не значит самый быстрый. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2008, 18:42 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
BelyexplaДля особо одарённых - "простой" означает, что проше быть не может.Простой код - не значит самый быстрый. Я про это и не говорил, но раз уж вы напросились, могу утверждать, что на выбраной мною платформе ваш код проиграет в производительности. И вполне вероятно, что на выбранных мною задачах подобного класса, ваша работа будет стоить дороже работы студента со стажем программирования запросов в один год и займёт больше времени. Естественно, вы на своей платформе можете показать обратный результат и работать за еду. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 24.12.2008, 20:19 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
explaИ вполне вероятно, что на выбранных мною задачах подобного класса, ваша работа будет стоить дороже работы студента со стажем программирования запросов в один год и займёт больше времени. Естественно, вы на своей платформе можете показать обратный результат и работать за еду. Какой-то Вы на жись обиженный... Работа студента будет дешевле ингода, но вот быстрее - сомнительно :) И хватает на еду не только мне, но и семье. И на хлеб и на масло :) Чего и вам желаю. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2008, 11:48 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
explaСобытия не имеют протяжённости во времени (в отличии от их последствий), так что Вариант номер раз в такой постановке не катит. Если интересуют и события и состояния, количество вариантов возрастает.Интересуют и события, и состояния. Предполагаю, чаще будет требоваться знать состояние. explaЕщё, в природе не существует событий, как не существует точек, это математическая абстракция. Так что твоя модель может быть не вполне адекватной в каждом конкретном случае.Ок, другой пример: Номенклатура ZZZZZZ <ресурс 1> имеет цену <измерение 1> с <BeginDate>. Насколько адекватно, на Ваш взгляд? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2008, 12:32 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
bootty, номенклатура такая же абстракция, как и событие, так что ИМХО, здесь всё в порядке. И вообще, с утра как то не придумывается, где может быть плохо. Наверное, даже и не может, потому как БД уже имеет дело с абстракцией реального мира. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2008, 12:52 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
explaНеизвестный, В кризис можно и за еду поработать... И не надо меня переубеждать. Ник expla всегда прав, а у его владельца своя голова есть и она не всегда разделяет мнение ника. Плохой хозяин у Вашей головы. За еду нельзя работать, даже в кризис. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2008, 13:00 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Bely Работа студента будет дешевле ингода, но вот быстрее - сомнительно :) Вам платят меньше чем студентам? Bely И хватает на еду не только мне, но и семье. И на хлеб и на масло :) Чего и вам желаю. Вот уж не надо! Я предпочитаю питаться более разнообразно. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2008, 13:04 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
йййййййййПлохой хозяин у Вашей головы. За еду нельзя работать, даже в кризис. Это Вы гастарбайтерам на закрытой стройке расскажите. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2008, 13:12 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
explaВам платят меньше чем студентам? Когда заканчиваются доводы с трассировками и примерами, начинаются понты и словоблудье. по существу есть что сказать? С примерами и трассировками? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2008, 13:29 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
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. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. Завершение второго запроса пока ожидаю.... Ещё нужны доводы? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2008, 14:11 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Те же яйца только с индексом... и свой запрос исправил (не оттуда его скопировал). Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. Код: 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. 20:5 и 31:1 - неплохой результат. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2008, 14:55 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
boottyВопрос в структуре для хранения истории событий . Разрешение/запрещение доступа, изменение цены товара, изменение какого-либо признака сущности с какого-то момента. А здесь почему-то все прицепились к одному конкретному примеру... Не побоюсь сказать банальность, но ответ содержится в вопросе. Что касается необходимости отражать в структуре БД состояния - для обсуждения этого аспекта вы слишком узко (или наоборот, неконкретно? :) ) ставите вопросы. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2008, 16:08 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
йййййййййЗа еду нельзя работать, даже в кризис. Когда как, товарищ. Рады за то, что вы можете делать такие заявления. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 25.12.2008, 16:11 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
DogenЧто касается необходимости отражать в структуре БД состояния - для обсуждения этого аспекта вы слишком узко (или наоборот, неконкретно? :) ) ставите вопросы.Согласен, виноват. Но ниже уже было другое:boottyИнтересуют и события, и состояния. Предполагаю, чаще будет требоваться знать состояние. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2008, 10:18 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
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. теперь, собственно запросы. Код: 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. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2008, 13:02 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Belyexpla, Более реальные тестовые данные. Но до тех пор, пока FULL TABLE SCAN будет выгоднее досьупа по индексу, тестировать бесполезно. Сделай стенд, чтобы полезно было. А то выходит, что ты гол в свои ворота забил. Индекс тут не используется не только и не столько из-за того что "выгоднее", а по фундаментальной причине. Что время то не замерил? Пока я вижу Cost 2605:788 - многообещающее начало. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2008, 13:35 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
explaСделай стенд, чтобы полезно было. А то выходит, что ты гол в свои ворота забил. Не у всех есть куча времени, чтобы его тратить на исследования. У меня его пока нет. explaИндекс тут не используется не только и не столько из-за того что "выгоднее", а по фундаментальной причине.Это что за "фундаментальная причина" по которой в такой таблице не используется индекс? explaЧто время то не замерил? Пока я вижу Cost 2605:788 - многообещающее начало. А что, consistent gets и physical reads - не подходят? Время может от чего угодно зависеть, в том числе от текущей нагрузки на сервер, чертыханий на клиента, закупоренности сетки итд. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2008, 14:28 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Bely, 1) понимаю... ведь тебе кучу кода писать приходится. 2) например так Код: plaintext 1. 2. 3) кого бодает consistent gets, physical reads кроме разработчика и DBA? physical reads не сложно свести к 0. что бы нивелировать влияние случайных факторов, к результату эксперимента применяют методы статистической обработки. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2008, 14:56 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
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. Далее запросы - поиск в диапазоне. Код: 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. И еще - другая дата (для таблицы с одной датой) Код: 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. Заставить запрос ходить по индексу с двумя датами - мне так и не удалось. Позже выложу еще запросы с поиском доступа н указанную дату, а не на диапазон. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2008, 16:35 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
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. если переделать индекс Код: plaintext 1. 2. 3. 4. 5. 6. То получаем Код: 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. И, ИМХО, из-за замены union на union all в запрос таки ошибочка закралась, в случае i.frd = sysdate-500000 запись задвоится. 3442:2114.... Я доволен. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 26.12.2008, 17:42 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Предлагаю таблицу: ИмяТаблицы, ИмяПоля, ДатаИзменения, Значение поля, Комментарии А уж дальше извлекать данные по конкретному полю конкретной таблицы процедурами или функциями. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2008, 16:58 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
RodionATПредлагаю таблицу: ИмяТаблицы, ИмяПоля, ДатаИзменения, Значение поля, Комментарии А уж дальше извлекать данные по конкретному полю конкретной таблицы процедурами или функциями. НЕ НАДО! В 1С 7.7 так и было, ничего хорошего. Потом в 8 версии от этого ушли ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2008, 17:02 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
RodionATПредлагаю таблицу: ИмяТаблицы, ИмяПоля, ДатаИзменения, Значение поля, Комментарии А уж дальше извлекать данные по конкретному полю конкретной таблицы процедурами или функциями.предлагаю запихнуть в такую таблицу миллионов 70 строк и посмотреть как быстро состарится полтьзователь от ожидания данных от отчетов, которые используют такую таблицу. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2008, 17:02 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
RodionATПредлагаю таблицу: боян первыйнах ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 29.12.2008, 17:02 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Господа, не ломайте голову над велосипедом! Период актуальности (время жизни и т.п. - называйте как хотите) - либо вектор, либо отрезок . Два поля типа дата/время с возможностью нести Null-значения и все проблемы проектирования БД решены. Остальные мелочи - задача программного кода. P.S.: На сегодня, конечно, есть теория гиперрациональных чисел, где время - это пространство... Но оно вам надо??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2009, 19:55 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
TsRVГоспода, не ломайте голову над велосипедом! Период актуальности (время жизни и т.п. - называйте как хотите) - либо вектор, либо отрезок . Два поля типа дата/время с возможностью нести Null-значения и все проблемы проектирования БД решены. Остальные мелочи - задача программного кода. P.S.: На сегодня, конечно, есть теория гиперрациональных чисел, где время - это пространство... Но оно вам надо??? Это про Вас? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 20.01.2009, 21:36 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Bely Это про Вас? Bely, вы всегда усложняете себе жизнь из-за пары миллисекунд? Формула-1? А Вы не задумывались, что когда-то преемнику Вашего "достояния" придется его разгребать??? Хорошо, если Вы пишете частные задачи и в них 3-4 таблицы!.. По существу поставленного вопроса: Первый вариант - как кадры на фото- или кинопленке. Для частных случаев вполне уместен. Считаю второй вариант универсальным, расширяемым, более полно описывающим историзм и понятным . А быстродействие запроса - это еще спорный вопрос... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 02:17 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
TsRVBely Это про Вас? Bely, вы всегда усложняете себе жизнь из-за пары миллисекунд? Формула-1? А Вы не задумывались, что когда-то преемнику Вашего "достояния" придется его разгребать??? Хорошо, если Вы пишете частные задачи и в них 3-4 таблицы!.. По существу поставленного вопроса: Первый вариант - как кадры на фото- или кинопленке. Для частных случаев вполне уместен. Считаю второй вариант универсальным, расширяемым, более полно описывающим историзм и понятным . А быстродействие запроса - это еще спорный вопрос... Извиняюсь, варианты перепутал с пылу-жару... Фотопленка - второй вариант. Первый предпочтительней. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 02:24 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
TsRVBely, вы всегда усложняете себе жизнь из-за пары миллисекунд? Формула-1? А Вы не задумывались, что когда-то преемнику Вашего "достояния" придется его разгребать??? Хорошо, если Вы пишете частные задачи и в них 3-4 таблицы!.. По существу поставленного вопроса: Первый вариант - как кадры на фото- или кинопленке. Для частных случаев вполне уместен. Считаю второй вариант универсальным, расширяемым, более полно описывающим историзм и понятным . А быстродействие запроса - это еще спорный вопрос...Судя по вашему ответу - вы с проблемой производительности при поиске по логу не сталкивались. А у нас лог вот уже к полусотне миллионов строк подбирается. И я не могу сказать пользователю, что отчет готовится медленно, но зато верно. Приходится предпринимать меры, чтобы отчет готовился в ПРИЕМЛЕМОЕ время. Да и размер табличек и индексов на таких объемах начинает становиться не таким безразличным. PS: что касается кино и фото - если бы кино было бы настолько круто, то оно бы выдавило уже фото. Но у фотографий есть такие варианты использования, которые никогда нельзя будет выжать из кино. Подумайте о больших выдержках затвора... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 11:01 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
BelyА у нас лог вот уже к полусотне миллионов строк подбирается. Не проще лог раскидать по периодам или вообще элементарно - в архив? Уверен, для оперативной работы необходимы лишь несколько сотен, может тысяч, последних записей... BelyПодумайте о больших выдержках затвора... Углубляться в мелочи можно до бесконечности. Об этом написано много специализированной литературы. В таком понимании мира - можно и бит разбить на составные части... P.S.: Вы явно работаете не с тиражным ПО... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 11:20 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
TsRVBelyА у нас лог вот уже к полусотне миллионов строк подбирается.Не проще лог раскидать по периодам или вообще элементарно - в архив? Уверен, для оперативной работы необходимы лишь несколько сотен, может тысяч, последних записей...Ну, сносить в архив дело хорошее, но вот только прозрачность теряется. И приходится генерить запросы вида Код: plaintext 1. 2. 3. 4. 5. 6. PS: судя по тому, что вы не сказали слово партиционирование, то оно вам не знакомо :) TsRVBelyПодумайте о больших выдержках затвора...Углубляться в мелочи можно до бесконечности. Об этом написано много специализированной литературы. В таком понимании мира - можно и бит разбить на составные части... Чтобы понимать особенности - надо знать частности. Все знают арифметику, но не все могут работать финансовыми директорами и бухгалтерами. Почитайте еще вот это TsRVP.S.: Вы явно работаете не с тиражным ПО...Я видел достаточно много тиражных систем, которые используют те же самые механизмы, что и наша нетиражная. Так что это ровным счетом ничего не значит, кроме того, что у меня больше маневра - мы можем переделать нашу систему. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 12:28 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
BelyНу, сносить в архив дело хорошее, но вот только прозрачность теряется. И приходится генерить запросы... Bely, вы противоречите сами себе. А Ваши примеры реализации, описанные выше, не теряют прозрачности и не требуют генерации запросов? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 13:51 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
TsRVBelyНу, сносить в архив дело хорошее, но вот только прозрачность теряется. И приходится генерить запросы...Bely, вы противоречите сами себе. А Ваши примеры реализации, описанные выше, не теряют прозрачности и не требуют генерации запросов?Вы правильно поняли. НЕ теряют прозрачности и НЕ требуют запросов с UNION -ами по нескольким таблицам. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 14:15 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
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 ; Если это Вы считаете "прозрачным", то что для вас " НЕ прозрачное"? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 14:24 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
TsRVЕсли это Вы считаете "прозрачным", то что для вас " НЕ прозрачное"? Здесь как раз запрос В ЛОБ. Те, кто получил доступ ДО и те, кто получил доступ ВО ВРЕМЯ периода. А теперь представьте, что надо сюда еще вклинить таблицу истории... В заключении могу предложить поэкспериментировать с разными структурами, чтобы получить срез данных НА ОПРЕДЕЛЕННОЕ ВРЕМЯ для таблиц с одной и двумя датами. Скорость выполнения Вас удивит. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 14:39 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Bely, а теперь попробуйте протестировать, допустим, следующую задачу: Для каждого кода выберем строку, максимально “приближенную” к требуемой дате И поглядим, чьи решения универсальней и "шустрее" ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 15:13 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
TsRVBely, а теперь попробуйте протестировать, допустим, следующую задачу: Для каждого кода выберем строку, максимально “приближенную” к требуемой дате Ну точно "Астронавт проектирования". Какой смысл в такой задаче? Я не вижу ни одного реального применения для такого запроса. А исследовать можно много чего . ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 16:26 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Bely, это аналитика. И подобные вариации у меня встречаются достаточно часто. Видимо, Ваш проект не настолько интересен, как мои... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 16:49 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
TsRVBely, это аналитика. И подобные вариации у меня встречаются достаточно часто. Видимо, Ваш проект не настолько интересен, как мои... Видимо Вы не можете сформулировать сущность этого показателя. Средняя температура по больнице никого не интересует. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 16:53 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Причем тут температура и время? Вы не путаете топик? Выберите, к примеру, из серии колбас те, которые по сроку годности необходимо в первую очередь выложить на прилавок... --- вот один из множества примеров. Мне Вас жаль - скучно живете! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 16:58 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
TsRVПричем тут температура и время? Вы не путаете топик? Выберите, к примеру, из серии колбас те, которые по сроку годности необходимо в первую очередь выложить на прилавок... --- вот один из множества примеров. Мне Вас жаль - скучно живете! Дык, вот он этот запрос. Код: plaintext А вот его сравнение с запросом по двум датам. PS: точнее формулировать надо. Для каждого кода выберем строку, максимально “приближенную” к требуемой дате Вот даты: 1) 01.01.2009 2) 10.01.2009 Какая из них наиболее приближена к 02.01.2009 ? а какая самая близкая из непрошедших? это будут две разные даты... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 17:09 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Bely, у различных, даже однотипных, продуктов различные сроки годности (разделение на сорта, производителей и т.п. не учитываем), при этом дата их производства различна во времени: Партия 1 : (==========) Партия 2 : (==========) Партия 3 : (==========) Партия 3*: (=====) ... и т.д. * - встречается, допустим, брак в упаковке, что приводит к сокращению сроков хранения (это расписано в ГОСТах). Отстаиваемый Вами вариант историзма с одной "датой" в таких случаях негоден, потому как не хранит дату окончания срока годности... У меня аналогичных задач встречается много, поэтому я всегда использую две даты в истории, даже если вторая, казалось бы, и ненужна... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 17:33 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Плин, пробелы покоцались :( Партия 1 : ..(==========) Партия 2 : ........(==========) Партия 3 : ................................(==========) Партия 3*: ...............................(=====) ... и т.д. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 17:34 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
> вариант историзма с одной "датой" в таких случаях негоден, потому как не хранит дату окончания > срока годности... Срок годности, история изменений и агрегаты, которые кому-то почему-то понадобилось вычислять на основании нафиг не нужных дат, - это три абсолютно разные и никак не связанные задачи. Вам, юноша, следует хотя бы в общих чертах ознакомиться с историей вопроса, прежде чем рассказывать о своих ошибках. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 17:44 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
TsRVОтстаиваемый Вами вариант историзма с одной "датой" в таких случаях негоден, потому как не хранит дату окончания срока годности...Гм... а ничего, что у вас не история, а просто атрибуты у объекта? История - это список всех изменений конкретного объекта. У вас же ничего не меняется. Для вашей задачи первая дата вобще не нужна. Нужна только одна дата - окончание срока годности. Дата когда было произведено ДЛЯ ИЗЛОЖЕННЫХ ВАМИ ЗАДАЧ - не нужны. Соответственно - у вас не интервал годности, а просто два параметра. Дата Выпуска. Окончание срока годности. PS: у меня в некоторых таблицах по 5-6 дат. Это не значит, что я живу в 6 временных измерениях. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 17:48 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
guest_20040621, вы в теме? А что такое для колбасы срок годности, для имущества срок гарантийного использования, для самолета время полета в рейсе? Вам нужны еще примеры по использованию историзма??? Или в Вашем понимании историзм должен быть только где-то там, позади у чего-то, чего мы не знаем и уже никогда не увидим? Наверное, у Вас он есть только в логах? Срок годности, история изменений... --- это все частные случаи! И вот когда каждый из таких случаев программисты-одиночки не видят и начинают извращать по-своему - корпоративное приложение в целом получается одной большой кучей *** ================== *** - скрипта ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 18:03 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
> вы в теме? Больше, чем хотелось бы. > А что такое для колбасы срок годности, Атрибут. > для имущества срок гарантийного использования, Атрибут. > для самолета время полета в рейсе Атрибут. > Вам нужны еще примеры по использованию историзма??? Ни один из приведенных примеров к истории изменений ни малейшего отношения не имеет. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 18:44 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
1. Где-то уже писал: история - вектор/прямая/отрезок времени. Как вы это представляете одной датой? Или Вы рассматриваете только частность вектора? От даты А до следующей записи? 2. Вы хотите вести полный историзм с учетом сохранения изменений? Вкратце: Добавляем сущность : вставляем строку, генерим ID, date1 = date; date2 = null, обрабатываем остальные условности... Изменяем сущность : date2=date-1, копируем сущность (в т.ч. ID!) - работаем уже с ней, date1=date, date2=null, обрабатываем остальные условности... Удаляем сущность : date2=date-1, обрабатываем остальные условности... Работает в любых случаях! Что еще универсальней, проще и быстрей можете предложить?????? Вы спорите по частным вопросам! Хватит плавать по дну! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 20:06 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
> Где-то уже писал: И это не единственная Ваша ошибка. Писать (а тем более давать советы) нужно очень хорошо подумав. > история - вектор/прямая/отрезок времени. Применительно к базам данных история изменений - это регистрация состояний сущностей и связей в любой момент времени. Как следствие - возможность консистентного непротиворечивого полного снапшота на любую дату. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 21.01.2009, 21:11 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
guest_20040621бла-бла-бла... Умный, разумный гость! Для начала зарегся, потом обсудим ваши эмоции... ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2009, 01:45 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
guest_20040621, кстати! По существу вопроса предложения есть??? Помнится, вопрос был поднят: " Оптимальная структура таблицы для хранения истории"... Сначала дайте дельное слово, потом пытайтесь пыжиться, защищая его!!!! ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2009, 01:49 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
guest_20040621Применительно к базам данных... Снова "частник"??? guest_20040621это регистрация состояний сущностей и связей в любой момент времени... Как раз это мной и выведено сюда, на общее обозрение! У вас имеются на данное решение права??? ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2009, 01:54 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
Уффф, господа! В чем проблемы? Если Вы решаете "глобальные" задачи на своих ноутбуках - то мне понятны ваши стремления! Определите уровень решаемых ВАМИ задач!!! ------------------------------------------------------------ P.S.: Для проверки: гольный массив [ID, Parent_ID] - 0,175 млрд - 1,8 сек. (+/- 0,2 сек.) ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2009, 03:03 |
|
||
|
Оптимальная структура таблицы для хранения истории...
|
|||
|---|---|---|---|
|
#18+
> Как раз это мной и выведено сюда, на общее обозрение! Хуже всего то, дружище, что Вы даже не понимаете, в чем Ваша ошибка. Hint: советы лет этак пять ближайших давать остерегайтесь. Засмеют. ... |
|||
|
:
Нравится:
Не нравится:
|
|||
| 22.01.2009, 09:54 |
|
||
|
|

start [/forum/topic.php?all=1&fid=32&tid=1543479]: |
0ms |
get settings: |
7ms |
get forum list: |
14ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
333ms |
get topic data: |
10ms |
get forum data: |
3ms |
get page messages: |
101ms |
get tp. blocked users: |
1ms |
| others: | 227ms |
| total: | 702ms |

| 0 / 0 |
