Foro de elhacker.net

Bueno primero tengo mucho sueño, asi que si me dejo algo me lo hacen saber y mañana lo publcio  :silbar:

Estoy diseñando la base de datos para un sitio que queremos hacer con unos amigos.

Esto es lo que tengo diseñado:
url:http://img266.imageshack.us/img266/8137/esquemamysql.jpg
esta todo compactado para que entre en la imagen  :-X

1. Las tablas son myisam y llevan foreing keys (FK) algún problema en ello??

Bueno e separado las diferentes partes por colores, las que no tienen color son funciones generales.

Los mediumint(8) son valores de un id de usuario smf.. no e puesto la tabla porque es un lio  :rolleyes:

Todas las relaciones son 1:N con FK.

Empiezo a explicar:

Amarillo superior:
es un sistema de noticias con comentarios, una tabla de noticias y otra de comentarios.
la tabla secciones es porque habrá varias páginas que usen el sistema de noticias, entonces con esa tabla me ahorro hacer varias tablas iguales.
(el web_ es solo un prefijo para distinguir de smf)

Azul:

es una area de consultas, sigue un sistema casi igual que el de las noticias.
la tabla de secciones se refiere al area de consulta que se hará.
ejemplo: sección: informatica; sección:medio ambiente, etc

Verde pequeño:
Es una bd que solo linka con el responsable de la ong.
Contiene una descripcion y esas cosas xD

verde grande:
es un sistema de peticiones de oración [ok si no creen me da igual, de que trata la web no es el caso  :silbar: :silbar:] y mas abajo otro sistema de noticias.
El sistema de noticias solo varia en los otros que se guardan noticias para todo tipo de users-visitantes y noticias de ambito privado (un grupo concreto de users).

El sistema de oración es lo mas complicado de toda la web creo yo, lo explico mas o menos:

Contamos con un responsable de país (un admin), responsable de Comunida autonoma, provincia, comarca y ciudad.
Bien, a los usuarios se les presentan los datos según los datos que dieron de donde son y cuando envian una petición esta se envia al responsable directo (lease el de ciudad), si el de ciudad cree que es una peticion de caracter comarcal la envia a su superior (el responsable de comarca).
Para eso habia pensado usar el campo de "relevancia" cuanto mas alto mas arriba busca en la bd, pero aun no lo tengo del todo claro....
el resto son categorias de oracion y los votos.

Bueno también se pensó el crear un Top10 de las peticiones para cada zona.

Explico como va esa parte:

El responsable de una ciudad recive X peticiones de las cuales toma 10 como importantes, esas 10 se guardan en un top10 de su ciudad.
Esas mismas 10 se envian al responsable de comarca (las de todas las ciudades de la comarca), el responsable recive todas ellas y selecciona 10 que agrega al top 10 de la comarca, esas 10 se envian a la provincia y así hasta llegar al final.

Esa parte no se como diseñarla, así que si hay ideas son bien recibidas  :xD

Rosa:

Es como una red social, los usuarios se agregan a las categorias que les gustan en la pagina principal se listan las ultimas noticias de todas las redes y en cada red las noticias de esa red.

Amarillo abajo:

es una zona de indignados, ejemplo: estoy indignado "porque el pan es caro"  ;-)

entonces hay ciertas tematicas (indignaciones politicas, de familia, dinero... etc)
y la gente puede comentarlas y votar por ellas.

---

y eso es todo!
el modlog es un log de las acciones de los mod's
y la papelera no es mas que eso  :o

el id_mod también linka con la tabla de usuarios smf, pero en estos casos le id_mod suele ser quien acepta los comentarios que requieren moderacion

Este es mi segundo diseño de una bd tan grande así que no me maten!!! el primero fue al finalizar el FP I... y espero ancioso el FP II el año que viene para poder darle mas caña al mysql...
si hay grandes catastrofes en el diseño me pegan un poco y lo corrijo  :o

Desde ya mis mas sinceras gracias por el simple hecho de leer esto.
Y si amportan alguna idea será bien recibida y valorada.

Cualquier dato extra que necesiten haganmelo saber!

saludos
nax

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 ;)

gracias por tu respuesta  ;D

en parte habia leido respuestas tuyas por el area y me parecieron muy bien explicadas.

Ahora... en mySQL soy un verdadero desastre  :o pero me informaré de lo que dices!!!

1. TRIGGERS no se que son xD pero ahora lo busco.

El tema principal es que estoy integrando la web a SMF y por tanto.. ellos usan myisam pero yo siempre e trabajado con innoDB. Entonces las FK las uso muchisimo... si logro entender los triggers usaré eso xD
Pero abria algun problema en mesclar tablas innodb con myisam?

2. Eso lo pensé, pero como SMF usaba un integer y luego la convertia.. no se... quise dejarlo así.. que tal se lleva el campo timestamp con las comparaciones? para, por ejemplo, ordenar los comentarios de una noticia por la hora y no por el id.

3. lo tendré en cuenta, muchas gracias

4. bien, no era conciente... pero donde hay un integer(3) me parece que son las categorias que como un id muy alto espero se inserte un 99 y no mucho mas...
de todas formas lo tendré en cuenta en cuanto haga la revisión.


muchas gracias por el soporte.

felices reyes  ;D

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  ;)

muchas gracias ^Tifa^, a partir de estos consejos trabajaré en los cambios al llegar a casa y si no hay problema dejo un nuevo modelo y me lo comentas  :xD

no me agrada la idea de mezclar myisam con innodb, se que este ultimo ofrece mayor integridad y por tanto es mas lento y ocupa mas...

simpre e trabajado con innodb pero mezclar las tablas SMF myisam con las de mi proyecto innodb.. no me convence... así y todo estarian linkadas solo mediante los usuarios y en teoria no deberia haber mayores problemas... veré como lo hago

lo de los integers ok, los cambiaré por tinyint en aquellos valores que creo serán escasos. de todas formas estudiaré algunos que, posiblemente, podrian superar los 127.

el tema de timestamp, bueno aun tengo la duda de en que formato se guarda y como puedo ponerlo en formato españa. Pero bueno, a base de tocar y provar, cuando llegue a casa lo confirmaré.
Si funciona como lo esperado ahorrará bastante trabajo en el php en cuanto a conversiones y demás.

muchas gracias por el tiempo otorgado.

un saludo
n4x

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%  ;D  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  :D 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)

lo de los 2 servidores dejemoslo por imposible, de momento,  :rolleyes:

gracias por la muestra del timestamp, trabaja como me imaginé asi que creo que lo usaré para un funcionamiento mas optimo y menos engorroso.

---

anoche seguia dandole vueltas a la región_03 en la imagen (verde inferior).
es la mas importante así que voy a explicarla un poco mejor para que se entienda lo que quiero hacer y a ver si se les ocurren mejoras.

pero antes:
la tabla web_oracion_news y web_news se diferencian de 1 solo campo: public (tinyint)
e estado pensando en fusionar ambas tablas y con ello me quito 2 tablas de encima
y el campo public situarlo como boolean y en posibilidad de nulo. ya que solo seria usado en la categoria 'oracion'.
(las news de las redes las dejo tal cual, prefiero que sean tablas separadas, por un tema de frecuencia de uso).


Entonces paso a explicar dicha región, el tema noticias lo salto, sino en el tema pedidos oración y demás.

podriamos imaginar que es una empresa. y en la empresa se envian diferentes circulares.
La empresa tiene un representante en cada pueblo de españa. Un representante en cada comarca, uno en cada provincia, etc.

si un miembro del pueblo 'reus' quiere enviar una circular, el responsable de ese pueblo la revisa y la envia.

El responsable puede hacer 2 cosas:
1- Enviar la circular a reus.
2- Considerar que la circular puede ser de interes a la comarca, y por tal caso enviarla al responsable comarcal

el responsable comarcal la recibe y puede hacer las 2 acciones anteriores, enviarla a toda la comarca, o enviarla a su superior directo.

para esta parte del planteamiento yo pense, en un principio, el campo relevancia de la tabla web_oracion. cuando la petición se envia a la ciudad tiene relevancia 1, si el responsable la envia a la comarca adquiere relevancia 2, etc...

sigo:
una vez se hace el tramite de las circulares, cada responsable de ciudad, elige las 10 mas divertidas  ;-)
y esas 10 se publican en un top 10.
A la vez que las elige y publica, esas 10 se envian al responsable de comarca (junto con todo el resto de top10 de ciudades que pertenecen a esa comarca).

El responsable comarcal recive todos los top10 de cada ciudad, y elige las 10 que mas gracia le causaron... y las publica y las envia a su superior. etc

para esta parte (que aun no tengo tablas) pensé en crear una tabla top10 para ciudad, otra para comarca, etc.
relacionando el top 10 con el id de ciudad, para la tabla top10_ciudad.

la tabla top10_ciudad contendria algo así:

table: top10_ciudad
rows: id_top id_ciudad id_peticion posicion
          int       int            int               int (de 1 a 10)

y eso es todo creo...
mi preocupación mas grande viene con el tema relevancia.. pues el método no me convence mucho...
podria agregar a web_oracion una columna para cada id...
ejemplo id_ciudad id_comarca etc...

con posibilidad de null, si la id_ciudad es 1 pero la id_comarca es null quiere decir que tiene relevancia de ciudad, si la id_comarca es 3 es de relevancia comarcal..

pero no se si tendria que relacionar todas las tablas de ciudades, comarcas, etc a la tabla principal (web_oracion) o de la manera que está ahora podria hacerlo sin problemas...

el tema es que si es este ultimo caso, creo que la metodologia es igual que la de 'relevancia'  :rolleyes: :-X

alguna idea :huh:  :)

gracias por toda la ayuda  ;)

pd. vaya post mas pesado me a quedado! mis disculpas!  :laugh: :xD

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.

entiendo que no se entienda (valga la redundancia  :rolleyes:)

si bien en el equipo nos vemos una ves a la semana en algun lugar y nos podemos pasar 6 horas hablando del tema y no siempre llegamos a algo xD

así que es normal que no puedas dar tu total opinión del proyecto.. pero si te queda duda de algo.. asmelo saber.

el campo null lo descarto entonces y usaré un valor cualquiera para hacer referencia a un nulo (como el 0 que en php evalua null :D)

así es como lo tengo con los top10.
(http://img15.imageshack.us/img15/2834/dibujovai.jpg)
http://img15.imageshack.us/img15/2834/dibujovai.jpg

si tuviera que poner un campo para ciudad, comunidad, etc... eso ya seria un desmadre de relaciones!!! (solo lo puse a modo de ejemplo en ciudad)

me e equivocado en algo?  :rolleyes: :rolleyes: :rolleyes: :o

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  :xD

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  :xD)
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.

a lo que te refieres es a tener una sola tabla tipo:

tabla_oracion_sitios

id_pais id_ca id_provincia id_comarca id_ciudad nombre

y si quiero poner españa:

id_pais id_ca id_provincia id_comarca id_ciudad nombre
    1        0         0                  0                   0        españa

agrego una comunidad autonoma
id_pais id_ca id_provincia id_comarca id_ciudad nombre
    1        1        0                   0              0           cataluña

así? hmmm si es el caso... podria ser una buena idea... y trabajar del mismo modo los top... hmmmmm pensaré en ello..

un ejemplo de top10 podria ser:

tabla_oracion_top10

id_pais id_ca id_provincia id_comarca id_ciudad id_peticion posicion
   1         1           0                 0             0              5             1
con lo cual marcariamos la petición (o circular) 5 en la primera posición de cataluña (siguiendo los 2 ejemplos anteriores)

hmm me gusta bastante... lo pensaré bien a lo largo del día, pero quiza sea la mejor solución

---

la comarca no es otra cosa que dividir en porciones mas pequeñas un territorio (http://es.wikipedia.org/wiki/Comarca)

si ponemos un ejemplo seria:

pais: españa
comunidad autonoma: cataluña
provincia: tarragona
comarca: baix camp
ciudad: reus
(http://es.wikipedia.org/wiki/Reus)

lo que yo digo es que hay un representante para cada ciudad, uno para cada comarca, uno para cada provincia, etc...

el de ciudad envia su top10 al de su comarca el cual recive todos los top10 de las ciudades que componen la comarca y así sucesivamente hasta llegar al pais.

---

AGREGO:

impresionante como cambia la cosa... (me e pasado a las herramientas de mysql por mayor comodidad xD)

ahora si está mas bonita esta parte, a mi parecer ni punto de comparación  ;-)
(http://img11.imageshack.us/img11/1998/dibujoiyo.jpg)
link: http://img11.imageshack.us/img11/1998/dibujoiyo.jpg

muchas gracias por todo...

iré haciendo las demás y si tengo problemas agrego :)


un problemita es a la hora de importar el código SQL del Workbench a MySQL

le doy a sincronizar y me dice que hay un error, pero no donde ni cual es...

Executing SQL script IN server
 
ERROR: Error 1005: Can't create table 'smf_test.web_oracion' (errno: 150)
 
 
 
 
 
CREATE  TABLE IF NOT EXISTS `smf_test`.`web_oracion` (
 
  `id_peticion` INT(10) UNSIGNED NOT NULL ,
 
  `peticion` VARCHAR(250) NOT NULL ,
 
  `usr_rel` MEDIUMINT(2) UNSIGNED NOT NULL DEFAULT 1 ,
 
  `votos` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
 
  `hora` TIMESTAMP NOT NULL ,
 
  `autor` MEDIUMINT(8) UNSIGNED NOT NULL ,
 
  `id_pais` INT(10) UNSIGNED NOT NULL ,
 
  `id_ca` INT(10) UNSIGNED NOT NULL ,
 
  `id_provincia` INT(10) UNSIGNED NOT NULL ,
 
  `id_comarca` INT(10) UNSIGNED NOT NULL ,
 
  `id_ciudad` INT(10) UNSIGNED NOT NULL ,
 
  `id_cat` INT(10) UNSIGNED NOT NULL ,
 
  PRIMARY KEY (`id_peticion`) ,
 
  INDEX `relacion2` (`id_comarca` ASC, `id_ciudad` ASC, `id_provincia` ASC, `id_ca` ASC, `id_pais` ASC) ,
 
  INDEX `categoria` (`id_cat` ASC) ,
 
  CONSTRAINT `relacion2`
 
    FOREIGN KEY (`id_comarca` , `id_ciudad` , `id_provincia` , `id_ca` , `id_pais` )
 
    REFERENCES `smf_test`.`web_oracion_lugares` (`id_comarca` , `id_ciudad` , `id_provincia` , `id_ca` , `id_pais` )
 
    ON DELETE NO ACTION
 
    ON UPDATE CASCADE,
 
  CONSTRAINT `categoria`
 
    FOREIGN KEY (`id_cat` )
 
    REFERENCES `smf_test`.`web_oracion_cat` (`id_cat` )
 
    ON DELETE CASCADE
 
    ON UPDATE CASCADE)
 
ENGINE = InnoDB
 
DEFAULT CHARACTER SET = utf8
 
COLLATE = utf8_general_ci
 
 
 
SQL script execution finished: statements: 10 succeeded, 1 failed
 

el sql de phpmy admin dice:

#1005 - Can't create table 'smf_test.web_oracion' (errno: 150)


saludos
nax

Vaya que cambio de modelo de tablas  ;-)  me gusta como se ve. Y me alegra que te movieses para WorkBench de MySQL  ;D

Cuando he visto el error 1005 (errno) no habia leido el script SQL y ya sabia de antemano que eran tablas InnoDB y habia una o mas Foreign Keys dentro  :xD es que es tan comun este error con las referencias foreign key en InnoDB...(Aun no se porque) pero ocurre por variadas razones algunas hasta sin sentido.

ya pegaste la estructura logica de la tabla web_oracion que viene siendo el hijo, necesito la estructura logica de las tablas padres web_oracion_lugares y web_oracion_cat ya que las razones del fallo anterior son bastantes variadas (No hay 1 sola definicion para que se de el fallo 1005) aveces ocurre porque una tabla hijo no puede hacer un FK a otro FK de otra tabla hijo, aveces me ha pasado porque 1 campo FK INTEGER debia declararlo como UNSIGNED, entre otras situaciones....

Pero necesito la estructura logica de las otras 2 tablas, no solo de la que pegaste aca, para depurar y ver como se podria resolver.

Un Saludo.

ok ahora te lo doy...

me e dado cuenta que el error no es solo uno..

por haí decian que habia que cambiar los nombres de las FK porque ya existian.. (nothing)

que las FK sean exactamente igual a la original (creo que ya lo son... pero nada)

este es el sql que genera al sincronizar con la bd.
el mydb no e encontrado aun donde borrarlo y que no vuelva  :laugh:

SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL';
 
CREATE SCHEMA IF NOT EXISTS `mydb` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci ;
 
USE `mydb`;
 
CREATE  TABLE IF NOT EXISTS `smf_test`.`web_oracion_cat` (
  `id_cat` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT ,
  `categoria` VARCHAR(100) NOT NULL DEFAULT 0 ,
  PRIMARY KEY (`id_cat`) )
ENGINE = InnoDB
AUTO_INCREMENT = 3
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;
 
CREATE  TABLE IF NOT EXISTS `smf_test`.`web_oracion_lugares` (
  `id_pais` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_ca` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_provincia` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_comarca` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_ciudad` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `nombre` VARCHAR(100) NOT NULL DEFAULT 0 ,
  `responsable` MEDIUMINT(8) UNSIGNED NOT NULL DEFAULT 0 ,
  PRIMARY KEY (`id_pais`, `id_ca`, `id_provincia`, `id_comarca`, `id_ciudad`) )
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;
 
CREATE  TABLE IF NOT EXISTS `smf_test`.`web_oracion_top10` (
  `id_top` INT(10) UNSIGNED NOT NULL ,
  `id_pais1` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_ca1` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_provincia1` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_comarca1` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_ciudad1` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_peticion1` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `posicion` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  PRIMARY KEY (`id_top`) ,
  INDEX `relacion1` (`id_pais1` ASC, `id_ca1` ASC, `id_provincia1` ASC, `id_comarca1` ASC, `id_ciudad1` ASC) ,
  INDEX `peticion` (`id_peticion1` ASC) ,
  CONSTRAINT `relacion1`
    FOREIGN KEY (`id_pais1` , `id_ca1` , `id_provincia1` , `id_comarca1` , `id_ciudad1` )
    REFERENCES `smf_test`.`web_oracion_lugares` (`id_pais` , `id_ca` , `id_provincia` , `id_comarca` , `id_ciudad` )
    ON DELETE NO ACTION
    ON UPDATE CASCADE,
  CONSTRAINT `peticion`
    FOREIGN KEY (`id_peticion1` )
    REFERENCES `smf_test`.`web_oracion` (`id_peticion` )
    ON DELETE CASCADE
    ON UPDATE CASCADE)
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;
 
CREATE  TABLE IF NOT EXISTS `smf_test`.`web_oracion` (
  `id_peticion` INT(10) UNSIGNED NOT NULL ,
  `peticion` VARCHAR(250) NOT NULL DEFAULT 0 ,
  `usr_rel` MEDIUMINT(2) UNSIGNED NOT NULL DEFAULT 1 ,
  `votos` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `hora` TIMESTAMP NOT NULL ,
  `autor` MEDIUMINT(8) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_pais2` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_ca2` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_provincia2` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_comarca2` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_ciudad2` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_cat2` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  PRIMARY KEY (`id_peticion`) ,
  INDEX `relacion2` (`id_comarca2` ASC, `id_ciudad2` ASC, `id_provincia2` ASC, `id_ca2` ASC, `id_pais2` ASC) ,
  INDEX `categoria` (`id_cat2` ASC) ,
  CONSTRAINT `relacion2`
    FOREIGN KEY (`id_comarca2` , `id_ciudad2` , `id_provincia2` , `id_ca2` , `id_pais2` )
    REFERENCES `smf_test`.`web_oracion_lugares` (`id_comarca` , `id_ciudad` , `id_provincia` , `id_ca` , `id_pais` )
    ON DELETE NO ACTION
    ON UPDATE CASCADE,
  CONSTRAINT `categoria`
    FOREIGN KEY (`id_cat2` )
    REFERENCES `smf_test`.`web_oracion_cat` (`id_cat` )
    ON DELETE CASCADE
    ON UPDATE CASCADE)
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;
 
 
SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;
 

al principio pensaba que era la tabla top10, pues esa se generaba bien y la principal (web_oracion), pero e borrado toda la bd y en sincronizado sin el top10 y da el mismo error.

muchas gracias por el soporte :)
a estas alturas andaria desesperado XD

Me gustaria decirte cual era el problema..... pero creo que si vez el Codigo modificado te daras cuenta...


Codigo:

 
SET @OLD_UNIQUE_CHECKS=@@UNIQUE_CHECKS, UNIQUE_CHECKS=0;
SET @OLD_FOREIGN_KEY_CHECKS=@@FOREIGN_KEY_CHECKS, FOREIGN_KEY_CHECKS=0;
SET @OLD_SQL_MODE=@@SQL_MODE, SQL_MODE='TRADITIONAL';
 
CREATE SCHEMA IF NOT EXISTS `mydb` DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci ;
 
USE `mydb`;
 
CREATE  TABLE IF NOT EXISTS `smf_test`.`web_oracion_cat` (
  `id_cat` INT(10) UNSIGNED NOT NULL AUTO_INCREMENT ,
  `categoria` VARCHAR(100) NOT NULL DEFAULT 0 ,
  PRIMARY KEY (`id_cat`) )
ENGINE = InnoDB
AUTO_INCREMENT = 3
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;
 
CREATE  TABLE IF NOT EXISTS `smf_test`.`web_oracion_lugares` (
  `id_pais` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_ca` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_provincia` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_comarca` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_ciudad` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `nombre` VARCHAR(100) NOT NULL DEFAULT 0 ,
  `responsable` MEDIUMINT(8) UNSIGNED NOT NULL DEFAULT 0 ,
  PRIMARY KEY (`id_pais`, `id_ca`, `id_provincia`, `id_comarca`, `id_ciudad`) )
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;
 
CREATE  TABLE IF NOT EXISTS `smf_test`.`web_oracion` (
  `id_peticion` INT(10) UNSIGNED NOT NULL ,
  `peticion` VARCHAR(250) NOT NULL DEFAULT 0 ,
  `usr_rel` MEDIUMINT(2) UNSIGNED NOT NULL DEFAULT 1 ,
  `votos` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `hora` TIMESTAMP NOT NULL ,
  `autor` MEDIUMINT(8) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_pais2` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_ca2` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_provincia2` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_comarca2` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_ciudad2` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_cat2` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  PRIMARY KEY (`id_peticion`) ,
  INDEX `relacion2` (`id_pais2` ASC, `id_ca2` ASC, `id_provincia2` ASC, `id_comarca2` ASC, `id_ciudad2` ASC) ,
  INDEX `categoria` (`id_cat2` ASC) ,
  /*CONSTRAINT `relacion2`*/
    FOREIGN KEY (`id_pais2`, `id_ca2` , `id_provincia2` , `id_comarca2`,  `id_ciudad2` )
    REFERENCES `smf_test`.`web_oracion_lugares` (`id_pais`, `id_ca` , `id_provincia` , `id_comarca` , `id_ciudad` )
    ON DELETE NO ACTION
    ON UPDATE CASCADE,
  CONSTRAINT `categoria`
    FOREIGN KEY (`id_cat2` )
    REFERENCES `smf_test`.`web_oracion_cat` (`id_cat` )
    ON DELETE CASCADE
    ON UPDATE CASCADE)
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;
 
 
CREATE  TABLE IF NOT EXISTS `smf_test`.`web_oracion_top10` (
  `id_top` INT(10) UNSIGNED NOT NULL ,
  `id_pais1` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_ca1` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_provincia1` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_comarca1` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_ciudad1` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `id_peticion1` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  `posicion` INT(10) UNSIGNED NOT NULL DEFAULT 0 ,
  PRIMARY KEY (`id_top`) ,
  INDEX `relacion1` (`id_pais1` ASC, `id_ca1` ASC, `id_provincia1` ASC, `id_comarca1` ASC, `id_ciudad1` ASC) ,
  INDEX `peticion` (`id_peticion1` ASC) ,
  CONSTRAINT `relacion1`
    FOREIGN KEY (`id_pais1` , `id_ca1` , `id_provincia1` , `id_comarca1` , `id_ciudad1` )
    REFERENCES `smf_test`.`web_oracion_lugares` (`id_pais` , `id_ca` , `id_provincia` , `id_comarca` , `id_ciudad` )
    ON DELETE NO ACTION
    ON UPDATE CASCADE,
 CONSTRAINT `peticion`
    FOREIGN KEY (`id_peticion1` )
    REFERENCES `smf_test`.`web_oracion` (`id_peticion` )
    ON DELETE CASCADE
    ON UPDATE CASCADE)
ENGINE = InnoDB
DEFAULT CHARACTER SET = utf8
COLLATE = utf8_general_ci;
 
SET SQL_MODE=@OLD_SQL_MODE;
SET FOREIGN_KEY_CHECKS=@OLD_FOREIGN_KEY_CHECKS;
SET UNIQUE_CHECKS=@OLD_UNIQUE_CHECKS;
 
 

Te dare una orejita  :P

Fijate en:

Tabla web_oracion_lugares

 PRIMARY KEY (`id_pais`, `id_ca`, `id_provincia`, `id_comarca`, `id_ciudad`) )


Tabla web_oracion

INDEX `relacion2` (`id_pais2` ASC, `id_ca2` ASC, `id_provincia2` ASC, `id_comarca2` ASC, `id_ciudad2` ASC) ,
  INDEX `categoria` (`id_cat2` ASC) ,
  /*CONSTRAINT `relacion2`*/
    FOREIGN KEY (`id_pais2`, `id_ca2` , `id_provincia2` , `id_comarca2`,  `id_ciudad2` )
    REFERENCES `smf_test`.`web_oracion_lugares` (`id_pais`, `id_ca` , `id_provincia` , `id_comarca` , `id_ciudad` )


Observate el orden de campos PRIMARY KEY de web_oracion_lugares y el orden modificado actual de los INDICES y FK de web_oracion

Un error tonto lo se....... pero ya vez como trabaja InnoDB en MySQL aveces.

Prueba el code ahora  ;)

ja... si que es para darse un par de palmaditas.........  :-X

muchas gracias xD no sabia yo que hacia esa distincción de orden...

enfin... pues bueno... ya como no podia ser distinto... dejo otro "problema" (al final me vas a cobrar xD)

ejecuto el sql.. todo correcto

me voy al phpmyadmin y en la parte de diseñador, no se ve las relaciones hacia web_oracion_lugares... bueno como normalmente la parte Diseñador siempre me ha funcionado como ha querido... me voy a las tablas y busco las FK... estan alli (en ambas tablas)

entonces... creo unos cuantos datos... me relaciona todo bien, es decir cuando voy a guardar datos en web_oracion, en id_cat2 (que va relacionado con las categorias) me muestra una lista de todas ellas... sin problemas

pero en la parte de id_pais2, etc... no me muestra ninguna lista y al guardar los datos no me muestra un "link" como suele hacer....

hay alguna forma de comprobar que realmente están funcionando correctamente?

saludos!
nax

Tranquilo, yo tampoco lo sabia lol  :xD  me di cuenta depurando el Codigo en MySQL. Pero yo tampoco sabia que InnoDB exhigia este orden de PK con FK.


Si ya de antemano se actualizan las tablas padre-hijo es porque esta funcionando. Si las relaciones existen realmente (Y podras darte cuenta con SHOW CREATE TABLE tabla) y vez algun punto donde diga REFERENCES es porque efectivamente la relacion existe. Ahora, todo se va a regir acorde a las condiciones que tu diste en este caso:

    ON DELETE NO ACTION
    ON UPDATE CASCADE

Por lo que estaras consciente que si eliminas aca en el padre no se aplicara en el hijo, pero si actualizas en el padre por ley debe actualizarse en el hijo, sino pasa asi es porque las tablas no estan en motor InnoDB o porque el nivel de aislamiento no es el que trae por defecto MySQL (Este ultimo lo dudo que lo hayas modificado)

Actualiza un dato padre y verifica si se aplica al hijo  ;)

que gran verdad!! que espeso estoy hoy  :P

ok todo correcto hasta día de hoy, cualquier cosa edito  :silbar: