Сейчас работаю над проектом, представляющий из себя огромный бизнес-портал. Приобретаем базы данных по городам, общие параметры:

Группы -> рубрики -> сферы деятельности

А потом по каждому городу (городов очень много) идут фирмы, фирмы, естественно, в каждом городе разные. Все это связано и должно довольно резво работать. Возник такой вопрос, как лучше все это реализовать?

Сделать для каждого города свою базу данных а-ля novosibirsk, moscow, barnaul и т.д., где будут храниться свои данные. 

Или же просто в одной базе сделать разные таблицы на примере novosibirsk_firms, moscow_firms и т.д.?

Запросы могут быть разные, при чем они могут одновременно запрашивать данные по разным городам одновременно, поэтому подскажите какой лучше выбрать метод реализации?

понимаешь, огромный - понятие более, чем растяжимое. 
для тебя - 20 000 предприятий покажутся громдным количеством, а кто-то обрабатывает инфо о 100 000 и думает о расширении базы.
потом, кроме количества записей, сильно на нагрузку влияют количество запросов(200 запросов в час или в секунду) и характер запросов.
кроме того, если планируется какой-никакой поиск по этим данным, то структура БД, максимально ускоряющая выборку необходимой информации может оказаться неудобной для гибкого поиска или же вообще - делающей нормальный поиск невозможным(как пример, хранить ВСЮ инфорамцию о предприятии в одном BLOB-поле проще и быстрее, если если тебе для выборки надо эта "вся информация", но поиск по улице или по номеру телефона при такой структуре станет практически невозможным).
это я к чему? универсальной структуры нет. любое решение будет компромиссом между ускорением одних операций и замедлением других. следовательно, ты сам должен определиться. потому как только тебе известны ньюансы(например, предполагается поиск по количеству сотрудников или сортировка по дате регистрации в системе, или же поиск вообще не нужен, зато нагрузка будет составлять 2000 запросов в секунду).