Cookieкакие преимущества есть в трех полях?
Возможность внести в таблицу бредовые (aka противоречивые) данные, и соответственно необходимость в дополнительном констрейнте вида


Это неправильная постановка вопроса. Exactly - это дополнительная, необязательная сущность. Поэтому ее присутствие - и вызываемые им проблемы - должны быть обусловлены получаемым в связи с этим преимуществом. Какие преимущества из этого можно получить - я лично не вижу; разве что возможность проиндексировать это поле, но зачем может пригодиться такой индекс - хз.

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

Cookie
если значение точно 2, тогда exactly=2, from=null, to=null
если значение от 1 до 2, тогда exactly=null, from=1, to=2
Тогда все равно нужен констрейнт - проверять, что либо то, либо другое null - но все еще веселее, поскольку простейший запрос вида "есть ли в таблице значение X" будет выглядеть так:


и что важнее - выполняться это будет не слишком-то быстро.

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

CookieЗЫ боюсь спорить на эту тему с таким серьезным специалистом
Пора менять ник :((

О. Вы меня порадовали.

gybson
+1.

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

Ввод данных и интерфейс оператора не имеют ровным счетом никакого отношения к структуре БД. Задача интерфейса - ввести данные так, как это следует делать с точки зрения ввода, например в трех полях (если это наилучший вариант). Задача БД - хранить данные так, как это следует делать с точки зрения последующей обработки, например в двух полях (если это наилучший вариант). Задача клиентского приложения в целом - служить драйвером/конвертором между "правильной БД" и "удобно пользователю", в частности, в данном случае, возможно, перекодировать "три в два".

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

ModelRне попадался? Явно требует трех полей.
Совершенно не явно. Вполне может оказаться так, что эту информацию будет оптимальным завернуть в XML, засунуть в EAV или извратиться над ней еще каким-нибудь образом.

ModelRНе исключено, что тот, кто хочет видеть 3 поля, имеет ввиду аналогичную логику. Если задано третье, игнорировать но не удалять значения первых двух
Не исключено. Почему я и сказал, что хотел бы выслушать его аргументацию. Если прочитаете мое письмо, я сказал что не представляю, зачем бы я делал именно так, но допускаю, что задача может этого потребовать.

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