Několik menších tabuelk vs. jedna velká tabulka

Dobrý den,
řeším takový to problém, možná malicherný, ale přesto bych na něj rád znal odpověď, oč se jedná:
Mám databázi adres, momentálně v klasickém relačním modelu, z ministerstva vnitra, bohužel se po nějaké době, jejího používání, ukázalo, že je nekompletní (není hlavní problém) a některé adresy podle klíčů se neschodují se skutečností ( což je, promiňte mi to slovo: průser a hlavní problém, vzhledem k tomu že obsahuje cca. 2,8 milionu adres), znamená, že některé skutečné adresy nejdou nikdy vybrat. Padlo tedy rozhodnutí najít jinou DB adres, po dvou týdnech hledání a testování se ukázala jako nejlepší databáze od ČÚZK, i když dát ji do použitelného stavu spotřebovalo dávku trpělivosti na příští dva měsíce. Bohužel s novou DB adres přichází i nová struktura tabulek v DB a tady stojím na křižovatce kterým směrem se dát. Vzhledem k tomu, že se z této databáze adres bude pouze číst, přemýšlím o možnosti udělat jednu velkou tabulku ve které bude vše, místo několika malých relačně spojených tabulek. Hledal jsem na internetu nějaký článek, který by mě od toho odradil a vysvětlil proč to tak neudělat, ale marně. Důvod proč to tak chci udělat je ten, že se tím značně zjednoduší spousta jiných dotazů, které s tabulkami adres pracují. Rád bych tedy znal názory odborníků, i "odborníků", na můj problém, ještě dodám, že přístup k adresám v databázi je nyní zhruba 1000x denně a očekává se do budoucna až dvaceti násobek, předem děkuji za odpověď.

Kajman:
„Tak si jen udělejte view a používejte ho v dotazech.“
Ano to není špatný nápad, ale trochu se bojím, v případě složitějších dotazů o rychlost (netetoval jsem ovšem), ale ze zkušenosti vím, že špatně použitý pohled v dotazu dokáže prodloužit dobu vykonání i na několik desítek sekund, vzhledem k tomu, že s databází pracují i jiní lidé než já (tj. mají možnost klasických operací: SELECT, INSERT, UPDATE a DELETE nad daty a CREATE TABLE), nerad bych jim takovou možnost poskytl, už jen proto, že po roce používání stále nacházím chybějící indexy nad sloupci.

peta:
„Struktura? Selecty? Zalezi na tom, jake informace, jakymi selecty chces jak casto tahat a jak vypada struktura.“
Struktura: Zbytek DB je navržen na 3 normálovou formu, jestli se ptáš na tohle a databázoví engine je MyISAM.
Selecty:
Prvně tedy ke složitosti samotných SELECT dotazů - používají se UNION, vnořené SELECTy, WHERE, GROUP BY, ORDER BY, agregační funkce, JOINy a LIMIT, to je vše. Žádné procedury, funkce, triggery atd.
Co se týče informací, tak si myslím, pokud je řeč o adresách, že se pravděpodobně budou vybírat informace o adresách, nejdelší možná kombinace (pominu-li že taková adresa neexistuje) je v objemu dat 300B a to když budu opravdu hodně přesný a v adrese uvedu i zeměpisné souřadnice. K adresám se ve většině případů přistupuje přes konkrétní ID, které přesně identifikuje konkrétní, a jednu jedinou, adresu, dalším častým dotazem je výběr přes PSČ, které výsledek omezí u nejčastějšího PSČ v databázi na 14500 záznamů (u třicátého PSČ to už je jenom 7000, přičemž počet PSČ je 2680), vezmu-li tedy průměrnou adresu na kterou připadá 200B je objem dat přibližně 2,7MB při maximálním možném výsledku a výběru celé adresy, reálně to pak je 600kB, vzhledem k tomu, že se nikdy celá adresa nevybírá.
Jak často je uvedeno v [#1] na konci.
*objemem dat je myšlena pouze užitková informace adresy, tj. ta část která se někde zobrazí (vypíše), přepošle dál nebo použije v programovém kódu třeba pro IF.