Cita: En particular, en el modelo relacional, la gestion de tipos de datos es algo que concierne explicitamente a las bases de datos desde la definicion teorica de las mismas y se denomina "Integridad de dominio",
Una aplicación no es una base de datos,ni es el modelo relacional.El modelo relacional es una cosa, una aplicación es otra.
Cita: Como se puede ver, el dominio db_enum es un string, pero es la base de datos la que se encarga de gestionar su tipo y que su valor sea valido.
Asi que, dependiendo del motor de base de datos que uses, un cierto dato, tiene una representación ...variable, dependiendo de qué motor use.Lo lógico es que la aplicación normalice su representación, lo cual significa, normaliza el tipo de dato, independientemente del sistema de almacenamiento.
Cita: la gestion de tipos de datos e integridad de dominio (que son casi casi la misma cosa) es responsabilidad de la base de datos
A nivel de aplicación,conceptualmente, un enum es una variable que puede tener un número restingido de valores.Si un cierto sistema de almacenamiento gestiona los enums como strings, otros como entero, otros como lo que sea, eso no es más que la proyección de ese tipo de dato, sobre ese sistema de almacenamiento concreto.Eso forma parte de la idea de serializacion.
Si la base de datos se encarga de gestionar tipos, y que el valor sea válido, supongo que cuando recibes datos de un formulario, *sin comprobar tipos, ni valores válidos*, haces un insert...y si falla, al usuario le devuelves el error devuelto por la base de datos, verdad?
La responsabilidad de comprobar tipos, valores válidos y la integridad de dominio, va desde el cliente, hasta varias (multiples) capas del backend.No creo que haya mucha gente que en su sano juicio le deje a la base de datos "comprobar tipos y la integridad de dominio".
Por otro lado....el código que tú propones, deja en manos de php(!!) la comprobación del tipo...sé consecuente...llama a la base de datos, obtén la metadata de las columnas que van a ser modificadas (buena suerte con los updates cruzados), y haz el binding según esa metadata, no según lo que diga php.
Cita: No confundamos limitaciones con responsabilidades,[...] que algunas implementaciones como mysql no lo hagan no quiere decir que no le concierna.
A ver si consigo entender esto, entre tanta retórica...Quieres decir que le concierne, pero que no lo hace...Ah...Pues entonces, alguien tendrá que hacerlo, no?
Aparte...como que no lo hace? Puedes hacer casi de todo con triggers...Si quieres construir tu aplicación así, claro...Y, esa sería la única forma (a base de muchos..muchos..triggers) que coincidirían las reglas de dominio SQL con las reglas de dominio de una aplicación.
Claro, que también podría elegir guardar mis datos en XML, o en MongoDB, o en ficheros planos, o en json, incluso insert() podría efectuarse sobre un webservice, un interfaz REST, o a través de SOAP.
Tú confundes "debe" con "es el responsable de".Que una base de datos relacional "deba" cumplir con una serie de restricciones de dominio, no significa que "sea el responsable de" mantener esas restricciones de dominio, sobre todo, cuando es un fallo de diseño presuponer que tus datos van a estar almacenados en un soporte con ciertas características.Más aún, presuponer que ese soporte va a realizar comprobaciones extra del dominio (por ejemplo, comprobar un nombre de usuario sobre una tabla de nombres de usuario no permitidos).Puedes hacerlo con SQL? Claro, por supuesto, con triggers....y esperando que nunca vayas a cambiar de base de datos...
Que buenos tiempos los del 92, con los dbase4 y todo eso...las aplicaciones estaban DENTRO de la base de datos...Pero aplicar esos conceptos en el 2015...
El resto , de ingenierías inversas, etc, no sé con qué tiene que ver...demasiada retórica.