No creo que a ninguna niña les llame la atencion bajo ningun concepto los juegos de mecanica  no es por sexismo ni similares, pero en una epoca de mi vida fui niña, y a lo mas 'mecanico' como juguete que podia soportar eran los legos     

Pero juegos muy muy mecanicos suelen ser poco llamativos o desinteresados para la mayoria sino todas las niñas, y no es tanto por implementacion de la sociedad como tal, sino por gusto preferencial de generos de forma natural.

El que no lo crea, que tome una niña y la lleve a una jugueteria y le de libre arbedrio para que ella sola eliga el juguete o los juguetes que de alli les llaman la atencion y veran el resultado 

Salu2.

Entonces, efectivamente era lo que yo tenia pensado que era  Krav Maga no es un arte marcial, es defensa personal  y si son 2 ambitos distintos 

Yo le recomende Aikido, por la mera razon de que el confirma que viene de 2 artes marciales donde todo es combate entonces mi recomendacion iba mas para equilibrarlo (o completarlo) como artista marcial. Hay cosas que te hacen aprenderte en artes marciales de combates de las cuales Aikido carece, y hay cosas que te muestran en Aikido de las cuales las artes marciales de combates carecen... pero si tu logras combinar ambas, y a un nivel avanzado pasarias a ser una persona meramente intocable.

Hitori mi nino, ya vio algunas cositas que posee Aikido que de el manejarlas en Muay Thai o conocerlas, saldria mas beneficiado contra otros oponentes del mismo Muay  y yo se que habra cosas que posee el Muay que beneficiaria mis conocimientos en Aikido, pero puestos que mi objetivo en la vida nunca ha sido ser yo intocable  sino tener algo con que defenderme ante cualquier situacion de emergencia, por eso elegi Aikido. Yo inicialmente queria Jujitsu de hecho fue a inscribirme en Jujitsu, pero lamentablemente el Dojo solo ofrecia jujitsu brasileno y no vi eficaz las luchas en el suelo, sobretodo porque yo se que en vida real las peleas de calle nunca son unanimes (de 2 personas) sino que son 3, 4, 5 o mas contra una sola persona (o sea tu), y si te vas al suelo con uno el resto te patea, te cae a palos, botellazos... en fin. Elegi Aikido, por su gran variedad en el arte, por incluir tecnicas de defensa unanime (de 2 personas), en grupo (randori), de armas (con palos, cuchillos y espadas) y lo mas importante, las caidas que te hacen aprender las cuales caigas de espaldas, de frente o de lado te proporciona la facilidad de evitarte quedarte en 1 solo punto (como haria otra persona comun) y evitar que te caigan a patadas en el suelo, tu te movilizas durante una caida y terminas en posicion de contraataque.. eso es muy efectivo 

Por cierto D71, despues que me integre al Aikido... no se que tan efectivas sean las patadas  a lo mejor con alguien que no conozca artes marciales (una persona comun de la calle) lo sean, pero para un Aikidoka de nivel intermedio-avanzado la cosa ya no seria tan beneficiosa no.... mira porque lo digo:

Pues Krav Maga es defensa personal directamente, no un arte marcial como tal, no tiene un objetivo ni una filosofia ni mucho menos, o no es asi D71? confirmame esto ultimo. En el anterior Dojo donde estaba mi escuela de Aikido (hace 2 años atras porque lueguito se mudaron a un Dojo independiente y individual) pero anteriormente, era un Dojo compartido con distintas artes marciales y Aikido era la ultima clase de la noche, yo llegaba temprano y veia los practicantes de Jujitsu brasileno, krav maga, boxing, karate shodokan (o algo asi) y boxing, me sentaba a mirar como practicaban estas clases y lo mas que pude captar del Krav Maga fue lo que te confirmo, no era un arte marcial sino pura defensa personal, aca habian muchas mujeres en estas clases mas que hombres. En cambio Aikido es un arte marcial (para algunos un buddho) por la filosofia que tiene no es unicamente aprendete esta, esta y esta tecnica, sino que va mas alla de la parte fisica a la parte emocional de ahi que algunos lo califiquen de Buddho mas que arte marcial como tal.

Yo le sugeri Aikido a -ramc- porque esta orientado a defensa (no como en krav maga) porque aca existe una filosofia, reglas, fundamentos que hay que conseguir con la practica para convertirte finalmente en un buen aikidoka, pero como el viene de artes marciales de combate donde su objetivo es exteriorizar toda esa energia negativa que la gente saca en un combate para derrotar a un oponente, y en Aikido es todo lo opuesto, aca tu aprendes a controlar y dominar esa energia negativa recibida para traducirla a energia positiva (un poco filosofico lo se). Y pues si el siente que tiene buen nivel en combate, ataques.. para equilibrar sus conocimientos no le caia nada mal algo opuesto que fuera defensa como lo es el Aikido, solo que esta arte es dificil de aprender y requiere mucha paciencia del que la practica.

Seria algo asi:


Ve olvidandote de TYPE ese comando se utilizaba en MySQL 4.x y hubieron versiones (la 5.1 y la 5.0) que en scripts de PHP rebotaban y no creaban las tablas porque TYPE es obsoleto y estas versiones no lo reconocian.

Ahora si tienes una MySQL viejita intentalo con TYPE pero actualmente se usa ENGINE en su lugar.

En caso de que te decidas por hacer lo siguiente mejor:


Esa tabla por defecto se almacenara en el motor de almacenamiento configurado por defecto en el fichero de configuracion de MySQL de tu localhost (en caso que hagas la tabla aca en localhost), por defecto suele ser Myisam (al menos que hayas modificado esto tu). Pero si en un muyyy remoto caso o condicion en el MySQL de host (el remoto) solo se soportara InnoDB (solo es un ejemplo) ya sabes lo que tienes que hacer... pasarle un ALTER alla de forma remota y cambiarle el ENGINE.

Como te decia chico no trabajo con Workbench  (nisiquiera lo conozco la verdad  ) ni ningun IDE de esos para BD.

Pero, hay que ver si Workbench exhige o aplica algun estricto que exhiga que se cumplan los CONSTRAINTS, sabemos que PK no acepta Nulos ni valores repetidos, sin embargo INDEX si acepta valores repetidos y nulos, y acabo de verificar en MySQL, el indice INDEX aunque le coloques el atributo NOT NULL continua siendo un indice MUL (con MUL quiere decir que acepta valores repetidos, que aunque no acepte mas NULLS si acepta valores repetidos, entonces sabemos que PK no acepta valores repetidos sino unicos. Si el indice en cuestion fuese UNIQUE de forma natural es un indice de tipo MUL tambien (No porque acepte valores repetidos como tal, pero si acepta valores NULLS repetidos  ) ahora si le colocamos el atributo NOT NULL, ese indice UNIQUE pasase de MUL a PRI (PK) porque ya ni acepta valores repetidos, ni acepta nulos.

Hay que ver si Workbench esta respetando todo lo anterior expuesto y estas condiciones forman parte de su funcionalidad.

Ya entiendo lo que tu dices, (se suele usar mucho lo que propones, en formularios webs donde 1 usuario puede tener varias preferencias de varias cosas  a la vez 'viajes, tecnologia, lectura, etc..') efectivamente se crean 2 INDEX en una tabla,  pero recuerda que id_estado aunque puedas incluirle varias opciones, debe el valor de id_estado siempre pertenecer al registro al cual haces referencia en la tabla1)

Por ejemplo si tabla1 tuviese:

ID      Nombre      Apellidos
1        Juan            Sanchez
2        Maria          Perez

Y la tabla2 tuviese:

ID   CODIGO   
1       1               
1       2               
2       1               

Y una tabla3 que detalle el campo CODIGO a que gusto personal se refiere:

CODIGO       DETALLE
1                    Futbol
2                    Viajes
3                    Tecnologia
4                    Moda

Asi, con el ejemplo anterior el usuario 'Maria' que le corresponde el ID = 2 en la tabla2 dice que 'Maria' solamente tiene una preferencia y es el 'Futbol', pero 'Juan' con ID = 1 en la tabla1 dice la tabla2 que a 'Juan' le gusta el Futbol y los Viajes.

Aunque claro puedes obviar la tabla auxiliar (la 3ra tabla) pero por normalizacion, por estetica y por organizacion hay personas que lo estructuran como esta con 3 tablas. En caso que decidieras obviar la tercera tabla, tienes que colocar DETALLE dentro de la segunda tabla y con su respectivo CODIGO en cada categoria.

No puedo decirte como implementar un diagrama entidad-relacion con  2 tablas (que aunque es posible con 2 tablas realizar lo que te explique anteriormente dentro del motor de BD, para un diagrama se complicaria para exponerlo al menos) ahora con las 3 tablas, fuera mas entendible de exponer el diagrama entidad-relacion.

Seria algo mas o menos...

tabla1                                       tabla2                                      tabla3
data1          ----------------->          data1          ------------------->        data1

Obvio sustituyendo data1 por los respectivos campos de cada tabla, pero yo creo que para mayor entendimiento visual, el diagrama deberia hacerse con las 3 tablas la auxiliar y las otras 2 porque si aplicas todo (categoria y indice) en 2 tablas (aunque es posible para la BD) como te decia, visualmente se vera engorroso y confuso en el diagrama al menos.... aunque es solo mi percepcion.

Otra cosa no se como Workbench maneje esto de las relaciones, y me puedo equivocar (No utilizo IDE para trabajar con BD) pero ten pendiente que quieres relacionar un PK con un doble INDEX, los PK no aceptan valores nulos ni repetidos (ademas que es 1 solo campo en el caso que lo haz definido), y el INDEX acepta repetidos, acepta nulos en este caso (no agregaste not null) y son 2 campos no 1 solo, asumo Workbench querra 2 campos PK tambien y querra que se cumplan las condiciones previamente mencionadas aunque no se si de manera obligatoria.

Enserio piensas eso???

volvemos a los apartamentos, las familias y los parqueos, entonces si la familia PEREZ se muda del residencial, no importa que manana se mude una familia nueva apellidada Ruiz, pueden perfectamente cambiarle al apartamento o al parqueo (pero no a los dos) el letrerito y colocar R en vez del antiguo P y me diras algo como, si si pero todos saben que la familia Perez ya se fueron asi que aunque el parqueo diga P la familia Ruiz puede parquearse alli... y llega un empleado nuevo a tu residencial, y lo mandan a limpiar el area de los parqueos de las familias que viven actualmente en los apartamentos, asi que ese empleaducho va y comienza a limpiar todos los parqueos de los apellidos que el conoce.. y de pronto se encuentra el apellido P y dira quienes rayos son 'P' no se quienes son, asi que estos no me daran nada de propina, y obvia limpiar ese parqueo porque el no sabe quien rayos es la familia P nadie se lo informo ni se lo dijo....

Ya me diras tu, cuando actualizes informacion de una tabla1 puedes perder completamente la relacion con la otra informacion de la tabla2. Siempre y cuando actualizes por el campo que los relaciona (o sea id_estado en este caso), si id_estado = 1 en la tabla1 lo actualizas a id_estado = 3 y la tabla2 no le haces nada, cuando consultes con WHERE y JOIN por el id_estado = 1 que te va a devolver? piensalo  si la tabla1 ya no tiene mas id_estado = 1 pero la tabla2 si....

si hablamos de pocas relaciones M:M podria bastarte con 3 tablas o hasta 4... pero existen ocasiones donde la estructura de tablas que tu necesitas para una aplicacion, va mas alla que 3 o 4 tablas, hay aplicaciones que depende su tamanio o crecimiento con el tiempo, van requieriendo mas de 20 tablas, donde existen relaciones de todo tipo entre esas 20 incluyendo tu famoso M:M

No es que sea lioso, si hay que analizar muy bien lo que estas intentando crear porque sino lo analizas y disenas bien, podria crear lo que se llama redundancia de datos (y no querras eso), ahora, si la persona que esta disenando la estructura sabe bien lo que esta haciendo, sabra montarte el asunto sin que esto pase. Yo no puedo decirte que siempre con una tabla auxiliar ya resuelves el problema de M:M porque depende mucho que entidades y que relaciones estaras peticionando, aveces si, aveces solo necesitas 3 tablas, pero aveces de esas 3 tablas se requieren 2 mas para hacer otra relacion M:M con otras entidades...

Como principiante no deberias aspirar enrollarte en desarrollar este tipo de estructuras porque hay que aplicarle mucha logica mental, y no solo logica, sino tambien considerar la optimizacion, el rendimiento de eso que quieres implementar y otras cosas...

Pero si tu pregunta es si con una o mas tablas auxiliar el problema se puede resolver en este tipo de relaciones, la respuesta es SI, solo que como principiante no deberias enrollarte ahi porque te puedes liar de mala manera.

Mira, yo no he utilizado nunca Workbench por lo cual no podria detallarte sobre estrellitas o marquitas que el te especifique, no manejo esta parte de esa aplicacion.

Tu pregunta siguiente, necesita una exposicion mas precisa para que comprendas.

Imaginate un residencial lleno de apartamentos, todos los apartamentos son identicos fisicamente (el mismo tamanio, color, pisos, etc). Ahora imaginate que todos esos apartamentos son tablas en MySQL, todos estan separados aunque visualmente sean identicos, que ocurre que en el apartamento 1 vive la familia Perez, en el apartamento 2 vive la familia Rodriguez, y asi sucesivamente, cada apartamento alberga una familia diferente. Imaginate que las familias son registros dentro de las tablas, ahora que ocurre todos los apartamentos al ser identicos tu necesitas saber cual es el apartamento de la familia Perez, para averiguar esto que necesitas? un identificador o numero o algo enfrente del apartamento que te especifique que ahi vive la familia 'Perez', imaginemos que ese identificador es un letrerito con la letra P gracias a este identificador (que en una tabla seria un PK o indice) ya sabes de todos esos apartamentos identicos cual es el de la familia Perez... pero ocurre algo, tu tienes que saber cual es el parqueo de la familia Perez, ya que los parqueos (mas tablas) estan frente a los apartamentos, pero los parqueos tambien son fisicamente identicos, que necesitas tu para saber cual es el parqueo de la familia Perez??? otro identificador o letrerito en el parqueo que tambien tenga la letra P pero si los parqueos tuvieran solamente un letrero ... y todos esos letreros estuvieran borrosos o vacios ... como sabes cual es el de la familia Perez???    (cuando te digo letreros vacios, imaginate que te hablo de campos en una tabla a los cuales no le has definido un PK o indice). Eso es lo que esta ocurriendo aca contigo, en la tabla2 definiste los campos (parqueos) pero no le escribiste al letrerito a que familia pertenecia (indices o PK) solamente colgaste el letrerito vacio. Entonces porque razon el apartamento que tiene el identificador P tiene que adivinar o saber cual de todos los parqueos con letreritos vacios le corresponde a la familia Perez?   

Explicame 

No creo que su profesor les haya dicho de manera muy seria que eviten siempre las relaciones M:M porque existen situaciones donde hay que estructurar y crear las tablas asi  no siempre sera una sola entidad con otra unica entidad  que el mundo donde vivimos es muy variado y un departamento puede tener varios empleados y varios empleados pueden estar a cargo de varios departamentos (aunque esto es solo un ejemplo) o un ejemplo mas logico, varios estudiantes pueden asistir a una clase de Ingles pero esos mismos estudiantes tambien podrian asistir a clases de Frances. Y las clases de Ingles y Frances pueden poseer mas de 1 rango de estudiantes en distintos horarios...

Lo que si puedo entender, es que tu profesor te dijese eso porque esta introduciendote en el tema de las relaciones y las entidades, y pues para evitar que te lies mucho o se lien otros, lo mejor es como basico intentar forzar a que relacionen de 1:1 o 1:M pero no mas que eso...

Ya cuando conozcan mas el asunto de las relaciones subdividir las tablas entre mas padre he hijos y ir relacionandolas todas por 1 o varios indices segun la conveniencia, es un proceso que dependiendo tu aplicacion podra obligarte a estructurar muchas tablas de relaciones 1:1, 1:M y hasta M:M o podra apenas requerir de tu tiempo pocas tablas de relaciones 1:M todo depende, pero para un principiante si puede resultar lioso ver un spaghettis de mas de 20 tablas donde hay relaciones de todo tipo ahi, por ende es comun que comienzen en lo mas basico, y es normal que se les peticione que por el momento no indaguen mas ni quieran crear tablas de relaciones M:M para que no se lien la cabeza, porque este ultimo modelado hay que tener mucho cuidado como se estructura para evitarse redundancia de datos y evitarte lios de spaghettis