Здравствуйте уважаемые форумчане. Подскажите идею по проектированию БД на MySQL.
Имеется ДБФ файл следующей структуры :

`MONTH` int(4) // Месяц
`YEAR` int(4) // Год
`MAIN_IND` // главный индекс товара
`NAM_IZD` varchar(254) // Наименование товара
`DEP_IND` text // Дополнительный индекс товара
`POST_IND` int(9) // Почтовый индекс магазина
`NAM_TRAKT` varchar(254) // Название магазина
`KOL` int(9) // Количество товара

На основании этого файла нужно сформировать БД.Я создал 3 таблицы следующей структуры:
Таблица в которой названия всех магазинов (100 записей)
CREATE TABLE `department` (
`ID_POST` int(9) NOT NULL AUTO_INCREMENT, // первичный ключ
`POST_IND` int(9) NOT NULL, // почтовый индекс магазина
`NAM_TRAKT` varchar(254) NOT NULL, // название магазина
PRIMARY KEY (`ID_POST`),
UNIQUE KEY `index_post` (`POST_IND`)
)
Таблица по всем товарам (3000 записей)
CREATE TABLE `editions` (
`ID_PUB` int(9) NOT NULL AUTO_INCREMENT, // первичный ключ
`MAIN_IND` int(9) NOT NULL, // главный индекс товара
`DEP_IND` varchar(254) DEFAULT NULL, // дополнительный индекс товара
`NAM_IZD` varchar(254) NOT NULL, // название товара
PRIMARY KEY (`ID_PUB`),
UNIQUE KEY `ID_MAIN` (`MAIN_IND`)
)

Таблица заказов ( 200 000 записей)
CREATE TABLE `orders` (
`ID_ORDER` int(11) NOT NULL AUTO_INCREMENT, // первичный ключ
`ID_PUB` int(9) DEFAULT NULL, // первичный ключ таблицы магазинов
`ID_POST` int(9) DEFAULT NULL, // первичный ключ таблицы товаров
`m_MONTH` int(4) DEFAULT NULL, // месяц
`y_YEAR` int(4) DEFAULT NULL, // год
`KOL` int(9) DEFAULT '0', // количество товара
PRIMARY KEY (`ID_ORDER`)
)

И возникает проблема. Количество товаров меняется каждый день. Тут проблем нет.
Но главный индекс товара, количество подчинённых индексов ,название товара для главного индекса время от времени меняются.
А накладные то ведуться…Если я эти данные буду менять в таблице товаров, то нету просмотра истории, потому что через 3 дня такой же товар может уже идти под другим индексом.Как сделать так,чтобы отслеживались изменения, чтобы можно было видеть
как мигрирует индекс в течении месяца.
Заранее спасибо.

Chop,

К сожалению это правда. Вот пример
MAIN_IND | DEP_IND | NAM_IZD
89015 | 7201;7356; 2341 | Счастливая и красивая
Через месяц
7201 | 7356;2341;89015 | Счастливая и красивая

Я подозреваю, что у меня не хватает знаний, для того ,чтобы это всё автоматизировать.
Потому и прошу у вас помощи.
Есть программа, она мне выдаёт результат работы в виде ДБФ файла, структуру которого я указал выше. Люди, которые работают с программой могут сами переназначить индекса, тесть подчинённый индекс сделать главным и наоборот.
И мне нужна такая структура БД, чтобы она работала по факту. Получил файл ,если есть изменения в количестве изданий или наименовании издания или подчинённых индексах добавить их в базу.

Злой Бобр,

Наверное я не правильно выразил мысль. Есть готовый софт, купленный, не мой. Этот софт используется на одном участке. Он даёт информацию в графическом виде и в виде ДБФ файла.
На другом участке есть накладные, туда приходит товар а потом расходиться по всем магазинам.
Задача второго участка, на основании ДБФ файла быстро всё отсортировать по магазинам , разложить по стопочкам. Я создал базу данных которую указал выше, написал клиент на jave,и всё работает. Но время от времени возникают небольшие сбои в связи изменением индексов.
Можно было поступить проще, базу данных вообще не делать, зачем эта история вообще нужна ? Но такой номер не пройдёт, потому как накладная может прийти за позапрошлый месяц, и хочешь не хочешь а вести её надо. Потому я и прошу у форумчан помощи, мне не нужны готовые решения в виде готовых процедур и триггеров, сам справлюсь. Мне нужен дельный совет, как спроектировать БД так, чтобы возможен был обратный синтез информации? Восстановить исходный ДБФ файл во временном разрезе учитывая все изменения что до этого вносились. Если эта задача решаема, то всё остальное просто вопрос времени и прямых рук.
Спасибо всем кто отписался или отпишется, ваше мнение для меня очень важно.
С Уважением.