 |
|
Модераторы: LSD |
 
|
|
изменение данных, как проследить? 
| UnixBeginner |
|
|||
 Шустрый  Профиль Группа: Участник Сообщений: 89 Регистрация: 10.11.2005 Где: Россия, г. Калини нград Репутация: нет Всего: нет |
есть таблица с данными:
первичного ключа нет. Выбираю эти данные по полю id и вывожу в таблице. Теперь необходимо проследить: изменялись ли данные, были ли удалены какие-либо строки. Как это можно реализовать если не обращаться к БД сразу после одного из этих действий (удаление, изменение, вставка)? Просто предположительный алгоритм, без привязки к языку. Правда есть предположение: ввести еще одно поле в программе - показатель - были данные изменени, ... и потом его проверять. Что посоветуете? |
|||
|
||||
Дата 13.2.2006, 13:13 (
Загрузка ...
| Akina |
|
|||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
Триггеры, регистрирующие изменение в БД в специальной таблице.
Журнал называется. Добавлено @ 13:27
тогда уж timestamp последнего изменения записи - но что делать с удаленными? -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
| UnixBeginner |
|
|||
|
Шустрый Профиль Группа: Участник Сообщений: 89 Регистрация: 10.11.2005 Где: Россия, г. Калини нград Репутация: нет Всего: нет |
просто изменения происходят в программе, а не в БД. Т.е. программа выбрала данные и все, затем пользователь работает уже с локальной копией, редактирует, ... А вносить изменения в БД необходимо только после того, как он нажал на кнопку "Save". Вроде триггеры тут не помогут. |
|||
|
||||
| Akina |
|
|||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
распрекрасно помогут... после редактирования, когда начинается сохранение, первым шагом будет повторный запрос и проверка, что данные, которые подлежат изменению в соответствии с воодом оператора, не подверглись изменению на сервере другим оператором с другого рабочего места, в ином случае следует сообщить о коллизии изменений. Задача же триггера - просто зафиксировать факт изменения данных: какие данные, как, когда и кем изменены. Что делать с этой информацией - это уже совсем другой вопрос. -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
| Bose |
|
|||
 Эксперт Профиль Группа: Участник Клуба Сообщений: 1458 Регистрация: 5.3.2005 Где: Riga, Latvia Репутация: нет Всего: 51 |
триггеры помогут отследить разницу между тем, что было в базе до того, как пользователь нажал Save, и что там оказалось после того...
если тебя интересует, именно процесс изменений данных на компьютере пользователя, то... это наверное ручками придётся обрабатывать... или триггерами в локальной базе данных  |
|||
|
||||
| UnixBeginner |
|
|||
|
Шустрый Профиль Группа: Участник Сообщений: 89 Регистрация: 10.11.2005 Где: Россия, г. Калини нград Репутация: нет Всего: нет |
ладно, видать нужно почитать по больше по БД, ьриггеры и другие примочки. Я пока в этом не особо разбирался, просто создавал таблицы и связи, а вот с тавими вопросами не сталкивался
 |
|||
|
||||
| Akina |
|
|||
|
Советчик Профиль Группа: Модератор Сообщений: 20581 Регистрация: 8.4.2004 Где: Зеленоград Репутация: 13 Всего: 454 |
Есть другой подход.
База данных дополняется полями TimeStamp As DateTime и Valid As Boolean. Поля НЕ РЕДАКТИРУЮТСЯ и НЕ УДАЛЯЮТСЯ. Любое действие по изменению - это установка Valid в False и создание новой записи с обновленным контентом. Удаление - просто установка Valid в False. Получается и журнал (лог атомов транзакций), и база в одном файле. Очень хорошо подходит для БД с низким (менее 5 в сутки) процентом обновления. -------------------- О(б)суждение моих действий - в соответствующей теме, пожалуйста. Или в РМ. И высшая инстанция - Администрация форума. |
|||
|
||||
| batigoal |
|
|||
 Нелетучий Мыш Профиль Группа: Участник Клуба Сообщений: 6423 Регистрация: 28.12.2004 Где: Санктъ-Петербургъ Репутация: 1 Всего: 151 |
По идее, если не нужно вести полную историю изменений, можно ограничиться только последними n версиями. Тогда хотя бы таблицу не так разнесет.
-------------------- "Чтобы правильно задать вопрос, нужно знать большую часть ответа" (Р. Шекли) ЖоржЖЖ |
|||
|
||||
| SergeBS |
|
|||
|
Эксперт Профиль Группа: Завсегдатай Сообщений: 1111 Регистрация: 10.6.2005 Где: Владимир Репутация: 1 Всего: 22 |
UnixBeginner
Почитай Глеба Уфимцева: Сервис многократной отмены 'SQL-UNDO 2' в многопользовательской системе, построенной на движке MSSQL-server 7.0 http://www.gvu.newmail.ru/sql_undo_2.htm Мне очень понравилось. В принципе перешивается и для других движков. |
|||
|
||||
|
|
| Правила форума "Общие вопросы по базам данных" | |
|
|
Данный форум предназначен для обсуждения вопросов о базах данных не попадающих под тематику других форумов:
Данный форум не предназначен для:
Если вы не соблюдаете эти правила, не удивляйтесь потом не найдя свою тему/сообщение.
Полезные советы: Если Вам понравилась атмосфера форума, заходите к нам чаще! С уважением, LSD, Zloxa. |
| 0 Пользователей читают эту тему (0 Гостей и 0 Скрытых Пользователей) | |
| 0 Пользователей: | |
| « Предыдущая тема | СУБД, общие вопросы | Следующая тема » |
[ Время генерации скрипта: 0.1179 ] [ Использовано запросов: 22 ] [ GZIP включён ]
Реклама на сайте Информационное спонсорство
|
|
По вопросам размещения рекламы пишите на vladimir(sobaka)vingrad.ru
Отказ от ответственности Powered by Invision Power Board(R) 1.3 © 2003 IPS, Inc. |