Как мне обрабатывать прогрессивные коды состояния в базе данных?

Question

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

Администрация колледжа недавно пересмотрела политику академических стандартов колледжа. Раньше у администрации было только три кода статуса, так что это не было большой проблемой. Однако новая политика имеет шесть кодов статуса:

1. Хорошее состояние
2. Академический концерн
3. Академическое вмешательство (1)
4. Увольнение на один срок
5. Академическое вмешательство (2)
6. Четырехместное увольнение

С этого момента я буду различать GPA для данного термина, произнося termGPA, и совокупный GPA, говоря cumGPA. Если termGPA студента падает ниже 2,0, и это приводит к тому, что его / 10 * cumGPA также падает ниже 2,0, он / она попадает в Академический концерн. Однажды на Академическом Концерне, одна из трех вещей может произойти со студентами в следующих условиях. Они:

1. Вернитесь к хорошей репутации, если их termGPA и cumGPA поднимутся выше 2,0.
2. Оставаться в текущем состоянии, если их termGPA выше 2,0, но их cumGPA остается ниже 2,0.
3. Перейти к следующему статусу, если их termGPA и cumGPA ниже 2.0.

Обычно я подхожу к этому процессу, написав консольное приложение, которое обрабатывает каждого учащегося итеративно и строит коды состояния на ходу. Однако мы принимаем не менее 8000 студентов, а в большинстве случаев около 12 500 студентов в семестр.

Кроме того, эта политика должна применяться задним числом в течение еще не определенного периода времени (поскольку бывшие студенты могут вернуться в колледж и затем будут подчиняться ограничениям новой политики), и как только я включу студента в набор данных, я должен вернуться через всю историю этого студента с колледжем. Я консервативно предполагаю, что пройду не менее миллиона студенческих записей и вычислю семестр каждого учащегося и скользящий балл cumGPA.

Вопросы:

1. Есть ли способ решить эту проблему в SQL и избежать использования курсора?
2. (при условии, что ответ на вопрос 1. «Нет») Как мне структурировать консольное приложение? Должен ли я создавать большую коллекцию и обрабатывать несколько тысяч студентов за раз перед записью в базу данных или обновлять базу данных после каждой обработки каждого студента?
3. Я слишком об этом договариваюсь?

Заранее благодарим за понимание и советы.

---

Редактировать: Основываясь на комментариях к ответам здесь, я должен был предоставить больше информации о структурах данных и способах вычисления GPA.

Я не могу использовать предварительно вычисленные значения cumGPA в нашей базе данных - мне нужен cumGPA студента в конце каждого прогрессивного семестра, например, так (примечание: я составил значения GPA ниже):

ID      TermID  CumGpa  TermGPA TermNumber PolicyCode
123545  09-10-2  2.08   2.08      1         GoodStanding
123545  09-10-3  1.94   0.00      2         AcademicConcern
123545  09-10-4  1.75   1.00      3         AcademicIntervention
123545  10-11-2  1.88   2.07      4         AcademicIntervention
123545  10-11-4  2.15   2.40      5         GoodStanding
123545  11-12-1  2.30   2.86      6         GoodStanding

Проблема заключается в том, что код состояния каждого последующего термина может зависеть от кода статуса предыдущего термина - фактически, только хорошее положение.

Насколько я знаю, это означает, что мне пришлось бы использовать курсор в SQL, чтобы получить самый последний код состояния каждого учащегося, что меня не интересует, так как я работаю в колледже с нехваткой денежных средств, который имеет ровно три сервера базы данных: один для тестирования и два сервера с одинаковыми данными на них (мы находимся в процессе перехода на SQL Server 2008 R2).

Answer 1

В итоге я написал консольное приложение на C # для обработки этих кодов состояния.Мои пользователи изменили первоначальные требования к обновлению статуса, включив в них только два предыдущих термина, но у этого процесса было достаточно крайних случаев, и я решил потратить свое время и написать более чистый, объектно-ориентированный код, который будет легче подобрать (он говорит:надеюсь) после того, как эта политика созреет и изменится.

Кроме того, мне пришлось развернуть эту базу данных на экземпляре SQL 2005, поэтому табличные параметры были мне недоступны.Если бы это было так, я бы предпочел зафиксировать базу данных только после обработки каждого студента, а не после обработки каждого термина для каждого студента.

Answer 2

Прежде всего, 12 000 записей - ничто для современных баз данных, так что это не ваша забота. Вы должны сосредоточиться на простоте. Похоже, что ваша база данных будет зависеть от событий, поэтому я бы рекомендовал использовать триггеры, например: fisrt trriger, когда ваш termGPA вставлен - обновите cumGPA, второй после обновления cumGPA - проверьте ваши критерии и обновите статус, если они произошли.

Answer 3

Даже бесплатная версия SQL теперь обрабатывает базы данных до 10 ГБ.12500 записей мало.Пройдя хотя бы 1 миллион записей, вы должны указать его каждому ученику или группе, чтобы очистить журнал транзакций.Это можно сделать с помощью курсора или консольного приложения.Если вы можете выполнить вычисления в TSQL, то пакетирование их будет, вероятно, быстрее, чем по одному за раз.Обратная сторона - чем больше партия, тем больше журнал транзакций, поэтому есть приятное место.Если вычисление является слишком сложным для TSQL и занимает почти столько же времени (или дольше), чем оператор вставки, вы можете вставить его в отдельный поток (или вычислить в отдельном потоке), чтобы операции вставки и вычисления выполнялись параллельно.Я делаю это в приложении, где я разбираю слова вне текста - анализ занимает примерно столько времени, сколько нужно для вставки слов.Но я не позволяю ему раскручиваться в нескольких сериалах.Что касается SQL, ему все еще приходилось поддерживать индексы, а попадание в него вставками из двух потоков замедляло его.Всего два потока, и более медленный поток ожидает медленнее.Порядок ваших обновлений также имеет значение.Если вы обрабатываете в порядке кластеризованного индекса, у вас больше шансов, что запись уже находится в памяти.

Answer 4

Это интересно.Я не думаю, что вам придется слишком сильно беспокоиться о производительности SQL.Он будет работать довольно быстро для вашего приложения.Я просто запустил маленькое глупое консольное приложение, чтобы исправить ситуацию, и вставил 15000 записей по одной за раз.Это заняло около 5 секунд.