¿Hay alguna manera de efectuar tipos de datos definidos por el usuario en MySQL?

Question

que tienen una base de datos que almacena (entre otras cosas), los siguientes elementos de información:

• identificadores de hardware BIGINT s
• Capacidades de almacenamiento BIGINT s
• nombres de hardware VARCHAR s
• la World Wide puerto Nombres VARCHAR s

Me gustaría ser capaz de capturar una imagen más refinada d definición de estos tipos de datos. Por ejemplo, las ID de hardware no tienen importancia numérica, por lo que no me importa cómo se formatean cuando se muestran. Las capacidades de almacenamiento, sin embargo, son números cardinales y, a petición del usuario, me gustaría presentarles miles y separadores decimales, p. 123,456.789. Por lo tanto, me gustaría refinar BIGINT en, digamos ID_NUMBER y CARDINAL.

Lo mismo ocurre con los nombres de hardware, que son texto simple y WWPN, que son cadenas hexadecimales, p. 24: 68: AC: E0. Por lo tanto, me gustaría refinar VARCHAR en ENGLISH_WORD y HEXSTRING.

Los tipos de datos específicos que inventé son solo ilustrativos.

Me gustaría mantener toda esta información en un solo lugar y me pregunto si alguien sabe de una buena manera de mantener todo esto en mis definiciones de tabla MySQL. I podría usar el campo Comentario de la definición de la tabla, pero eso me huele a pescado.

Un enfoque sería definir la estructura de datos en otro lugar y usar esa definición para generar mi CREATE TABLE s, pero eso sería una revisión importante del código que tengo actualmente, entonces estoy buscando alternativas.

¿Alguna sugerencia? El lenguaje de aplicación en uso es Perl, si eso ayuda.

Answer 1

Una buena forma de hacerlo es usar vistas. Por ejemplo, para insertar comas en un número cardinal, puede utilizar:

mysql> create table foo (id int); 
Query OK, 0 rows affected (0.12 sec) 

mysql> insert into foo (id) values (123456789); 
Query OK, 1 row affected (0.00 sec) 

mysql> create view v_foo as select format(id, 0) as id from foo; 
Query OK, 0 rows affected (0.10 sec) 

mysql> select * from v_foo; 
+---------------+ 
| id   | 
+---------------+ 
| 123,456,789 | 
+---------------+ 
1 row in set (0.02 sec) 

Se puede utilizar otra string functions para dar formato a otros campos, y almacenarlos en la definición de vista.

Answer 2

Propondré una respuesta que cuestiona la pregunta.

Uno de los mantras que las personas que modelan las bases de datos como de zumbido es la separación de la capa de presentación (formato) y datos y creo que una parte relevante de like es algo como:

'Tú no almacenar datos formateados en sus bases de datos, ni discriminará contra ninguna opción de formato. Deberás almacenar los datos en los tipos de datos compatibles nativos. Tus aplicaciones deberán proporcionar una capa de presentación y formatear tus columnas.

Bueno, la respuesta de friedo no va directamente en contra de esto - los datos solo se presentan a través de una vista, el almacenamiento sigue siendo nativo.

Aún así, depende de cómo defina la capa de presentación allí; si la vista y la configuración del servidor se consideran parte de la capa de presentación, todo está bien; de lo contrario, hay posibles problemas ya que yo, posible usuario de su sistema ser capaz de especificar el hecho de que mi separador de miles es una cita única (y lo es, al menos en el lugar de mi residencia actual).

Además, una vez que va por ese camino, ¿cuánto tiempo cree que pasará hasta que tenga que ocuparse de las solicitudes para volver a analizar los datos del texto en un número y posiblemente terminar en situaciones en las que esto podría ser ambiguo (como DD/MM/AA frente a MM/DD/AA)

La queja anterior solo se refiere al formateo, la determinación del número de dígitos decimales define el dominio de sus datos y es una buena cosa, ya que limita la posibilidad de que entren datos inconsistentes en su base de datos.

EDITAR: (entreteniendo un poco más el punto de vista del purista, con respecto a las bases de datos) Decir que los datos numéricos hexadecimales no tienen significado en otras bases es generalmente una declaración falsa. Los valores numéricos no tienen ninguna base y se pueden representar en cualquier base. Su dominio (el conjunto de valores permitidos) es el mismo.

La elección del hexadecimal para la dirección MAC es natural debido a razones históricas y al hecho de que es, por ejemplo, fácil de leer la parte del proveedor en ese formato. La elección del formato "divertido" para direcciones IPv4 es histórica, probablemente con una razón anecdótica.

Pero ambos son solo una opción e internamente un buen sistema los almacenará sin sesgo (por ejemplo, almacenar IPv4 ya que el texto no es bueno). Cuando RDBMS le presenta los resultados de una consulta (en una pantalla) ya toma el rol de una aplicación y formatea los resultados de alguna manera.

Esto no es significativo y el formato que utilizará en su aplicación no debe influir en la forma de almacenar las Capacidades de almacenamiento u otras propiedades de la entidad.

Así que estoy diciendo que se trata de datos de configuración de la aplicación (metadatos a la fecha central) y por supuesto puede/debe almacenarse en la base de datos, pero con MySQL (que no es tan rico definiendo tipos personalizados) puede No cabe en la definición de la tabla y simplemente debe almacenarse en otra tabla que la aplicación leerá y aplicará a sus columnas cuando presente datos al usuario y no de una manera malintencionada que no será portátil.

Por ejemplo, la idea de vista funciona, pero ¿puede consultar la vista fácilmente para obtener los formatos que se aplican a los campos? O digamos que desea cambiar el formato en todas las instancias del campo WWPN en todas las consultas que lo utilizan (la cadena de caracteres también suena como que ya está mal), ¿sería eso fácil? O si hay otras consultas que transforman los datos y los anotan en otra tabla, ¿los anotará con el formato aplicado o sin él (volver a analizar)? Etc ...

Ahora si has tenido una tabla que almacena los datos de configuración de la aplicación, como FieldFormatting: tabla, campo, formato, CheckRules, LongFormat (o lo que tiene más sentido en su situación) se convierten entonces en las preguntas anteriores es un poco más fácil de tratar y puede elegir opciones adicionales para su aplicación y lógica comercial.

Si realmente (realmente, realmente) tiene que proporcionar acceso directo a la base de datos y los tipos nativos harían los datos ilegibles para los usuarios y simplemente preformate, incluso podría usar la tabla anterior para generar y actualizar las vistas/consultas semiautomáticas

NOTA: Aquí considero un punto de vista purista ya que tengo la sensación de que está tomando decisiones de diseño aquí y no persiguiendo la última gota de rendimiento o conveniencia (por ejemplo, entre tipos de datos de aplicaciones y tipos de datos de bases de datos) los problemas pueden ser más importantes que las pautas y reglas de modelado. Pero las preguntas del último párrafo siguen en pie.