Разрабатываю уровень хранения данных приложения. И вот какое интересное поле потребовалось - дата с точностью до месяца. То есть, по сути, интересует только число года и номер месяца в году. Озадачился способом хранения такого поля. Пока только два "лобовых" варианта на ум приходят:
а) хранить как дату, при работе не обращать внимания на день;
б) хранить как целое число порядковый номер месяца (за месяц с индексом 1 выбрать какой-либо определенный месяц в прошлом).

В первом случае теряю на избыточном хранении и постоянных операциях разбиения дат на составляющие в операциях сравнения. Во втором случае будет присутствовать некоторая "запутанность" в интерпретации данных (не особо страшно, поскольку логика работы с таким полем будет либо реализована в базе, либо вынесена на уровень компонентов доступа к данным).

Может быть, уважаемые гуру подадут еще какие-то идеи? Или ссылками на статьи по этой теме поделятся. Буду благодарен.

ololПривет земляк, а зачем надо дату разбивать на составляющие?
Можно ведь числу всегда присваивать 1.
Привет, olol.
Можно и единицу присваивать, конечно. Не суть важно, каким будет число в дате, если его все равно предполагается игнорировать. Есть значения дат, хранящихся в столбце. Есть значение даты для выборки нужных записей. В запросе придется пойти одним из двух путей:
а) сравнивать значения года и месяца (разбиение даты на составляющие);
б) вычислять разницу между датами (использование функции вроде datediff).

авторА вообще-то формат DATA в разных базах реализована по разному...
Ты хотел сказать о типе Date , а не Data . :)
Конкретная реализация на этапе проектирования меня не должна волновать. Достаточно того знания, что во всех современных СУБД есть достаточно функциональности для работы с этим типом данных.

Большое спасибо всем, кто участвовал в обсуждении! Я принимал во внимание почти каждый комментарий. В конце-концов, решение о хранении номера месяца отпало само-собой после того, как были написаны и проведены тесты для обоих решений. Решение о хранении номера года и номера месяца в отдельных полях было отвергнуто сразу (извини, Cat2 ). То же самое и для решения о кодировании и расшифровке текстовых строк (извини, gardenman ).

Итак, с датой оказалось работать удобнее, причем без той потери производительности, которой я изначально боялся. Реализация - для Microsoft SQL Server 2000 (была выбрана эта платформа).

P.S. Согласен с f2f : в смысле проектирования sparrow предложил хорошее решение. Но дело в том, что денормализации оно все равно "не выдержит", на мой взгляд.

В Microsoft SQL Server 2000 есть два типа данных для хранения дат: smalldatetime, datetime. Конечно, я выбрал smalldatetime .