Noms de colonnes — gestion des en-têtes avec points et noms non compatibles SQL

Les CSV produits dans la réalité comportent rarement des noms de colonnes compatibles SQL. Les en-têtes peuvent contenir des points (fius.fiu_id), des espaces (Customer Email), des caractères unicode (café) ou commencer par un chiffre (2024_revenue). La façon dont une plateforme de données traite ces noms en dit long sur son modèle d'utilisation.

Cette page décrit l'approche de Scrydon Analytics (la séparation nom physique/nom d'affichage de style Foundry/Atlan) et la compare aux autres plateformes.

Ce que fait Scrydon

Lorsque vous téléversez un fichier avec un en-tête pointé comme fius.fiu_id, Scrydon l'ingère sans perte :

L'en-tête brut est conservé comme nom d'affichage dans le catalogue, sans jamais être perdu. Le nom physique est normalisé pour satisfaire les règles d'identifiant StarRocks, ce qui simplifie le SQL — pas de guillemets obligatoires dans chaque requête, pas de rupture inattendue dans les outils BI qui construisent des identifiants automatiquement.

Règles de normalisation

Appliquées une seule fois, lors de l'inférence du schéma :

• Tout caractère hors de [A-Za-z0-9_] devient _
• Un chiffre en tête reçoit un préfixe _
• Un résultat vide est remplacé par column
• Le résultat est tronqué à 128 caractères (limite des identifiants StarRocks)
• Dans une même table, les noms normalisés qui entrent en collision reçoivent un suffixe _2, _3, … dans l'ordre de la source

display_name n'est enregistré que lorsque la normalisation a modifié l'en-tête source, ou lorsque l'en-tête source était déjà compatible SQL mais a dû recevoir un suffixe pour éviter une collision.

Ce que vous écrivez en SQL

SELECT fius_fiu_id, fius_country, fius_annual_sar_volume
FROM compliance_authorities
WHERE fius_egmont_member = true;

L'interface de requête, les intégrations BI et les outils en aval opèrent tous sur fius_fiu_id. Le point n'apparaît que dans l'étiquette de l'interface. C'est la même convention que Foundry et Atlan utilisent depuis des années.

Ce qui se passe lors de l'écriture/ingestion

Les téléversements CSV envoient les lignes avec les en-têtes d'origine (fius.fiu_id). Le chemin d'écriture traduit automatiquement display_name → column_name avant la validation et le Stream Load, ce qui vous permet de continuer à téléverser des fichiers avec les en-têtes pointés sans avoir à renommer les colonnes dans le fichier source.

Comment les autres plateformes gèrent cela

L'industrie se regroupe essentiellement en trois camps :

• Normaliser et oublier (BigQuery, Databricks/Snowflake/Fabric par défaut) : peu coûteux, avec perte d'information, ergonomique en SQL — mais l'original est perdu à jamais.
• Citer et autoriser (correspondance de colonnes Databricks, identifiants entre guillemets Snowflake) : sans perte sur disque — mais chaque requête, outil BI et connecteur a besoin d'une logique de citation, ce qui génère une friction ergonomique importante.
• Séparation physique/affichage (Foundry, Atlan, Scrydon) : nom normalisé en SQL, original conservé comme métadonnées de catalogue, les étiquettes UI/BI affichent l'original. C'est la « bonne » réponse pour les plateformes de type catalogue — nous l'avons choisie pour les mêmes raisons que Foundry et Atlan.

Pourquoi la séparation physique/affichage

Concrètement :

1. Le re-téléversement du même fichier fonctionne. Déposez à nouveau le CSV, le chemin d'écriture résout les en-têtes pointés via display_name → column_name automatiquement. Vous n'avez pas à renommer les colonnes dans la source.
2. Les outils BI et le SQL embarqué restent simples. Un classeur Tableau, un notebook d'analyste ou un SELECT fius_fiu_id dans un workflow n'ont pas besoin de connaître le point.
3. Le catalogue est auditable. Quand une colonne a été renommée lors de l'ingestion, ce fait est interrogeable (display_name IS NOT NULL) — utile pour le triage opérationnel lorsque quelqu'un se demande pourquoi sa requête sur fius.fiu_id renvoie « la colonne n'existe pas ».
4. La migration entrante et sortante est symétrique. L'export vers CSV utilise le nom d'affichage ; les consommateurs récupèrent le fichier dans la forme qu'ils avaient envoyée.

Ce qui est normalisé en pratique

Deux en-têtes distincts qui se normalisent en la même chaîne reçoivent un suffixe dans l'ordre de la source — fius.fiu_id devient fius_fiu_id, et un fius_fiu_id ultérieur dans le même fichier devient fius_fiu_id_2. Le display_name des deux conserve l'original verbatim, de sorte que l'interface ne les confond jamais.

Limites

• Les identifiants StarRocks sont ASCII uniquement et limités à 128 caractères. Les en-têtes de plus de 128 caractères sont tronqués après la normalisation ; l'original complet est toujours conservé dans display_name.
• Quelques caractères (codes de contrôle, NUL) sont supprimés avec les autres. Si votre CSV utilise un caractère exotique que vous souhaitez spécifiquement conserver, exposez-le via description plutôt que d'espérer le trouver dans display_name.
• Les tables schema-first (où vous avez déclaré des colonnes explicitement) contournent la normalisation — les colonnes déclarées doivent être compatibles SQL au moment de la création de la table. La normalisation ne s'applique qu'aux chemins d'ingestion data-first.

Voir aussi

• Vue d'ensemble d'Analytics