Каморка

Есть БД. Разные люди могут менять данные в разных таблицах. Главбух может поменять цену товара, завскладом - инвентарный номер, HR - адрес сотрудника. Нужна таблица в которой бы отмечались все изменения.

С полями Кто, Что и Где все понятно
EmployeeID - int - Кто изменил
TableName - char - Где изменил
FieldName - char - Что изменил
Проблема идентифицировать запись в таблице. Главбух меняет цену товара под номером 5 (Primary key - integer), а HR меняет адрес сотрудника по фамилии Пупкин Вася (PK - char+char; не будем обсуждать правильность выбора PK). Какого типа должен быть
RecordNumber -???

Аналогично со старым и новым значениями
OldValue - ???
NewValue - ???


Или это как-то по-другому делается?

Спасибо.

Бодался я как-то с чем-то подобным.
ничего разумнее чем делать просто char для RecordNumber не придумал.
изменения с Old на New value писал просто текстом в соответствующее поле.

первый вопрос.... как эта таблица будет использоваться? есть ли _реально_ сформулированные требования отзаказчика зачем нужна таблица и как ее будут пользовать? вообще апрям вот надо именно _одну_ таблицу?

Нужно получать ответы на вопросы типа: "На что изменились цены в апреле" и "Кто добавил ребенка жене Васи Пупкина". То есть, запросы разные и нужно отслеживать все изменения некоторых полей.
Одна таблица необязательно. Сделать для каждой таблицы таблицу изменений? Это удвоить количество таблиц.

CdR писал(а):Бодался я как-то с чем-то подобным.
ничего разумнее чем делать просто char для RecordNumber не придумал.
изменения с Old на New value писал просто текстом в соответствующее поле.

Да, Old and NewValue не такая уж и проблема.
А если ПК составной? В RecordNumber писать Вася[непечатный_символ]Пупкин?

если делать все одной таблицей то перформанц просядет иьо конкурентность маленькой будет. ибо все через одно место будет проходить.... если хочешь одну таблицу, то тогда ИД тип варчар и в него все что угодно пиши.

StS писал(а):Есть БД. Разные люди могут менять данные в разных таблицах. Главбух может поменять цену товара, завскладом - инвентарный номер, HR - адрес сотрудника. Нужна таблица в которой бы отмечались все изменения.

С полями Кто, Что и Где все понятно
EmployeeID - int - Кто изменил
TableName - char - Где изменил
FieldName - char - Что изменил
Проблема идентифицировать запись в таблице. Главбух меняет цену товара под номером 5 (Primary key - integer), а HR меняет адрес сотрудника по фамилии Пупкин Вася (PK - char+char; не будем обсуждать правильность выбора PK). Какого типа должен быть
RecordNumber -???

Аналогично со старым и новым значениями
OldValue - ???
NewValue - ???


Или это как-то по-другому делается?

Спасибо.

пишеш тригер на инсерт и апдейт на тех таблицах и заносиш в приведенную данные

Какая база данных (SQL Server,Oracle,DB2)?
SQL Server
Kak yже было сказано лучше всего написать триггер FOR INSERT,UPDATE,DELETE
create trigger tru_MyTable on MyTable after update,delete,insert
as

if @@ROWCOUNT = 0
return
if exists (select * from inserted) and exists (select * from deleted)
begin
insert MyAuditTable
select
i.ID
, d.MyColumn
, i.MyColumn
from
inserted i
join
deleted d on d.ID = i.Id
end
if exists (select * from inserted)
begin
insert MyAuditTable
select
i.ID
, i.MyColumn
from
inserted i
end
if exists (select * from deleted)
begin

insert MyAuditTable
select
d.ID
, d.MyColumn
from
deleted d

end
go

у нас в планах на будущее стоят всякие "истории". Главный балаган наступает, когда после накопления истории начинают менять EmployeeId вперед/назад.

Yuri Dimant писал(а):Какая база данных (SQL Server,Oracle,DB2)?
SQL Server
Kak yже было сказано лучше всего написать триггер

За идею с триггерами спасибо, но на данном этапе мы говорим только о структуре БД. Привязываться к конкретной БД не хотелось бы. Если нужны триггеры, поставим требование к DBMS иметь триггеры, но ставить требования типа "иметь фичу как у MSSQL" - несолидно как-то.

dima писал(а):у нас в планах на будущее стоят всякие "истории". Главный балаган наступает, когда после накопления истории начинают менять EmployeeId вперед/назад.

Запретить менять EmployeeID и отслеживать изменения при инсерте/удалении (приеме на работу/увольнении) в Employee table. В Emloyee table должна быть дата приема на работу.

StS писал(а):

dima писал(а):у нас в планах на будущее стоят всякие "истории". Главный балаган наступает, когда после накопления истории начинают менять EmployeeId вперед/назад.

Запретить менять EmployeeID и отслеживать изменения при инсерте/удалении (приеме на работу/увольнении) в Employee table. В Emloyee table должна быть дата приема на работу.

Ежели MS SQL Server и делать все в одной таблице - то будет тормозить хот ты что делай. Теоретически не должно но на практике будет. Так что лучше разбить на несколько таблиц. А в Оракле должно работать. Особенно ежели покупать сервер не от Делла за 5 штук а за 50 штук. А вообще это говно задача. Ежели ты на фулл тайме я б их послал подальше. Пусть выберут там десяток полей и баста. Либо бери Оракл с анализатором лога. Придется все логи хранить но зато какой фронт работ!

Vovchik писал(а): Ежели MS SQL Server и делать все в одной таблице - то будет тормозить хот ты что делай. Теоретически не должно но на практике будет. Так что лучше разбить на несколько таблиц.

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

Vovchik писал(а): А вообще это говно задача. Ежели ты на фулл тайме я б их послал подальше. Пусть выберут там десяток полей и баста.

Задача не стоит отследить изменение всех полей. Задача - отследить все изменения некоторых полей, но в разных таблицах.

StS писал(а):

Vovchik писал(а): Ежели MS SQL Server и делать все в одной таблице - то будет тормозить хот ты что делай. Теоретически не должно но на практике будет. Так что лучше разбить на несколько таблиц.

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

Vovchik писал(а): А вообще это говно задача. Ежели ты на фулл тайме я б их послал подальше. Пусть выберут там десяток полей и баста.

Задача не стоит отследить изменение всех полей. Задача - отследить все изменения некоторых полей, но в разных таблицах.

Тормозить будет всегда (практически) поскольку в мелкомягком (да и во многих других базах) блокировки сделаны по АНСИ принципу который сосет однозначано. В нем читатели блокируют писателей и наоборот. Во избежание сего факта мона делать все вне трансакции (вряд ли получиться) и-или сделать чтение сей таблицы без блокировок вообще. Тыда читатели будут читать грязные данные. На вставку мона добиться приемлемой производительности но для этого придется опять таки раскошелиться на железо поскоку этот лядский мелкомягкий любит локи эскалировать не так как положено. Плюс триггеры плохо влияют на перформанс.
Ежели полей не слишком много то мона обойти одной таблицей. Ее содержимое затем ночью кидать в амбар данных и таблицу опустошать. А читать юзеры будут большую таблицу из амбара данных. Сие будет оптимальный вариант плюс достаточно переносимый между платформами. Тока триггеры надо переписывать каждый раз. Заместо триггеров мона сделать все ручками в приложении и тогда хоть роман пиши и засовывай куда хошь. Это может быть производительнее (но не обязательно) но гораздор больше прострора для ашипок. Зато мона попытаться чдеть все в ANSI SQL и тыда все будет переносимо.

Всем спасибо.
Отдельное спасибо Вовке за триггеры и Вовчику за амбар.