Создаю БД, в которой содержится таблица для учета рабочего времени - сколько дней отработал тот или иной сотрудник в конкретный месяц. В таблице "Учет рабочего времени" создаю поля: "ID-сотрудника", "ФИО", "Месяц", "Год", "Список отработанного количества часов". Первые четыре поля понятно что будут хранить и как, а пятое поле предполагаю заполнять примерно следующим образом: "8,8,8,8,8,В,В,А,6,6,8,8,В,В,8,8,...", где числа - это количество отработанного времени в определенный день, "В" - обозначение выходных дней, "А" - административный отпуск(порядковый номер каждого элемента в строке представляет собой день месяца). Но такую методику хранения данных, мягко говоря, можно назвать только "очень странной", т.к. если при работе через сам SQL Server по случайной или преднамеренной ошибке пользователь для января вместо 31 значения введет 41, то все рухнет. Плюс к этому, данный принцип нарушает некоторое количество правил проектирования БД, что не есть хорошо.
Немного подумал и решил поискать в SQL реализацию такого понятия программирования, как "Динамический список" - структура данных переменной длинны, но в SQL если "думать по-топорному" он реализуется с помощью добавления дополнительных полей в таблицу - 31 поле только для хранения дат - это через чур. Больше ничего придумать не могу.
Может кто сталкивался с такой проблемой? Как решали, какой тип данных использовали?

Ejhi Работники
IDFIO1Петров2Иванов

Типы дней
TIDNAME1Рабочий2Выходной

Отработанные дни
IDTIDDATEHOURS122011-01-096.5112011-01-108112011-01-118212011-01-108.5212011-01-117.5
Программист-ЛюбительТабель отработки
IDГодмесяцденьОтработка1201111Праздник1201112Праздник...120111138 часов120111146 часов

В принципе и так можно сделать, НО по-моему прослеживается некоторая избыточность данных... Ладно, допустим в компании работают 100 сотрудников и необходимо хранить их табели в течении 10 лет(условность), делаем небольшие подсчеты: 100сотрудников*10лет*364дня=364000 записи=>ладно, требуется более-менее нормальный объем памяти для хранения такого! Теперь допустим, что работников у нас не 100, а 10000. Выполняем те же расчеты и получаем 36'400'000=>примерно переводим необходимую память для хранения этого в байты и получаем базу объемом в несколько гигабайт(десятков гигабайт) и это если сотрудников только 10000 и нет других таблиц, а если их 100'000 или 1'000'000(возьмем какую-нибудь очень крупную транснациональную компанию) и т.д., то это никакого винчестера не хватит для хранения БД! Теперь возьмем, что БД строится не таким образом, а как хотелось мне(если бы это было доступно)-усложняется процесс разработки-несмоненно "да", однако мы избавляемся от дублирования четырех полей(ID, фамилия, имя,...) и соответственно экономим не хило память-оно нам надо-желательно, стоит ли "игра свеч"-по-моему вполне.
Видимо придется накладывать одно ограничение - в базе могут храниться не данные за каждый день в виде списка, а суммарное количество отработанного времени за каждый месяц.