ВладимирМПроблема в чем? Это Вы сейчас помните, что .T. = мужчина? Почему собственно? Просто потому, что лично Вы так решили. Убедительно. Кроме шуток, это часто решающий аргумент.

Но представьте себе, что с Вашим приложением будет разбираться Лисонька . А для нее .T. = женщина. Просто потому, что для нее это "совершенно очевидно".
Не вижу такой проблемы.
Вижу другую проблему: некий программист пытается разбираться в чужих таблицах исключительно на основе своих догадок , игнорируя описания структур. Вот это действительно проблема и гнать надо подальше таких программистов.

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

Анекдот в тему догадок:
--------------------------------------
Девушка в гостях у парня. Захотела умыть лицо.
Выходя из ванной, говорит:
- Я там у тебя увидела два полотенца - "М" и "Ж". Взяла "Ж". Я правильно догадалась?
- Вообще-то, "М" - это для морды.
--------------------------------------
:)

ВладимирМВы сознательно закладываете в собственное приложение неопределенность еще на уровне структуры базы данных. Есть некое "умолчание", "соглашение", которое никак, никоим образом, не вытекает ни из структуры базы данных, ни из его содержимого.
В чем проблема? Назовите логическое поле IsMale (IsFemale или что-нибудь в этом роде) и вот уже нет никакой неопределенности.

ВладимирМРазумеется, без таких умолчаний иногда не обойтись. Но зачем это делать в таком очевидном случае? Ведь Вы не получаете совершенно никаких выгод, кроме недостатков.

Логическое поле в файле DBF физически занимает 1 байт, значит, выигрыша в размере по сравнение с М/Ж - нет. Наглядность данных по сравнению с символьным полем - ухудшается. Требуется дополнительное программирование, чтобы преобразовать .T./.F. в М/Ж в отчетах. Дополнительные проблемы при отсутствии преимуществ.

Никакие выгоды, кроме недостатков, говорите? Дополнительные проблемы при отсутствии преимуществ?
Хорошо, вот мое мнение по поводу достоинств и недостатков:

Одинаково для обоих полей:
- Размер поля.
- Вывод в тех отчетах, где требуется либо расширенный вывод (Мужской/Женский, Муж/Жен и т.п.), либо любой вывод на другом языке.

Преимущества символьного поля:
- Простота вывода (на экран или в отчеты), где требуются просто "М" или "Ж".
- Наглядность при просмотре таблиц напрямую (актуально только для программистов и администраторов БД, которые лазят в таблицах напрямую, а не через программы для пользователей, в которых можно запрограммировать какой угодно показ и для символьного, и для логического поля).

Преимущества логического поля:
- Проще программировать в логических операциях (например, where <field> вместо where <field>=='М'). Кроме того, исключаются ошибки, когда программист при написании очередной логической операции забыл переключить раскладку и набрал английскую 'M' вместо русской 'М'.
- Быстрее работает в логических операциях (особенно это актуально в циклах и на больших объемах данных).
- Если у символьного поля есть преимущество в наглядности при просмотре таблиц напрямую, то у логического поля есть преимущество, если программист или администратор БД захотят увиденную ошибку откорректировать напрямую. Если какая-то таблица не имеет встроенного контроля значений поля, то в случае символьного поля проблема раскладки может привести к труднообнаружимым ошибкам, которые могут годами оставаться незамеченными.
- Если предполагается обмен с другими программами, то проще контроль входных данных - в логическом поле запрещенных значений в принципе быть не может (входная проверка поля не нужна вообще), а в символьном поле запрещенных значений - завались (требуется входная проверка поля).
- Если сейчас или в будущем предполагается обмен данными с таблицами на других языках (национальные языки народов России, стран СНГ и других государств), то корректнее именно логическое поле. Кстати, в этом частном случае все преимущества символьного поля не только "идут лесом", но и превращаются в недостатки.