Проектируем базу. Вопрос более теоретический, чем практический.
Есть таблица студентов. Они могут перемещаться между группами на оснавании приказов, а также могут отчисляться/заканчивать и восстанавливаться в любой группе. Соответственно для этого есть таблица групп. Приказ на перемещение формируется для множество студентов, а также требуется, чтобы приказ можно было "откатить", а при случае снова активировать("накатить"). Для этого формирую таблицу приказов и еще одну таблицу для списка студентов, входящих в приказ. При активации приказа(т.к. сказать формирование проводки) в зависимости от его типа формирую, либо обновляю строку перемещения в таблице перемещений. Таблица перемещений выглядит следующим образом:

ID | Grp | StartDate | EndDate | IDorder1 | IDOrder2

ID - первичный ключ
Grp - группа в которую перемещен студент
StartDate - дата с которой он находится в этой группе
EndDate - дата до которой он находится в этой группе
IDOrder1 - на основании какого приказа он зачислен
IDOrder2 - на основании чего выбыл

Соответственно есть 3 типа приказов:
1 - на зачисление( формируют новую строку в таблице перемещений и заполняют поле StartDate, IDOrder1)
2 - на перемещение( проставляют IDOrder2 и EndDate в строке предыдущего перемещения и формируют как и в 1 случае )
3 - на отчисление( проставляют IDOrder2 и EndDate в строке предыдущего перемещения )

Такая схема обеспечивает то, что на любую дату можно однозначно, без дополнительных вычислений узнать в какой группе находился студент из соотношения( StartDate<= Date <= EndDAte).
Мой коллега однако не согласен с такой структурой и считает, что на каждый приказ должна быть заведена отдельная строка в таблице перемещений, а таблица студентов учавствующих в приказе вовсе не нужна, так как это дубляж данных.

что можете посоветовать?

Но тогда таблица 8 не будет иметь структуру, удобную для формирования отчета. Т.е. отчеты в большинстве своем смотрят на принадлежность стунта группе на заданную дату. Так?

авторЯ таки и не понял что предлагает ваш коллега.
Примерно тоже, что и вы
Примерно следующая реализация таких передвижений:
автор1. Таблица приказов
2. Таблица пунктов приказов (ведь приказ может иметь пункты, если вы их к-л видели). Движения "делаются" именно пунктами. Пункты разных категорий, все в одной табличке.Пусть будет проще - приказы должны быть одного типа(зачисление, отчисление, перевод)
автор3. Есть таблица "студент в пункте приказа". Служит для подготовки приказа, в д.с. методисткой и для того стобы можно было "достать" в базе п. приказа и посмотреть че там понаделано чьими-то корявыми ручками Это предлагаю я, а коллега отвергает.
автор4. Есть куча табличек вида "студент - группа", "студент - состояние" (состояние - это учится , акад. отпуск, повторное обучение, переведен на др. факультет, отчислен, абитура, "зачислен, но не в группе"), "студент - курс", "студент - стипендия", "студент - надбавка к стипендии", "студент - направление/специальность" и т.п. руковолители, дипл. работы, старостенье...
Эти таблички похожи на ту, которую вы привели. Поверьте, группу и состояние лучше разделить по разным табличкам. Т.к. академ отпуск, группа и курс вещи независимые. А еще есть бюджет-контракт!
Не понятен смысл вышесказанного. Я думаю, что таблица состояния это и есть таблица в которой есть №группы, дата с которой он числится, когда уходит из этой группы, а также номера приказов - оснований для его зачисления в эту группу и его отчисления оттуда. Если студент еще не закончил и не отчислен то ДатаКонца = NULL. И тогда есть актуальность на любую дату! Есть специальные группы отчисленных и ушедших в академ.отпуск, т.е. это все-равно группы, только специальные. В таблице групп есть соответствующее поле.
автор5. когда приказ с пунктами "регистрируется", т.е. получает дату и номер, в таблички из п.4 делаются соотв. записи. С откатами жопа, т.к. откатить можно п. приказа, за которым не было движений, аналогично с пунктами "во изменение",суть которых найти пункт, откатить его и проинсёртать свои записи. А юзеры откатить норовят не последние, а те что подревнее пункты.
Заметьте, что приказ об отмене тоже может быть отменен, поэтому в вашей табличке движений не хватает 2х столбиков, чисто для удобства Ж-) Отменить можно только последний приказ. О логировании "откатов", "накатов" можно подумать отдельно(например создать журнал операций с приказами)
авторПо поводу удобства отчетов - это они по началу говорят что на любую дату, потом оказывается - нужны только актульные (последние) данные, а ваши таблички движений нужны для разборок полетов.
Опыт разработки подобных систем подсказывает, что этого все-таки лучше, при возможности, сохранить возможность формирования отчетов на дату.
авторВ связи с чем все признаки студента (курс, группа, состояние etc) при регистрации приказа + ко всему записываются непосредственно в поля таблички студент. Работать приложение существенно быстрее будет, чем если искать по движениям на sysdate.
Сам не понял чё написал.Пройденный этап, как раз от этого и уходим.

Не спорю. Можно(да и кстати, более удобно) использовать эти поля для получения информации на текущую дату, за предыдущие периоды все равно прийдется использовать таблицу перемещений