Насколько важно в БД использовать поля разных типов Date/bool/long/integer - VB

Т.е. сейчас начал планировать "структуру полей".
Смысл в чем.
При работе с текстовухами я особо не парился и в куче переменных используются String где по логике могло бы быть Date или boolean, или integer
Т.е. пример: дата хранится как string в формате: DD.MM.YYYY , при отображении я соблюдаю "культурность" и конветирую это как Date с (авто)поправкой на настройки виндов (National standard).
Другой пример, читаю из файла заведомо число и проверяю его наличие как Len(string)>0.
Плюс в БД еще длину String можно задавать up to 255
Я чего боюсь. Счас начну эти Date использовать, таже база на другой системе выдаст автоматом DD.MM.YYYY как MM/DD/YY. А у меня "по точкам" где-то MM и DD вычисляются.
Т.е. где нибудь чегой-то сглючит самым непредсказанным образом.
М.б. не париться и использовать везде "Текстовый" тип, ну где это очевидно не 255 а меньшей длины?
Больше места займет? А намного ли (с т.зр. мировой революции), если скажем пусть даже по 1000(обычно на порядки меньше) строчек (10-12 полей) в 2-х таблицах
Какие рекомендации?
Потом еще не понял пока насколько проблема, просто вспоминаю из прошлого. Напр. там пустая строка TheStr="", а оно мне при запросах начнет выдавать какие-нибудь NULL и хорошо если не на русском. В Access вроде усмотрел "разрешить строки нулевой длины". Т.е. как этот момент переварить.
В текстовухе я использовал структуру:
parametr1=PARAM1;parametr2=PARAM2;parametr3=PARAM3;
причем
parametr1=PARAM1;parametr2=;parametr3=PARAM3;
и
parametr1=PARAM1;parametr3=PARAM3; //упоминание о parametr2 вообще отсутствует
дает одинаковый результат
parametr2=""
Ну, т.е. есть о чем беспокоиться...
Счас пока планирую/конструируб БД в Access2000, потом конечно сделаю "создать" на VB думаю целиком управление через ADODB чтоб не кашей как я это делал раньше для себя(типа одна и та же прога и DAO и ADO + первые попавшиеся контролы, и еще не дай бог объект Access туда же в кучу).