Sv Community El Salvador
Soporte y Tecnología => Programación => Base de Datos => Mensaje iniciado por: tekun en mayo 08, 2014, 10:53:55 am
-
no quiero denigrar ni restar valor, pero al ver este video, definitivamente agradezco al sicario que me dijo "hey negro utiliza postgres, estoy leyendo que esta vergona esa base de datos"....eso haya por 2007.... ahora luego de muchos años... creo que es difícil de no ver la gran ayuda que me brindo...
les dejo este video... espero opiniones de aquellos que utilizan MySQL en sus trabajos:
Tekpub: Why Not MySQL? (http://www.youtube.com/watch?v=1PoFIohBSM4#ws)
-
MySQL se condeno desde que lo agarro Oracle. si pensas usar MySQL mejor usa MariaDB. para proyectos sencillos, un blog, cosas asi... esta bien, para algo mas avanzado, postgre es mas adecuado.
-
MySQL se condeno desde que lo agarro Oracle. si pensas usar MySQL mejor usa MariaDB. para proyectos sencillos, un blog, cosas asi... esta bien, para algo mas avanzado, postgre es mas adecuado.
Muy de acuerdo.
Dentro de las soluciones libres, PostgreSQL por mucho es la mejor. Pero yo también agregaría: FireBird
Para soluciones super ligeras: SQLite
-
MySQL se condeno desde que lo agarro Oracle. si pensas usar MySQL mejor usa MariaDB. para proyectos sencillos, un blog, cosas asi... esta bien, para algo mas avanzado, postgre es mas adecuado.
naaaa estamos hablando de años de existencia de MySQL, oracle compro a sun en abril 2009.... y para ese entonces MySQL ya era MySQL....
ahora veo porque se dicen llamar la db más rápida.... uta sin tanta verificación "de rigor" como no va a ser más rápida la consulta....
pero yo lo pensaría dos veces.... si a la hora de meter el valor 113 en una tabla luego vea el valor 99....
-
naaaa estamos hablando de años de existencia de MySQL, oracle compro a sun en abril 2009.... y para ese entonces MySQL ya era MySQL....
lo que quiero decir con eso es que muchos comportamientos no se han corregido, MySQL se ha estancado en correciones y features porque asi le gusta a Oracle.
ahora veo porque se dicen llamar la db más rápida.... uta sin tanta verificación "de rigor" como no va a ser más rápida la consulta....
pero yo lo pensaría dos veces.... si a la hora de meter el valor 113 en una tabla luego vea el valor 99....
ahi vos estas hablando en hiperbola, no seas exagerado, en ningun lado el video dice que MySQL NO SIRVE, eso que propones vos tampoco va a pasar. alguna vez has oido la frase "para cada tarea la herramienta correcta"? de eso se trata este tema. ciertamente no vas a querer errores de validacion, inserciones no controladas o cosas por el estilo en un sistema de alta confiabilidad, pero para un blog, una pagina web pequeña, un inventario chiquito o simplemente para tecniquear, MySQL es MAS que suficiente.
eso si, si se piensa usar MySQL mejor usar MariaDB que es un fork libre de MySQL sin las manos sucias de oracle.
-
la mejor opcion ahorita si t gusta mysql seria Mariadb como dice goomba.
por ahora yo sigo usando mysql
-
en ningun lado el video dice que MySQL NO SIRVE, eso que propones vos tampoco va a pasar. alguna vez has oido la frase "para cada tarea la herramienta correcta"?
es correcto, por eso yo tampoco lo he dicho...
mi problema es que, nunca he creado un blog, o algo para jugar, por eso nunca he pensado en usar MySQL...
por eso puse la pregunta de que espero comentarios de la gente que usa ese RDBMS... porque lo usan, aun sabiendo los "features" que tiene...
por ejemplo moyo18, dice que es mejor Mariadb, pero el mismo dice seguir usando MySQL... mi pregunta es porque?
-
dice que es mejor Mariadb, pero el mismo dice seguir usando MySQL... mi pregunta es porque?
muchos proveedores de hosting vienen con mysql creo que por eso?
por lo menos yo en mi servidor por defecto tenia mysql, me acuerdo que alguien me pidio postgree para un proyecto y lo instalamos, y eso es todo no tengo mas gestores que esos.
yo ni habia escuchado de maria hasta el dia de hoy XD
-
por ejemplo moyo18, dice que es mejor Mariadb, pero el mismo dice seguir usando MySQL... mi pregunta es porque?
porque hace lo que el necesita y nada mas que eso?
-
no quiero denigrar ni restar valor
mi problema es que, nunca he creado un blog, o algo para jugar, por eso nunca he pensado en usar MySQL...
(http://cdn.niketalk.com/4/4c/4c1e3d65_AwkwardSeal-1.jpeg)
-
asdñkfjasdkfja
este g00mba hombe......
-
En MySQL podes activar el "modo estricto" que hace que muchas de las cosas mencionadas sean denegadas.
Sin embargo tengo que decir que el problema viene a ser mas del programador que deben conocer los aspectos y funcionamiento de la base de datos que esta usando.
Ademas de que yo no considero que el hecho que postgres te impida meter datos erroneos sea un beneficio sustancial, si no mas bien es como un consuelo para quien no sabe lo que esta haciendo con la BD (sin ofensa, asi lo veo).
Alguien que ha trabajado tanto tiempo con MySQL/MariaDB como con Postgres se da cuenta tambien de los beneficios, calidad de herramientas y soporte que tienen ambos, sin embargo es fácil decir "esto no sirve" cuando no se entiende exactamente el porque fue diseñado de esa manera.
Quiza es la tendencia a creer que lo que uno conoce mas es lo mejor!
-
vaia, al fin alguien viene a hablar técnicamente... y de casos concretos...
....., los ejemplos expuestos no son basados en algo no parametrizado... sino en la definición de una tabla como tal...
diseñar una tabla con un campo que no permita NULOS y que al hacer un insert los permita, no es bajo ningún concepto falta de parametrización... yo no estoy comparando features estoy comparando formas "básicas"...
eso de que se "puede" configurar modo estricto esta demás, con los ejemplos del video...
sino que al momento de crear la tabla diga: "mire pero aunque le ponga que no acepta nulos, siempre los podrá guardar" .... o sea helloooou
y ese es mi punto....
de que me sirve almacenar una fecha "31-febrero-2003" y que cuando lo guarde me diga registro guardado.... las fechas no son básicas acaso....?
-
que me corrijan sino es asi, pero creo que esos aspectos que has mencionado no dependen solo de base de datos, tmb depende de la validacion que hagas con los datos osea si se te pasa un 31 de febrero creo que tenes un probleema a la hora de mandar ese dato a la base, la base te almacena los datos que le mandes pero vos debes de validar esa data antes de ingresarlos....
-
que me corrijan sino es asi, pero creo que esos aspectos que has mencionado no dependen solo de base de datos, tmb depende de la validacion que hagas con los datos osea si se te pasa un 31 de febrero creo que tenes un probleema a la hora de mandar ese dato a la base, la base te almacena los datos que le mandes pero vos debes de validar esa data antes de ingresarlos....
por eso decia, depende que tan serio es tu proyecto pues, en un desarrollo para alta confiabilidad es normal tener mas de un sistema de validaciones, y esta perfectamente bien que la base de datos tenga su propia validacion, pero un programador medianamente competente SIEMPRE pone algun tipo de validacion en su codigo, indistintamente de si la BD tiene o no tiene validacion.
-
vaia, al fin alguien viene a hablar técnicamente... y de casos concretos...
....., los ejemplos expuestos no son basados en algo no parametrizado... sino en la definición de una tabla como tal...
diseñar una tabla con un campo que no permita NULOS y que al hacer un insert los permita, no es bajo ningún concepto falta de parametrización... yo no estoy comparando features estoy comparando formas "básicas"...
eso de que se "puede" configurar modo estricto esta demás, con los ejemplos del video...
sino que al momento de crear la tabla diga: "mire pero aunque le ponga que no acepta nulos, siempre los podrá guardar" .... o sea helloooou
y ese es mi punto....
de que me sirve almacenar una fecha "31-febrero-2003" y que cuando lo guarde me diga registro guardado.... las fechas no son básicas acaso....?
Mi punto exactamente.
En base a lo que escribis pareciera que las validaciones en tus programas son hechas por la base de datos y no por el sistema en si, hay muchos problemas con eso:
1. Si usas un ORM en tu sistema no podes asumir que será Postgres la BD y por lo tanto tus validaciones tendrian que ser configuradas por cada BD soportada por el abstractor de bases de datos.
2. Si tu sistema depende del mensaje de error de la BD para determinar el campo erroneo hay una penalidad de rendimiento ya que tenes que enviar la consulta a la BD para darte cuenta que la fecha 31-Feb-2003 estaba erronea.
Cuando se trata de sistemas a nivel de producción en grandes empresas resulta que ni MySQL, ni Postgres (ni ninguna BD dicho sea de paso) se instalan y se usan sin configurarlas, generalmente habrá un DBA que configurará la BD con los parametros necesarios como es el modo estricto, ajustes de memoria, deshabilitar motores de BD sin uso, ajuste de balance y distribucion de carga, replicacion, etc.
Quizá aqui se erra un poco en la falta de sanitización de datos que se pasan a la BD, en tu ejemplo decis que:
diseñar una tabla con un campo que no permita NULOS y que al hacer un insert los permita, no es bajo ningún concepto falta de parametrización... yo no estoy comparando features estoy comparando formas "básicas"...
Pero el error esta precisamente en que MySQL no te guarda un NULL en un campo que no permite NULL si no que hace un CAST automatico a una cadena vacia y te diré que en la mayoria de casos es hasta lo que el programador talvez esperaba.
Aqui entra el caso de conocer los aspectos de MySQL a profundidad, por ejemplo insertar un NULL o 0 (cero) en un index con autoincremento hace que este genere el siguiente número en la serie.
Comprender a profundidad como MySQL trata los NULLs requiere de al menor leer las siguientes dos paginas:
https://dev.mysql.com/doc/refman/5.0/es/working-with-null.html (https://dev.mysql.com/doc/refman/5.0/es/working-with-null.html)
http://dev.mysql.com/doc/refman/5.0/es/problems-with-null.html (http://dev.mysql.com/doc/refman/5.0/es/problems-with-null.html)
En fin, para terminar te digo que MySQL no es algo de "hobbie" ni para "juguetar", si bien sirve para eso por su facilidad tambien su robustes hace que todas estas companias lo usen: http://www.mysql.com/customers/ (http://www.mysql.com/customers/)
Digo Facebook, Twitter, Wikipedia, LinkedIn, etc. no pueden haber agarrado lo peor y seguir con ello!
-
1. Si usas un ORM en tu sistema no podes asumir que será Postgres la BD y por lo tanto tus validaciones tendrian que ser configuradas por cada BD soportada por el abstractor de bases de datos.
interesante.... pero tengo un ejemplo aún más interesante....
imaginate que yo use MySQL y cree una aplicación de escritorio "con mi favorito vb.Net" y tuve que validar un campo NULO para que en realidad no acepte nulos... hasta ahí todo bien... vendo la aplicación y listo me marcho.... Luego contratan a alguién para que haga una versión Web, junto con otros dos cheros que programen en Android y otros 4 que programen para iOS... La empresa les exige usar la misma DB por no aceptan la propuesta de tener esparcida su información en plataformas distintas.... que tienen que hacer esos otros programadores??? hacer validaciones innecesarias porque la validación de MySQL no hace lo que debe de hacer... Y que decir de una herramienta que suba información de forma masiva, un Bulk de datos...
ese es mi punto... para que reinventar la rueda cuadrada y perder tiempo en tanta validación si con una debe de bastar!
2. Si tu sistema depende del mensaje de error de la BD para determinar el campo erroneo hay una penalidad de rendimiento ya que tenes que enviar la consulta a la BD para darte cuenta que la fecha 31-Feb-2003 estaba erronea.
nah... la penalidad siempre existe... lo que difiere es quién lo hace... la App o la DB...
Quizá aqui se erra un poco en la falta de sanitización de datos que se pasan a la BD, en tu ejemplo decis que:
Pero el error esta precisamente en que MySQL no te guarda un NULL en un campo que no permite NULL si no que hace un CAST automatico a una cadena vacia y te diré que en la mayoria de casos es hasta lo que el programador talvez esperaba.
Aqui entra el caso de conocer los aspectos de MySQL a profundidad, por ejemplo insertar un NULL o 0 (cero) en un index con autoincremento hace que este genere el siguiente número en la serie.
Comprender a profundidad como MySQL trata los NULLs requiere de al menor leer las siguientes dos paginas:
https://dev.mysql.com/doc/refman/5.0/es/working-with-null.html (https://dev.mysql.com/doc/refman/5.0/es/working-with-null.html)
http://dev.mysql.com/doc/refman/5.0/es/problems-with-null.html (http://dev.mysql.com/doc/refman/5.0/es/problems-with-null.html)
imaginate un registro de clientes, donde el NIT no debe de ser NULL.... pero por lo menos hay CINCO aplicaciones que hacen insert a mi tabla... y luego hago una auditoría de esa tabla y encuentro valores NULL... digo p$$ta, como es esta shit, quién y cómo es que tengo valores NULL....
yo como DBA que tengo que hacer ??
leyendo uno de los links me parece gracioso esto:
Por lo tanto, es totalmente posible insertar cadenas vacias o ceros en columnas marcadas como NOT NULL, ya que son valores NOT NULL
falso!, el valor NULL es distinto de vacío y también distinto de 0... en vb.Net el tipo de dato string tiene esto String.IsNullOrEmpty
acá tengo una versión de SQLServer 2000, de hace 14 años... el vídeo que puse es de hace 3 años... y SQLServer me pega la putiada
insert into abb values (null);
Cannot insert the value NULL into column 'kaaa', table 'TEST.dbo.abb'; column does not allow nulls. INSERT fails
me acabo de acordar de otra del video.... siempre con la misma tabla de clientes... si el campo SALARIO es un numerico de 6 enteros y 2 decimales... y ya posee unos cientos de registros y alguién por error cambia la definición de la tabla y esa columna le baja la escala a 2 enteros.... sabiendo que ya maneja información de salario real de clientes, que creen que hace MySQL ????
tada! hace el cambio en la tabla y tadaaa! cambia toooodos los valores automáticamente de ese campo al nuevo valor máximo permitido....
jueeeela....
-
interesante.... pero tengo un ejemplo aún más interesante....
imaginate que yo use MySQL y cree una aplicación de escritorio "con mi favorito vb.Net" y tuve que validar un campo NULO para que en realidad no acepte nulos... hasta ahí todo bien... vendo la aplicación y listo me marcho.... Luego contratan a alguién para que haga una versión Web, junto con otros dos cheros que programen en Android y otros 4 que programen para iOS... La empresa les exige usar la misma DB por no aceptan la propuesta de tener esparcida su información en plataformas distintas.... que tienen que hacer esos otros programadores??? hacer validaciones innecesarias porque la validación de MySQL no hace lo que debe de hacer... Y que decir de una herramienta que suba información de forma masiva, un Bulk de datos...
ese es mi punto... para que reinventar la rueda cuadrada y perder tiempo en tanta validación si con una debe de bastar!
nah... la penalidad siempre existe... lo que difiere es quién lo hace... la App o la DB...
hablas como todo DBA. un programador NO PUEDE NI DEBE dejar todas las validaciones del lado de la base de datos. esa es una MALA PRACTICA. es mas, cuando escribo mi codigo, no solo valido mis entradas, sino que lo hago AGNOSTICO A LA DB. que significa esto? que como no se con que BD lo voy a ocupar, tengo, POR HUEVOS que validar mis campos, ese ejemplo que estas poniendo vos es clasico ejemplo de programadores dejados.
imaginate un registro de clientes, donde el NIT no debe de ser NULL.... pero por lo menos hay CINCO aplicaciones que hacen insert a mi tabla... y luego hago una auditoría de esa tabla y encuentro valores NULL... digo p$$ta, como es esta shit, quién y cómo es que tengo valores NULL....
yo como DBA que tengo que hacer ??
activarle el modo estricto a mysql como ya te dijeron?
leyendo uno de los links me parece gracioso esto:falso!, el valor NULL es distinto de vacío y también distinto de 0... en vb.Net el tipo de dato string tiene esto String.IsNullOrEmpty
acá tengo una versión de SQLServer 2000, de hace 14 años... el vídeo que puse es de hace 3 años... y SQLServer me pega la putiada
me acabo de acordar de otra del video.... siempre con la misma tabla de clientes... si el campo SALARIO es un numerico de 6 enteros y 2 decimales... y ya posee unos cientos de registros y alguién por error cambia la definición de la tabla y esa columna le baja la escala a 2 enteros.... sabiendo que ya maneja información de salario real de clientes, que creen que hace MySQL ????
tada! hace el cambio en la tabla y tadaaa! cambia toooodos los valores automáticamente de ese campo al nuevo valor máximo permitido....
jueeeela....
y porque le vas a cambiar la definicion de tipo a una columna QUE YA ESTA LLENA? ya sea MySQL, Oracle o cualquier otra, corres serio riesgo de perder informacion en el proceso. para mi que ya le andas buscando tres pies al gato.
-
interesante.... pero tengo un ejemplo aún más interesante....
imaginate que yo use MySQL y cree una aplicación de escritorio "con mi favorito vb.Net" y tuve que validar un campo NULO para que en realidad no acepte nulos... hasta ahí todo bien... vendo la aplicación y listo me marcho.... Luego contratan a alguién para que haga una versión Web, junto con otros dos cheros que programen en Android y otros 4 que programen para iOS... La empresa les exige usar la misma DB por no aceptan la propuesta de tener esparcida su información en plataformas distintas.... que tienen que hacer esos otros programadores??? hacer validaciones innecesarias porque la validación de MySQL no hace lo que debe de hacer... Y que decir de una herramienta que suba información de forma masiva, un Bulk de datos...
ese es mi punto... para que reinventar la rueda cuadrada y perder tiempo en tanta validación si con una debe de bastar!
nah... la penalidad siempre existe... lo que difiere es quién lo hace... la App o la DB...
imaginate un registro de clientes, donde el NIT no debe de ser NULL.... pero por lo menos hay CINCO aplicaciones que hacen insert a mi tabla... y luego hago una auditoría de esa tabla y encuentro valores NULL... digo p$$ta, como es esta shit, quién y cómo es que tengo valores NULL....
yo como DBA que tengo que hacer ??
leyendo uno de los links me parece gracioso esto:falso!, el valor NULL es distinto de vacío y también distinto de 0... en vb.Net el tipo de dato string tiene esto String.IsNullOrEmpty
acá tengo una versión de SQLServer 2000, de hace 14 años... el vídeo que puse es de hace 3 años... y SQLServer me pega la putiada
me acabo de acordar de otra del video.... siempre con la misma tabla de clientes... si el campo SALARIO es un numerico de 6 enteros y 2 decimales... y ya posee unos cientos de registros y alguién por error cambia la definición de la tabla y esa columna le baja la escala a 2 enteros.... sabiendo que ya maneja información de salario real de clientes, que creen que hace MySQL ????
tada! hace el cambio en la tabla y tadaaa! cambia toooodos los valores automáticamente de ese campo al nuevo valor máximo permitido....
jueeeela....
si hay cierta penalidad en ambos casos, pero sinceramente entre realizar las validaciones en la aplicación,o que ocurra en la BD lo siguiente: que si el valor esta correcto, realiza correctamente la consulta, sino realiza la primera consulta, informa del error, el usuario lo corrige y vuelve a realizar la consulta, el usuario se vuelve a equivocar, realiza otra consulta, informa del error...... la BD deberia responder peticiones innecesarias que se pudieron haber resuelto con una simple validación que tampoco es reinventar la rueda considerando en el caso de php que la mayoria de framework viene ya con funciones de validación.
En el caso de programación movil (android o ios) tambien pondria que si no haces las validaciones en la app, , considera el caso que si las validaciones solo son en la base se podria dar el caso que por consultas de datos erroneos hicieras gastar al usuario su plan de datos.
PD:
hablas como todo DBA. un programador NO PUEDE NI DEBE dejar todas las validaciones del lado de la base de datos. esa es una MALA PRACTICA. es mas, cuando escribo mi codigo, no solo valido mis entradas, sino que lo hago AGNOSTICO A LA DB. que significa esto? que como no se con que BD lo voy a ocupar, tengo, POR HUEVOS que validar mis campos, ese ejemplo que estas poniendo vos es clasico ejemplo de programadores dejados.
:yao_ming: por gusto escribi el g00mba lo explico mejor
-
:yao_ming: por gusto escribi el g00mba lo explico mejor
de hecho me gusto mucho tu aporte, no habia considerado el punto de vista de las apps moviles.
-
imaginate que yo use MySQL y cree una aplicación de escritorio "con mi favorito vb.Net" y tuve que validar un campo NULO para que en realidad no acepte nulos... hasta ahí todo bien... vendo la aplicación y listo me marcho.... Luego contratan a alguién para que haga una versión Web, junto con otros dos cheros que programen en Android y otros 4 que programen para iOS... La empresa les exige usar la misma DB por no aceptan la propuesta de tener esparcida su información en plataformas distintas.... que tienen que hacer esos otros programadores??? hacer validaciones innecesarias porque la validación de MySQL no hace lo que debe de hacer... Y que decir de una herramienta que suba información de forma masiva, un Bulk de datos...
ese es mi punto... para que reinventar la rueda cuadrada y perder tiempo en tanta validación si con una debe de bastar!
Ahi habrian 3 grandes errores si fuera una empresa que se dedicara a hacer sistemas:
1. En tu caso expuesto los programadores nuevos desconocian los requisitos del sistema, sobre todo el manejo de datos nulos.
2. Digamos que "todo esta bien porque la validación la hace Postgres" pero entonces si los programadores nuevos obviaron el punto anterior, entonces tambien van a desconocer que tu BD hace validaciones de NULL osea que el programa de ellos va a colapsar al primer NULL porque no van a manejar el error de la base de datos.
3. No se porque no comence por esto: como ingresas un valor NULL por error desde una interfaz web?, o incluso desde una aplicación de escritorio?. A menos que explicitamente hagas conversion de cadena vacia a NULL o especifiques NULL como valor en tu query NINGUN lenguaje devuelve NULL para un textbox vacio o para un checkbox sin cheque, en otras palabras creo que estamos discutiendo sobre cosas que para comenzar en realidad no pasan.
nah... la penalidad siempre existe... lo que difiere es quién lo hace... la App o la DB...
Lo decis como si la aplicación no tuviera que consultar el pool de sockets para conectarse a una BD, ocupar una conexión de la BD y una gran cantidad de RAM/CPU. Sin contar que en sistemas gigantes la BD se encuentra en otro servidor por lo que estas hablando hacer generar IO en la red para la validación de una fecha. No se como siquiera remotamente esto se puede despreciar.
imaginate un registro de clientes, donde el NIT no debe de ser NULL.... pero por lo menos hay CINCO aplicaciones que hacen insert a mi tabla... y luego hago una auditoría de esa tabla y encuentro valores NULL... digo p$$ta, como es esta shit, quién y cómo es que tengo valores NULL....
Volvemos al punto 3 de los problemas, en todo caso podes encontrar una cadena vacia, no un null, y para seguir no creo que una aplicación web de esta epoca tenga que enviar el formulario para que valide con la BD si el NIT estaba vacio. Tendría que ser un chequeo JS para comenzar y luego uno de lado de servidor.
yo como DBA que tengo que hacer ??
Configurar bien la DB seria un buen comienzo
leyendo uno de los links me parece gracioso esto:
Por lo tanto, es totalmente posible insertar cadenas vacias o ceros en columnas marcadas como NOT NULL, ya que son valores NOT NULL
falso!, el valor NULL es distinto de vacío y también distinto de 0... en vb.Net el tipo de dato string tiene esto String.IsNullOrEmpty
Creo que leiste mal porque eso esta correcto. De hecho decis que es falso y luego afirmas lo mismo que dice el texto que citaste.
me acabo de acordar de otra del video.... siempre con la misma tabla de clientes... si el campo SALARIO es un numerico de 6 enteros y 2 decimales... y ya posee unos cientos de registros y alguién por error cambia la definición de la tabla y esa columna le baja la escala a 2 enteros.... sabiendo que ya maneja información de salario real de clientes, que creen que hace MySQL ????
tada! hace el cambio en la tabla y tadaaa! cambia toooodos los valores automáticamente de ese campo al nuevo valor máximo permitido....
jueeeela....
Bueno, para comenzar que DBA cambia un tipo de columna "a prueba y error"?, osea quien en su sano juicio va a cambiar el tipo de una columna de una tabla de una aplicación en producción sin un estudio previo que avale el cambio?.
Primera vez en mi vida que leo un DBA que su seguridad de que hizo bien el cambio es que la BD no le dió error.
Pensa en este caso: el DBA hace el cambio de 6 a 2 decimales en Postgres y no da error porque no comio decimales, luego resulta que viene alguien y mete el primer salario con 6 decimales y bum, Postgres da error, la aplicacion no sabe como manejarlo y da error, posiblemente genere una excepción y se cierre... así es la forma de trabajar con Postgres?