Existe-t-il des types de données personnalisés?

MySQL prend-il en charge les types de données personnalisés? Par exemple, les codes postaux peuvent être stockés dans un varchar(10)champ, mais ils peuvent être compactés dans un int, avec des options pour les blancs, et un indicateur indiquant s'il s'agit d'un code postal à 5 ​​chiffres ou 5 + 4 chiffres.

Existe-t-il un moyen d'installer des types de données transparents pour de telles choses? En ce qui concerne l'application, ce serait un type chaîne, il y aurait simplement une troncature des données (avec ou sans avertissement), si l'application transmettait des données invalides.

Des fonctions personnalisées peuvent être utilisées (par exemple, il existe une fonction intégrée INET_ATONpour les adresses IPv4. Mais cela ne permet pas de telles choses zip LIKE '12345%'qui devraient être correctement indexées. Un support bien écrit pour les types de données personnalisés permettrait de marquer un type de données comme triable. Ainsi, le compact zip int, une fois trié, serait trié comme s'il s'agissait d'un zip varchar(10).

Cela permettrait à la colonne d'avoir une largeur fixe, cela permettrait de réduire le stockage variable de 6 ou 10 octets à 4 octets de largeur fixe.

Il existe plusieurs utilisations applicables

• Codes ZIP
• Adresses IPv6
• Champs d'horodatage personnalisés avec précision de niveau minute et capacité au-delà 2038avec moins d'utilisation de stockage que datetime, mais pas besoin de prendre en charge les dates avant l'année de mise en œuvre (par exemple, le min pourrait être 2007 s'il s'agit des dates les plus anciennes du système)
• Horodatages qui implémentent DST (qui ne semblent pas exister )
• L'état américain à deux lettres peut être stocké dans un seul octet
• les ENUMs longs peuvent être séparés en un type de données personnalisé afin que DESCRIBEla sortie ne soit pas aussi compliquée à regarder avec tout le wrapping.

Je m'attends à ce que les gestionnaires de types de données soient stockés de la même manière que les fonctions sont stockées.

Existe-t-il quelque chose de semblable à distance sur un moteur de base de données? J'utilise principalement MySQL, mais je suis curieux de savoir si cela a déjà été implémenté, à moins de faire en sorte que l'application appelle une fonction comme la INET_ATONfonction.

MS SQL semble avoir quelque chose de cette nature , mais j'aimerais savoir si c'est plus qu'un simple synonyme. (par exemple booleanpourrait être un synonyme de tinyint(1), ou postal_codepour l'un charou varchar (5ou 9ou ou 10)) Les synonymes ne sont pas ce que je demande ici.

MySQL prend-il en charge les types de données personnalisés?

Réponse simple: non

Existe-t-il quelque chose de semblable à distance sur un moteur de base de données? J'utilise principalement MySQL, mais je suis curieux de savoir si cela a déjà été implémenté, à moins de faire appeler l'application une fonction comme la fonction INET_ATON.

Oracle a CREATE TYPEqui est analogue dans une certaine mesure à une classe OO, y compris des fonctionnalités telles que les fonctions membres et l' héritage

Postgres a CREATE TYPEun peu moins les classes OO (pas de fonctions membres ou d'héritage) mais est incroyablement flexible et utile, vous permettant même de créer de nouveaux types de base. Il y a aussi CREATE DOMAINqui permet une forme d'héritage ou de sous-typage et étend essentiellement un type de base avec quelques contraintes. Postgres a également quelques types de base intéressants par défaut, par exemple les types inet et géométriques . Dans Postgres, on peut écrire une extension en C pour un type de données personnalisé, comme dans cet exemple ici avec le type de données base36 .

SQL Server a CREATE TYPEqui vous permet de créer un type de données personnalisé basé sur un type de données système existant. Par exemple, je pourrais créer un type appelé SSNqui est fondamentalement défini comme VARCHAR(11)mais de cette façon, je n'ai pas à me souvenir de la taille d'un champ.

Firebird a également sa solution via des domaines .

Dans Firebird, le concept de «type de données défini par l'utilisateur» est implémenté sous la forme du domaine. Bien sûr, la création d'un domaine ne crée pas vraiment un nouveau type de données. Un domaine fournit les moyens d'encapsuler un type de données existant avec un ensemble d'attributs et de rendre cette «capsule» disponible pour une utilisation multiple dans l'ensemble de la base de données. Si plusieurs tables nécessitent des colonnes définies avec des attributs identiques ou presque identiques, un domaine est logique.

L'utilisation du domaine n'est pas limitée aux définitions de colonnes pour les tables et les vues. Les domaines peuvent être utilisés pour déclarer des paramètres et des variables d'entrée et de sortie dans le code PSQL.