Форум пользователей MySQL

Здравствуйте,
Исходя из прочтённого мною на сайте, понял что дуб-дубом в SQL и был удивлён тому, как подходит админ к каждому вопросу и как вкладывает душу в каждый свой ответ. Искренне надеюсь уделит и мне время.

Меня интересует, как более грамотно распределить информацию по таблицам, в каких случаях лучше использовать существующую таблицу, в каких создать новую. Как использовать индексирование при поиске.

Есть таблица пользователей users и в ней поля, пишу на своё усмотрение, жду критики и советов:
id_user [INT(8)] (PRIMARY KEY) - ключ, для объединения таблиц
email [VARCHAR(32)] (UNIQUE)
pass [CHAR(32)] - так как поле постоянной величины (всегда 32), думаю грамотнее будет использовать именно ЧАР (ВАРЧАР в этом случае будет +1 бит при хранении данных) 
status [INT(1)] - типичный статус: 1- админ, 2- модер, 3- пользователь
name [VARCHAR(48)] - ФИО
country [INT(3)] - Страны хранить логичнее в цифрах, потом преобразовавать при выводе (так меньше места :-))
city [INT(4)] тоже, что и страны

Далее таблица объявлений offer1, впринципе думаю правильнее на каждый тип объявлений делать отдельную таблицу:
id_user [INT(8)] - для объединения таблиц offer1 и user
id_offer1 [INT(8)] (PRIMARY KEY) - номер объявления
title [VARCHAR(128)] - заголовок, по нему проводится выборка, но не всегда. Иногда при запросе пользователи не указывают его, поэтому не знаю, стоит ли его включать в индекс, жду подсказки
opisanie [VARCHAR(8192)] - не уверен, но кажется для такой длины наиболее оптимально использовать ВАРЧАР. Стоит ли его включать в индекс, но иногда по нему тоже происходит выборка (в поисковой форме стоит текстовое поле, а под ним чекбокс - искать в описании, если поставить галочку, поле тоже включается в выражение WHERE только методом ИЛИ)
country_offer1 [INT(3)] - Даём возможность пользователю размещать объявления не только в своей стране. Думаю стоит включать в индекс, так как основной критерий отбора
city_offer1 [INT(4)] - Даём возможность пользователю размещать объявления не только в своём городе. Думаю стоит включать в индекс
datetime_offer1 [DATETIME] - так же думаю стоит включить в индекс, так как по дате происходит сортировка объявлений, то есть показываются самые свежие и т.д. по убыванию. Но опять не уверен, жду подсказки.

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

Стоит ли в таблицу включать поле, например confirm и давать ему два значения 0- объявление не проверено модератером, 1- объявление разрешено для показа, или всё же объявления ожидающие проверки лучше хранить в отдельной таблице? (с перспективой на миллионное количество записей) Такой же вопрос и по поводу архивации объявлений, если пользователь в данный момент решил снять объявление, стоит ли давать ему другой статус или всёже лучше хранить в другой таблице.

Можно ли использовать разные(содержащие несколько полей (сорри, не знаю как правильно называется)) индексы для одной таблицы и одинаковых полей, например:
ADD INDEX(country_offer1,city_offer1,title,opisanie) для offer1
ADD INDEX(country_offer1,city_offer1,title) для offer1
ADD INDEX(country_offer1,city_offer1) для offer1
Можно ли так схитрить? Если можно то как правильнее сделать?
Может при ИНДЕКСИРОВАНИИ использовать id_user?

И ещё вопросик, например пользователь забанил другого пользователя и не хочет видеть его объявления, создаём новую таблицу ban
id_user - пользователь
id_user_black - ид забаненого пользователя.
Как мне сделать запрос к таблице объявлений, чтобы исключить из неё все объявления забаненного пользователя?

И последний вопрос, читая форум частенько встречал РК - как это расшифровывается?

Пока писал сообщение, половину вопросов позабывал, так что ещё напишу.
Надеюсь на помощь.