1 - No existe foreign keys en tablas Myisam es un motor no transaccional
(Si quieres controlar las actualizaciones, eliminaciones de una tabla padre a una tabla hijo, requeriras apoyarte
en la creacion de TRIGGERS)

2 - En la sección Amarilla Superior, donde hace mencion a Noticias & Comentarios. En relacion al campo 'hora'
si realmente vas a guardar una hora te convendria el tipo de dato TIME en vez de INTEGER, ya que supongo la hora
sera colocada tipo '03:00:20' por ejemplo, y el tipo INTEGER espera valores enteros (sin puntos).
O si prefieres puedes dar uso del tipo de dato TIMESTAMP en el campo hora, asi de manera automatica cada vez que
un usuario postee algo, se publicara de manera automatica la fecha y hora (Del servidor en cuestion) dentro del campo hora sin que tu particularmente
tengas que llevar control de esto.

3 - Recuerda que el tipo de dato TEXT y VARCHAR tienen la misma capacidad de almacenamiento de caracteres
(Siempre y cuando tengas un servidor MySQL superior a la version 5.0.3) la diferencia me parece es que
VARCHAR puedes controlar la cantidad de caracteres que recibira especificandole un tamanio de almacenamiento
(Por ejemplo VARCHAR(65,400)) Esto soportara 65,400 caracteres maximo. En cambio el tipo de dato TEXT no
puedes indicarle de forma manual el maximo de caracteres a soportar (Aunque TEXT como VARCHAR tiene un maximo
de 65,500 caracteres me parece ) No puedes especificarselo manualmente, el control del maximo del tipo TEXT
lo controla una variable dentro del archivo de configuracion de MySQL llamada 'max_allowed_packet' si esta
variable dice que el maximo son por ejemplo 20,000 bytes, aun TEXT teniendo capacidad de soporte de 65,500
el hara caso a la variable anterior, por ende no podran insertarse mas de 20,000 caracteres maximo (si hay mas
seran truncados tu sabes). Por lo tanto si vas a alojar tu proyecto en un servidor compartido o similar,
y decides seguir dando uso del tipo TEXT averigua el maximo de esta variable, para que no te lleves una sorpresa
nada agradable. (Tampoco te recomiendo usar MEDIUMTEXT por ejemplo, consume mas bytes en memoria que VARCHAR,
y VARCHAR sigue soportando un poco mas de 65,000 caracteres).

4 - Espero que estes consciente que aunque coloques un limite de almacenamiento en los tipos de datos
numericos (TINYINT, INTEGER, etc) esto no implica que el maximo de numeros que se puedan insertar son
los que indiques al declarar el almacenamiento... por ejemplo, si tu creas un campo asi:

NUMERO INTEGER(3)

Por ejemplo, esto no indica bajo ningun concepto, que el campo NUMERO solo te acceptara cifras de 3 numeros
ni tampoco va a truncar y dejar 3 numeros si tu insertas por ejemplo '12450'. Dicho campo acceptara sin mucho
inconveniente la insercion de 12450 y no lo truncara, ya que la especificacion de almacenamiento se refleja
hacia cuantos datos se van a mostrar en la aplicacion (ya sea web, o una aplicacion grafica) es ahi que se van
a mostrar 3 numeros, no que el campo como tal solo va a recibir 3 numeros y lo otro a truncar, el campo recibira
siempre la cantidad inferior de su maximo total sin problema alguno.


Seguramente, habran tablas que podran obviarse utilizar para ahorrarle al motor la busquedad y verificacion
en una tercera tabla de algun dato que podrias relacionar en 2 tablas.. pero, como yo particularmente desconozco
de que va el proyecto lol.. no puedo especificarte que se puede poner o que se puede quitar. Pero haz hecho
buen intento y es lo que vale   recuerdate dar uso del EXPLAIN en cada consulta que vayas a realizar
para que sepas cuales estan mas cercanas a una buena optimizacion (digo cercana no exacta porque EXPLAIN se
base en estadisticas no en hechos reales) pero tendras una buena aproximacion.

Si te vas a inclinar por tablas Myisam nada mas, y tienes facilidad de modificar my.cnf o my.ini
recuerda al menos darle 256MB de ram a la variable 'key_buffer' (que seria el espacio compartido
que le estarias otorgando a todos los indices de todas tus tablas Myisam en memoria) o si quieres manipularlo
de forma mejor, puedes otorgarle a cada indice de cada tabla su propio espacio independiente en memoria ram...
si te interesa saber como en MySQL solo avisame

1- TRIGGERS, los conocidos disipadores, digamos que son atributos o condiciones que se aplican a una tabla antes o despues que se realiza una transaccion en esta.

2 - No hay ningun problema en usar InnoDB con Myisam, pero recuerda que Myisam es un motor no transaccional y InnoDB si, con esto te digo que InnoDB a pesar de las ventajas que posee, tiene desventajas como que ocupa mas espacio en disco, consume mas RAM fisica, entre otras cositas que posiblemente no te preocupen sino son muchas tablas ya que asumo quieres cuidar la integridad de tus datos.

4 - Si estas consciente que el ID mas alto de un campo no va a sobrepasar de el numero 127 deberias en lugar de INTEGER usar TINYINT ya que TINYINT ocupa menos espacio de disco y controla que la data no sea mayor de la cifra 127. Ya que INTEGER(3) no va a controlar la cantidad que entre, INTEGER acceptara cualquier valor insertado hasta su maxima capacidad.

PD: Se me habia olvidado lol... no hay ningun problema con el tipo de dato TIMESTAMP y el metodo de ordenacion con ORDER BY puedes darle uso sin problema alguno 

Gracias N4X

me agrada que te guste mucho todo el tema relacionado a optimizacion. En el caso de Base de datos el resumen es tan extenso que yo misma no lo conozco 100%    pero trato de conocer lo mas que pueda.

Sobre mezclar tablas Myisam con InnoDB no es que exista un problema a gran escala, pueden convivir juntas pero, habran cosas que deberas analizar el triple si vas a dar uso de estas dos o mas, por ejemplo dividir la distribucion de la RAM fisica entre la cache buffer de InnoDB (Que lo usa para guardar indice y data) y la cache buffer de Myisam (Que lo usa unicamente para guardar los indices... la data se la deja el motor para que la guarde el sistema operativo en su cache). Entonces a la hora de dividir la ram para el motor tienes que analizar muy bien como lo haces (Si es con 1 solo motor es mas comodo porque de antemano solo deberas trabajar 1 sola vez) Entre otras cositas como el sistema de bloqueo que tiene cada motor de almacenamiento... pero no hay que extenderse demasiado.

Generalmente lo que yo suelo hacer, para no mezclar motores y no mortificarme dividiendo la ram fisica y los segmentos de area compartida del SO, tengo un Mysql maestro con todas las tablas InnoDB y un Mysql esclavo con las mismas tablas pero en Myisam, y todas las inserciones de datos se hacen al Maestro (para proteger la integridad de los datos) y la solicitud de dichos datos (SELECT) se hacen al esclavo.  Asi le sacas el mayor provecho que tiene el motor Myisam que es ser rapido con la lectura y aprovechas InnoDB para hacer las inserciones y proteger a mayor nivel tu data  y asi de igual manera configuras Myisam para sacar mayor ventaja de la ram para su buffer y a InnoDB por su otro lado su ventaja para su buffer. (Es que InnoDB por recomendacion requeriria 80% de tu ram fisica para distribuirla en sus segmentos, buffers, procesos etc, en cambio Myisam con un 50% de tu ram fisica podria ser manejable...) Aunque todo depende el exceso de trabajo que se le monte a la DB.

Pero para hacer lo anterior requeririas de 2 servidores, uno para que sirva de Mysql maestro y otro para que sirva de Mysql esclavo... dicho esclavo puede ser un PC remoto no importa.

Sobre TIMESTAMP no se en que formato lo querras convertir, hasta lo que me concierne Mysql al menos en sistemas Unixes y Linux lo maneja en modo UTC. Mira un ejemplo de una tabla y un campo fecha con tipo de dato TIMESTAMP

 
mysql> DESCRIBE ejemplo;
+-------+-----------+------+-----+-------------------+-----------------------------+
| FIELD | TYPE      | NULL | KEY | DEFAULT           | Extra                       |
+-------+-----------+------+-----+-------------------+-----------------------------+
| fecha | TIMESTAMP | NO   |     | CURRENT_TIMESTAMP | ON UPDATE CURRENT_TIMESTAMP |
+-------+-----------+------+-----+-------------------+-----------------------------+
1 ROW IN SET (0.00 sec)                                                             
 
mysql> INSERT INTO ejemplo VALUES(NULL);
Query OK, 1 ROW affected (0.00 sec)     
 
mysql> INSERT INTO ejemplo VALUES(NULL);
Query OK, 1 ROW affected (0.00 sec)     
 
mysql> INSERT INTO ejemplo VALUES(NULL);
Query OK, 1 ROW affected (0.00 sec)     
 
mysql> SELECT * FROM ejemplo;
+---------------------+      
| fecha               |      
+---------------------+      
| 2010-01-07 19:22:02 |      
| 2010-01-07 19:22:34 |      
| 2010-01-07 19:23:16 |      
+---------------------+      
3 ROWS IN SET (0.00 sec)     
 
mysql> INSERT INTO ejemplo VALUES('2010-01-07');
Query OK, 1 ROW affected (0.00 sec)             
 
mysql> SELECT * FROM ejemplo;
+---------------------+
| fecha               |
+---------------------+
| 2010-01-07 19:22:02 |
| 2010-01-07 19:22:34 |
| 2010-01-07 19:23:16 |
| 2010-01-07 00:00:00 |
+---------------------+
 
 

Si le insertas la fecha lo mas que hara es no colocarle los segundos, pero si insertan null se colocara la fecha junto a hora y segundos (acorde al reloj del sistema operativo)

Hola N4X.

De antemano te habia hecho la sugerencia que efectivamente hay tablas que se pueden reducir o compenetrar con otra. Pero no puedo especificarte de antemano cuales serian porque aunque te explicas (disculpa que aun no entienda 100% del todo tu aplicacion final).

Es relativo separar o dejar 1 sola tabla con muchos campos y separarse de la normalizacion de datos. Aveces si es mas efectivo desnormalizar una tabla para optimizar tu aplicacion ya que para el motor es mucho mejor y mas rapido acceder a la data dentro de una sola tabla que conseguir una data buscando en 2,3,4 o mas tablas, tu entenderas que para una aplicacion de gran tamano (digase miles o millones de registros) es mas forsozo para el motor tener que sacar varios registros de un JOIN de 2 o 3 o mas tablas, pero si esos miles o millones estuviesen en 1 sola tabla todos, el proceso es mas rapido. Pero aunque algunas veces es bueno apoyarse en la desnormalizacion no te fies siempre de ello.. ya que desnormalizar implica tener logs, datafiles mucho mas grandes en un solo archivo no distribuido en varios archivos como si tuvieramos normalizacion.. entre otras cosas. Tu conoces el tipo de proyecto que debes realizar si es un proyecto pequeno o mediano-pequeno, puedes darte el permiso de desnormalizar algunas tablas para optimizar, pero procura elegir tablas que tu sepas que en un futuro no va a afectar los registros que tengas dentro por alguna actualizacion que debas hacer, que esto no afecte la relacion.

Ahora, sobre considerar los valores NULL en los campos no te lo recomendaria ni en modelo normalizado ni desnormalizado. La razon? recuerda que NULL no es un tipo de dato es nada.. vacio, nisiquiera es 0 o espacio vacio es nada. Sin embargo todos los campos que tu declaras en un motor de DB tienen un tipo (integer, char, varchar, text, etc) cuando tu creas un campo y le asignas un tipo de dato, le estas diciendo al motor que cuando reciba un registro reserve memoria para ese tipo de dato recibido (sea texto, numero, decimales, fechas, etc) pero si tu ingresas un dato NULL cuando el motor reserva memoria para un INTEGER por ejemplo.. a la hora que haces una consulta a una tabla donde existe ese NULL por ejemplo, el motor cuando llegue al registro donde existe ese NULL se detendra unos segundos a analizar que realmente en ese espacio reservado hay un valor NULO cuando el esperaba encontrar un INTEGER, despues que el analiza esto entonces sigue su recorrido.

Es como por ejemplo, que yo tenga 20 botellas de plastico para guardar agua y te diga N4X sal de este departamento pero antes de que tu salgas verificame de las 20 botellas cuales tienen agua, y tu pasas caminando vas con los pies tentando y sabes que tienen agua sigues de largo, pero de repente si toqueteas una y la sientes liviana te detendras unos segundos al menos para verificar que dicha botella no tiene agua... esta vacia, asi mas o menos reacciona el motor.

Toma eso en cuenta, coloca cualquier valor ya sea 'espacio' o cero pero no consideres los nulos.

Otra cosa si tu de antemano sabes, que llegara un punto donde deberas relacionar todas las tablas a traves de 1 tabla padre, ve considerando agregar 1 indice que contenga el mismo valor y relacione todas las tablas que sospechas llegara un punto que se van a relacionar.

SI mas o menos entiendo tu punto en no querer tener tantos datos relevantes y repetidos cuando haces referencia a una misma cosa exceptuando 1 solo campo en la tabla que uses de relacion.

Tu dices que hay 1 representante por cada pais, y que hay 1 representante por cada provincia de cada pais, y que hay 1 comarca (que no se que es esto) que es el que recibe la informacion top10 por parte del representante de un pais, no sin antes este representante recibir todas las circulares de todos los representantes de cada provincia? Lol eso es lo que entiendo 

Seria algo como:

Tabla_rep_provincia  --> Tabla_rep_pais --> Tabla_Comarca --> Tabla_top10

Seria mas o menos asi la relacion??? o sea la info pasa primero al representante de la provincia, luego pasa al representante de dicho pais, luego pasa al Comarca y finalmente pasa a una tabla top10? 

Sobre tu imagen mostrada, y de antemano puedo decirte una completa ignorancia y mal consejo porque no capto en su totalidad que estas buscando lograr. A simple vista no podria ser las tablas:

web_oracion_pais_t10
web_oracion_cat_10
web_oracion_provincia_t10

Una sola tabla? lo mismo expreso y pregunto para las tablas superiores:

web_oracion_pais
web_oracion_ca
web_oracion_provincia

No podrian ser una sola tabla? digo analizalo sino te afecta las relaciones en algun punto. Hay varias maneras de relacionar entidades, de forma desglosada como la tienes actualmente (Y mas entendible para cualquier DBA futuro) o de manera conjunta (La cual yo utilizo bastante para evitarle al motor tantos recorridos y perdida de tiempo al optimizador interno  )
Pero no te digo que sea lo mas recomendable, a mi me gusta porque me gusta ahorrar trabajo al motor y porque yo de antemano se donde puede o no afectarme una relacion de entidades si mezclo tablas, pero en tu caso me queda un poco lejano porque aun no tengo la idea clara del escenario que compone los datos de tus tablas.

Pero dime si no es posible juntar esas tablas mencionadas anteriormente y porque.