mynewvk: я понимаю, просто это усложнение логики. конкретно в данном случае это уместно (может быть. все еще зависит от интерфейса управления этой системой). но в более общем случае эта модель совершенно не масштабируемая. по крайней мере, потому что количество подгрупп может быть только 2. если появятся еще дополнительные занятия и выделится еще одна подгруппа студентов, то придется снова лезть в логику приложения. разделение на подгруппы - это организационный вопрос, который лежит не в зоне ответственности программиста и программы как таковой, это ответственность управляющего, следовательно программа должна быть простой и должна уметь делать минимально-возможную атомарно-целлостную операцию.
mynewvk: я бы минимальной единицей, для которой составляется расписание, считал одну подгруппу и заполнил бы первоначальные данные в избыточном виде. 2 подгруппы это не 100. и управление в этом случае будет более очевидное. то есть, в моем предложении ты составляешь отдельные расписания на каждую группу, дублируя некоторые данные. а так - да, "together" это вариант, только тебе придется делать еще логику по приоритетам и понимать, что делать, если данные перекрывают друг друга. то есть, получится, непонятное поведение, если на одну группу будут данные в ее описании и в "together" одновременно
