Aplicacion administrador Mysql CentOS
Rodrigo Fuentealba
darkprox en gmail.com
Dom Ene 21 00:58:17 CLST 2007
El 19/01/07, Juan Martínez<jeugenio en umcervantes.cl> escribió:
> Javier A. Jimenez (Zykboss) escribió:
> > Alvaro Herrera wrote:
> >> Javier A. Jimenez (Zykboss) escribió:
> > y ese no es el tema, no
> > estamos hablando del mejor motor de base de datos. ni siquiera de la
> > solución que funciona mejor...
>
> Es que son dos cosas que van de la mano.
> Un buen software, siempre sera la mejor solucion "standart" para
> cualquier problema.
Correcto. Asi que a estudiar modelos de datos. Lee algo sobre Oracle y
los modelos de datos. Puede que sea comercial, pero te aseguro que
aprenderas mas en dos documentos de eso que en todo un manual.
Firmado, un DBA.
> > El tema es que hay tareas que MySQL las puede hacer bien, y es bueno y suficiente.
>
> El tema es que MySQL no se le puede llamar DBMS
Sí se le puede llamar DBMS. En eso estás errado.
Un sistema de administración de bases de datos (DBMS, SGBD, SABD) es
un sistema capaz de guardar (insert), modificar (update), eliminar
(delete) y mostrar (select) datos de manera que pueden ser
aprovechados.
Aunque muchos se me tiren encima, LDAP también es un DBMS, pero no los
guarda en manera de tablas relacionales, sino de árboles.
LDAP, así como MySQL no son RDBMS, pues MySQL no puede generar
relaciones entre datos. LDAP tampoco, pues las relaciones que se
generan son de padre a hijo.
> > Esto en realición al
> > comentario que originó este vertedero de opiniones, el cual tajantemente
> > dice "MySQL no deberia existir ni siquiera por si mismo"
>
> Por que rompe la teoria, y eso es grave.
Demasiado.
> >>> Personalmente trabajo con varios sistemas basados en MySQL, y el
> >>> problema que hemos tenido no es del motor, sinó con el diseño.
>
> Eso ocurre todo el tiempo, nada nuevo...
Apuesto a que seria mejor un diseño que valide los parámetros desde tu
aplicacion y deje a la BD gestionar todo con procedimientos
almacenados y funciones.
> >> Bueno, pero a ver, si dices "funciona bastante bien", por que dices que
> >> han tenido problemas con el diseño? No queda claro si te refieres a que
> >> MySQL ha causado que el diseño tenga que ser malo, o que simplemente
> >> tienes gente incompetente que hizo un mal diseño.
> >>
> > Y la comprensión de lectura ?
>
> Digamos que MySQL ayudar a hacer malos diseños...
Ayuda a hacer malos diseños? Es el causante de malos diseños.
> > El motivo es que no vale la pena invertir tiempo en estar a la caza de
> > errores que puedan surgir producto de la migración,
>
> Ok, es el primer argumento de peso hasta aquí.
Que es lo que hemos estado discutiendo por harto tiempo.
> > sobre todo cuando el sistema, como dije anteriormente, funciona bien
>
> Claro. Pero hoy uno debe ser altruista y siempre mirar hacia el ideal...
O mejor dicho, visionario y siempre mirar la calidad del producto. No
puedes sacar algo bueno basandote en cosas malas.
> Tuve la suerte de empezar con postgres y tener que usar mysql despues, y
> por Dios que uno agradece el consejo que le dieron al momento que uno
> tomaba la decision...
Bueno, uno se da cuenta. Yo tuve la mala suerte de partir a la inversa.
> > Claramente el objetivo de plano es echar por tierra a MySQL
Un boicot seria excelente, por el bien de todos.
> > y migrar
> > todo a Postgres
>
> No necesariamente, podria ser SQLite tambien :-)
...hasta a SQL Server u Oracle seria aceptable.
> > ("o cualquier otro RDBMS")... y por qué? porque MySQL es
> > malo...
>
> No.
Sí.
> Por que:
>
> 1. No es 100% opensource
Lo cual no necesariamente contribuye a que sea malo.
> 2. Rompe la teoria (grave)
Lo cual afirma que es malo.
> 3. Su argunmento principal es "es muy rapido". Yo podria escribir
> rapidamente algo que uses archivos planos y andaria aun mas rapido...
Su argumento principal es falso, de hecho, lo cual es publicidad
engañosa y eso hace que el producto final que ofrecen sea malo.
> > Ricardo mencionaba, tal vez el usuario no requiere integridad
> > referencial, solo tablas sueltas (si, MyISAM), y MySQL es una opción...
>
> No es opcion. Si quieres tablas sueltas, usa archivos de texto.
O mejor usar dBase o CSV... archivos sueltos.
> Lo minimo que uno espera de bases de datos *_relacionales_* es que te
> entregen nativamente la integridad referencial...
Claro. Pero MySQL no ha dicho que es relacional... lo cual es razon de
peso para no elegirlo.
> > No voy a entrar en el terreno de que es o no es un motor de base de
> > datos relacionales decente...
>
> O sea... Entonces cual es la idea?
Defender a MySQL a concho... Este es el abogado del diablo, defiende
lo indefendible.
> > Pero si es molesto ver gente que sale y
> > dice que MySQL es malo y punto, me parece algo parcial (tal vez
> > fanatismo por otro software)... Todo dependerá del tipo de aplicación a
> > desarrollar... y tal.
>
> Los argumentos que mas veo es "si es facil y funciona, entonces es
> bueno" y eso es falso, sino usemos todos hasefroch...por algo estamos aqui.
Hasefroch esta muy lejos de ser facil de usar, si me preguntan la
opinion, tienes que aprender a usar cada cosa que viene en Windows, el
Antivirus, el Antispam, liarte con unidades C:, D:, saber que aparte
de conectarte a otro PC tienes que estar en el mismo entorno de red
que el... etc.
> Cuesta mucho siempre hacer lo mejor que se pueda?
> O mejor es conformarse con lo bueno?
Bueno, un profesor me dijo alguna vez "lo mejor es enemigo de lo
bueno"... Fue el profesor que me echo de la UTFSM (Thno) porque me
eche Cobol 3 veces con el, asi que siempre trato de hacer lo mejor
posible. En el fondo, el cliente siempre quiere lo mejor...
> Y no me vengan con que lo mejor es enemigo de lo bueno, por que eso es
> para los autocomplacientes...
Eso o para los masoquistas...
--
Rodrigo Fuentealba Cartes
Desarrollador de Sistemas Web
Registered User 387639 - http://counter.li.org
Más información sobre la lista de distribución Linux