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

Belyvinger4Почему не хотите время тянуть в первичный ключ?потому что это неправильно.
Подумайте о двух изменениях, сделанных в одну секунду.

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


2 bootty , уточните семантику дат. Это фактические даты предоставления/лишения доступа или просто системные даты изменения атрибутов записи? Т.е. это история изменений записи БД, или изменений объекта документирования/управления?

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

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

Настоящий уровень абстракции не позволяет судить о производительности. Так что не стоит бежать впереди паровоза.

bootty
expla 2 bootty , уточните семантику дат. Это фактические даты предоставления/лишения доступа или просто системные даты изменения атрибутов записи? Т.е. это история изменений записи БД, или изменений объекта документирования/управления?
Первое, т.е. не системные даты.

Тогда наверное для GUI подойдёт вариант номер два , а для отчётов и пр. фоновых процессов можно сделать материализованное представление первичных данных в форме вариант номер раз .

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

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

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

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

Если не знаете, то какая вам разница? Лично я успешно пользуюсь вторым способом, в силу того, что бизнес логика это допускает.

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

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

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