DjangoBB LoFi version

Начало » Базы данных » хронологическая БД

del3d

Дек. 25, 2010 10:16:38

Здравствуйте, товарищи!

Пытаюсь спроектировать БД, для некоторых таблиц которой важно отслеживать все изменения и сохранять старые данные..
Например, имеется таблица `users`:

CREATE TABLE `users` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `login` varchar(255) NOT NULL,
  `password` varchar(255) NOT NULL,
  `f_name` varchar(255) NOT NULL,
  `l_name` varchar(255) NOT NULL,
  `s_name` varchar(255) NOT NULL,
  `email` varchar(255) default NULL,
  `date_modify` datetime default NULL,
  UNIQUE KEY `login` (`login`),
  PRIMARY KEY (`id`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Если у какого-то пользователя изменится фамилия, то в таблицу добавляется новая запись с измененными данными и текущая дата изменения..

|  1 | admin | Васильев     | 2010-12-09 12:00:39 | 
|  2 | beemn| Пчелкин       | 2010-12-09 12:00:39 | 
|  3 | admin | Иванов       | 2010-12-25 11:00:39 |

Т.е. актуальной будет наибольшая дата для выбранного пользователя..
НО ТОГДА ПОЛЕ `login` НЕ ПОЛУЧИТСЯ СДЕЛАТЬ УНИКАЛЬНЫМ.. и на уровне БД не будет гарантии несовпадения логинов..
Как мне подружить уникальность и хронологию?
Спасибо.

dimabest

Дек. 25, 2010 11:53:16

В таблице users хранить актуальные данные, а в таблице history - список изменений (без уникального поля логин)?

Если актуальные данные определять по MAX(date_modify), то все выборки “более одного юзера” будут либо слишком сложными, либо невозможными.

o7412369815963

Дек. 25, 2010 19:40:34

dimabest
+1

+ активных данных будет необходимый минимум, а всю историю можно затолкнуть будет в отдельную базу т.к. к ней гораздо реже обращаются… ( это к вопросу оптимизации )

Ferroman

Дек. 25, 2010 19:44:39

Premature optimization is the root of all evil (or at least most of it) in programming. © Donald Knuth

del3d

Дек. 26, 2010 17:51:19

dimabest
В таблице users хранить актуальные данные, а в таблице history - список изменений (без уникального поля логин)?

o7412369815963
+ активных данных будет необходимый минимум, а всю историю можно затолкнуть будет в отдельную базу

Согласен.. логин уникален.. запросы на выборку очень простые.. но:
Тогда таблицы users и history будут иметь практически одинаковую структуру..
и еще нужен триггер, который при изменении данных сохранял бы старые данные..
придется посылать разные запросы на извлечение текущих данных и измененных, а мне бы хотелось заставить систему работать всегда одинаково, независимо от временной метки, на момент которой мы хотим получить данные..

o7412369815963
а всю историю можно затолкнуть будет в отдельную базу

зачем историю хранить отдельно от текущих данных?

Ferroman
Premature optimization is the root of all evil (or at least most of it) in programming. © Donald Knuth

Полностью согласен с высказыванием, но оптимизировать пока еще нечего.. с проектированием бы разобраться..

Может быть id/login/password вынести в отдельную таблицу?

Андрей Светлов

Дек. 26, 2010 18:27:13

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

DcDr

Фев. 4, 2011 21:59:11

del3d
зачем историю хранить отдельно от текущих данных?

Потому что БД - реляционная.
Для РСУБД предложенное выше разнесение данных на 2 таблицы - естественный способ хранения данных.
К тому, скорее всего для вашего случая - и наиболее быстрые выборки. История ж не каждый раз нужна.