Python-сообщество

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

Пытаюсь спроектировать БД, для некоторых таблиц которой важно отслеживать все изменения и сохранять старые данные..
Например, имеется таблица `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 |

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

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

dimabest
+1

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

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

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

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

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

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

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

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

Отредактировано (Фев. 4, 2011 22:00:57)