una mas sobre los motores... 
en fin, de las conclusiones que he leido, no me podido ajustar alguna a mi decision... ya que, mientras que algunas hacen mencion a decidir en cuanto que si la tabla va a ser para escribir se use Inno y si va a ser para consultar se use MyIsam, encuentro esto algo ambiguo ya que de alguna manera a mis tablas le haran tanto una funcion como la otra... y en cuanto a que proporcion, pues no se como decidir, ya que cierto una de mis tablas (eventos) sera mas escritura que lectura, de mi otra tabla (usuarios) se tendra que leer -ya que inicialmente contemple MyISAM- la existencia del usuario para el evento. Es decir, este factor con el que muchos conluyen tomar para la decision, a mi me deja en duda.
Otra cosa, ahora, sobre esto, el factor de las llaves foraneas no lo contemple como decisivo ya que por alguna forma u otra llego a considerar que mi codigo de programacion me mantiene a raz lo que se inserte en las tablas. Digamos que ese punto a favor del Innodb no es tan crucial para mi, al menos no asi lo siento en este.
algo que si me llamo la atencion fue que llegue a la -no se si correcta o incorrecta- conclusion que por ejemplo el tema "concurrent inserts" favorece a MyISAM mientras que el tema "table locking" le favorece a Innodb, de donde aqui, si tengo algo que pudiera ser un factor de decision, dependiente de mi siguiente duda:
table locking: http://dev.mysql.com/doc/refman/5.0/...e-locking.html
concurrent inserts: http://dev.mysql.com/doc/refman/5.0/...t-inserts.html
he leido que para "contrarrestar" (diciendole de alguna manera a esto) el efecto del table locking se recomienda que las sentencias select corran lo mas rapido posible, quizas mi traduccion es mala, de la pagina refente el parrafo es:
Cita:
y la verdad no comprendo como lograr esto (digamos que con mi tendencia a conservar MyISAM como motor)... es decir, el tiempo que se lleva a cabo el table locking es el tiempo que tarda en ejecutarse una sentencia? -select, por ejemplo-?, o el tiempo que se tiene una conexion mysql?... o cual? porque si es una fracccion de segundo o algunos segundos (que no lo exime en mi caso) quiza podria no considerarle importante... o si de alguna manera este tiempo esta determinado entre mis lineas de codigo... como podria mejorarle para evitar lo mayor posible el dichoso table locking?? como/cuando se "libera" una tabla del locking??Try to get the SELECT statements to run faster so that they lock tables for a shorter time. You might have to create some summary tables to do this.
Que quiere decir con la segunda observacion.... summary tables?? creo que entiendo el concepto pero como le aplicaria correctamente?? una tercera tabla que me relacione un evento a un usuario? eso generaria mas sentencias select... no me quedo claro...
llego a esta duda ya que, mi aplicacion seria un basico de altas de eventos, por diversos usuarios "internos" esparcidos en un area geografica de varios km2 (ciudades cercanas, vaya) y no se si este factor pudiera ser el que me de la pauta para detenerme y regresarme y comenzar a hacerlo todo con Inndb...
para un caso de una aplicacion que sera para una intranet de una corporacion con puntos de acceso dispersos (al menos 6) en una area geografica amplia... la posibilidad de tener algun problema con algun equipo que se congele o retrase existe, -especialmente en mi caso donde habra equipos malos y nuestra infraestructura no es la mejor- y he leido que para este tipo de detalles, la recomendacion es Innodb, pero no he logrado determinar en si porque, y como podria contrarrestarle en MyISAM... alguna referencia al respecto?? Convendria dada mi circunstacia el uso del Innodb??? o habria que considerar tambien el hardware del server? tambien la posibilidad latente que en mas de un punto de acceso se este tratando de ejecutar sentencias mysql.... mas select que insert/update, pero las posibilidades estan...
Y sobre el mismo locking, que tipo de error le presentaria al usuario, y como se puede recuperar uno como programador de esto?
otro factor seria el de hardware, he leido que para que Innodb no de problemas de rendimiento se necesitan muchos -de preferencia- recursos de hardware... pero no he logrado llegar a especificos otros mas que lo mencionado aqui
http://www.mysqlperformanceblog.com/...zation-basics/
y bueno mis recursos de mi server en ram estan mucho mas limitados que lo mencionado ahi, y mi sistema operativo es win32 (server2003)...
serian recomendable entonces quedarme en MyISAM por este detalle??? si es importante para esto, mi tabla de eventos que seria la que creceria a mayor velocidad (porque para registrar evento hay que tener el usuario, pero un usuario podra aparecer en indefinidos eventos) creceria a un promedio de 150 registros diarios (lun-vie, y no constante) y no se eso en tamaño bytes a cuanto pueda ascender, la tabla cuenta con (considerando MyISAM, y sin la opcion de FKs) 11 columnas, en su mayoria varchar, alguna long int, e incluso una int... aunque bueno de una u otra manera ambas creceran a un ritmo parecido... no se de que tamaño o si es considerable con este tipo de numero de registros, o si de plano estoy muy lejos de lo que seria una tabla grande... ya que hablan que Innodb genera en tamaño tablas mas grandes, pero, que tanto es tantito? es decir, aplicaria este factor dada mi circunstacia? seria crucial para la toma de la decision?
De alguna manera encuentro incongruente que se mencione por un lado que Innodb es mejor en el sentido del table locking pero que no es muy efectivo con BDDs que tengas muchas tablas.
Otra cuestion que me llama la atencion mucho es que, la mayoria de las referencias sobre el rendimiento hablan de terminos como "es mas rapido si tiene muchos selects" o "si muchas sesiones estan activas" o "es mas rapido MyISAM" y etc, todo en terminos de muchas/pocas pequeña/grande... y la verdad no logro llegar a una conclusion al respecto... alguna guia sobre como interpretar esas indicaciones??? como saber si en mi caso en particular es depreciable algun factor en particular?
espero no haber sido muy pesado en este post... estoy tratando de aprenderle...
cualquier observacion es bienvenida y muy agradecida.
Saludos.
(uso xampp for windows 1.7.3)
