Проблема
Проблема всем известна. Типичный случай: церковь построена во второй половине 17 века, а колокольня, скажем, в 1883 году. Сейчас приходится либо вовсе забывать про колокольню, указывая что-то вроде 1650-1700, либо же брать период целиком: 1650-1883. В первом случае колокольня не находится по поиску объектов XIX века, во втором случае объект попадает в поиск по 18 веку, к которому он не имеет ни малейшего отношения. И то и другое печально. Вывод очевиден: начальной и конечной даты для времени постройки недостаточно.
Проект решения
Я предлагаю поступить следующим образом. Для датировки использовать два поля: первое условно называется "Дата постройки". В нем в свободной форме указываются даты. Например, "вторая половина XVII века, колокольня - 1883 г.". Это поле не используется для поиска.
Второе поле условно назову "Шкала постройки". Это действительно одно поле, но оно предстает в виде таблицы, примерно такой:
Сразу оговорюсь, что набор столбцов пока приблизительный. Мне кажется, однако, что деление менее чем на четверть века не нужно, так как тогда шкала чересчур усложнится, а смысла в нем мало.
Нижняя строка таблицы - это набор флажков, в которых можно ставить галочки, в нашем случае - вот так:
Такая же шкала используется в форме поиска. Например, если нам нужно найти объекты конца XIX - начала XX века, то в поисковом запросе указываем:
Объект находится, так как есть совпадение по одному столбцу. А вот в поиск по 18 веку объект не попадает. Чего, собственно, и хотелось.
Техническая сторона (читать необязательно ) )
Предлагаемый способ основан на побитовом сравнении, что обеспечивает очень быстрый поиск. Шкала переводится в биты, в нашем примере шкала объекта имеет форму двоичного числа 110000000100000, то есть десятичное 24608. Так что это, действительно, одно поле, причем довольно компактное. Запрос имеет форму 110000, то есть 48. Используемая в проекте СУБД позволяет производить побитовое сравнение. Побитовая операция "И" выдает положительный результат при совпадении хотя бы одной позиции со значением 1 (то есть совпадение галочек хотя бы в одном столбце шкалы поискового запроса и шкалы объекта).
Преимущества
1. Структура базы данных практически не изменяется. Никаких новых таблиц и связей. Ограниченный объем допрограммирования.
2. Шкалу исключительно быстро заполнять. Достаточно несколько раз щелкнуть мышкой. Это преимущество я считаю исключительно важным.
3. Поиск очень быстрый.
4. На основе существующих сейчас дат постройки можно автоматически заполнить как поле "Шкала", так и свободное поле "Дата постройки", так что никакого тотального ручного переноса не будет.
Недостатки
Недостаток один и вполне очевидный: невозможность поиска по более мелким периодам, чем указаны в шкале. Но я думаю, что достоинства перевешивают.
Жду отзывов.
