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?
