Есть таблица в которой хранится записи о заказах. В ней порядка 30 полей разных типов. Записи в таблице очень динамически изменяются.
Нужно создать вторую таблицу, в которой будет происходить "логирование" изменений, производимых с записями из первой таблицы.
Это будет, так сказать, "история ведения заказа". Затем записи из второй таблицы будут выводиться в хронологическом порядке в некой "событийной форме". При этом как для текстовых полей, так и для булевых, нужно будет выводить "старое" и "новое" значение. Естественно, булевые поля нужно будет выводить в какой-то более удобочитаемой форме, чем нолики и единички. Задача усложняется ещё тем, что данные должны выводиться на двуязычный сайт, т.е. при выводе названий полей должны использоваться языковые переменные. И разным пользователям должна выводиться информация по разным полям в зависимости от их уровня доступа. По итогу, пользователь должен увидеть на выходе примерно такой список.
1) заказ создан тем-то и тогда-то
2) заказ проверен и отправлен в работу тем-то и тогда-то
3) тех. описание изменено с такого-то на такое-то тем-то и тогда-то
..) и т.д.

Может кто подскажет какая структура второй таблицы будет наиболее оптимальной?
Возможно придется создать какую-то вспомогательную таблицу к этой таблице, в которой будет храниться информация по названиям полей, их уровню доступа и пр.

debloggerДолжно быть поле создания записи. По нему сортируете и получаете всю историю вопроса для каждого ключа.
"ИД записи во второй таблице", "дата создания" и "кто создал" (т.е. кто редактировал запись в исходной таблице) -- это естественно должно быть. При желании можно ещё и IP здесь сохранить на всякий случай. Скорее всего так и сделаю.
Меня сейчас больше волнует остальная часть таблицы.

deblogger ,
То, что вы предлагаете использовать энумирацию для булевых полей вопрос конечно же интересный. Однако, во-первых, как её использовать в конкретно этом случае? В основной таблице есть несколько булевых полей с разными значениями значит потребуется несколько разных энумерованных списков. Как в таком случае их использовать? Создать все 30 полей в новой таблице? мне кажется, что это не вариант. Создать два поля "старое значение" и "новое значение"? Но как тогда подружить в них несколько разных энумерованных списков и как они будут дружить с остальными типами данных (текст, числа, даты). И как сделать так, чтобы пользователь видел перевод этих полей, т.е. одному должно выводиться ('yes','no'), а другому ('да', 'нет')? На сайте есть система переводов, но в таком случае нам нужно будет подставить в скрипт не значение поля ('yes','no'), а некие языковые переменные. Где их в таком случае хранить и как лучше подставить в нужном месте?

Есть ещё "поля подстановки", когда хранится код записи из другой таблицы и при выводе данных пользователю. Как сделать, чтобы в таком случае выводились актуальные данные?

Я понимаю, что вопрос возможно не тривиальный, но может кто-то из форумчан решал хоть что-то похожее?

Cygapb-007,

Спасибо. Там действительно много интересного.