Discussion :

[frantzgac]

Bjr

il est fréquent qu'on souhaite donner des noms de champs explicites aux noms internes d'une base de données. Exemple, ID_CLI qui sera l'identificant client dans la BDD deviendra 'Numéro Client" dans l'IHM.

Je vois que la table RDB$FIELDS (FB) contient RDB$QUERY_NAME ou RDB$EDIT_STRING qui pourraient recevoir un descriptif explicite pouvant servir de noms de champs dans un IHM sauf s'ils ont un usage précis. Dans mes BDD ces champs sont vides.

Mais d'une part je ne crois pas que ce soit recommandé d'écrire directement dans les tables systèmes et d'autre part je me dis que la clause de création des champs d'une table contient peut être de quoi réaliser cela proprement.

Je n'ai rien trouvé de tel dans la doc.

[makowski]

mal cherché

lire les notes de version

COMMENT ON DATABASE IS {'txt'|NULL};
COMMENT ON <basic_type> name IS {'txt'|NULL};
COMMENT ON COLUMN tblviewname.fieldname IS {'txt'|NULL};
COMMENT ON PARAMETER procname.parname IS {'txt'|NULL};

pour une colone stocké dans RDB$RELATION_FIELDS.RDB$DESCRIPTION

[jose.ignacio.agata]

et que peut on faire de ces info ensuite ? requeter dessus ? ou cela est juste informatif ?

[makowski]

Les tables système sont des tables, donc on peut les interroger comme tout autre table

C'est ce que font des outils comme database workbench ou flamerobin

Donc on peut effectivement imaginer une interface graphique allant chercher des noms "civilisés" dans les tables systèmes pour générer l'interface utilisateur

le champ RDB$RELATION_FIELDS.RDB$DESCRIPTION est un blob sub type 1

[frantzgac]

Merci bien éminent membre Makowski !

Où se trouve donc ces notes de versions ?

J'ai tenté d'entrer directement la commande

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

COMMENT on column PRO_ACTEUR.NOM_ACT 'Nom'

mais ça répond

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
Engine Code    : 335544569
Engine Message :
Dynamic SQL Error
SQL error code = -104
Token unknown - line 1, char 0
COMMENT

[frantzgac]

Bon, encore moi. Finalement j'ai trouvé une Note de version qui cause de la clause COMMENT mais c'est celle de la version 2.1. J'en déduis que cela fait partie des nouveautés de la 2.1 et que cette clause n'existait pas avant.

Juste ?

[frantzgac]

Toujours moi.

Désolé les essais ont été faits sur un PC qui est encore sous IB pour des raisons de maintenance. Je confirme que ça marche aussi avec FB 1.5.

[jose.ignacio.agata]

bonjour à tous

en allant plus loin dans cette idée, on se demandait si on pouvait stocker une info utilisable ensuite dans notre soft.

Notre problème est qu'apparemment nous ne pouvons pas trier par la colonne rdb$description puisque c'est un blob. Alors peut on stocker une info simple dans la colonne rdb$edit_string qui est une string 125, donc triable.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
update RDB$RELATION_FIELDS 
   set  rdb$edit_string='parc_show_01' 
  where rdb$field_name='PARC_REF'

et ensuite

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
select  *  from RDB$RELATION_FIELDS
where RDB$edit_string starting 'parc_show'
order by RDB$edit_string

merci d'avance pour vos commentaires

[Barbibulle]

Sans vouloir tout remettre en cause, n'est il pas trop risqué de vouloir utiliser les colonnes des tables systèmes à des fins applicatives ?

Mettons que fb supprime ces colonnes ou décide de les utiliser différemment. Qu'adviendra t'il de votre application ?

Je serai à votre place je me créerai mes propres tables avec les infos dont j'ai besoin.

Vous n'aurez plus la contrainte de devoir cherchez des champs dans les tables systèmes et de vous limiter à ceux disponibles. Mettons que vous voulez associer à une de vos colonne en plus d'un nom, une petite image, il vous suffira d'ajouter un blob dans votre propre table.

Et cela aura l'avantage de moins vous lier aux évolutions de FB.

[jose.ignacio.agata]

merci de l'avis - c'est ce que nous allons faire (créer une table dédiée)... mais c'était tentant !

[makowski]

les remarques sont justes, mais deux points de précision :

RDB$RELATION_FIELDS.RDB$DESCRIPTION peut être utilisé sans problème
quand à RDB$EDIT_STRING, il n'est pas utilisé par Firebird

[frantzgac]

Je rebondis sur cet échange car il m'évoque un léger trouble :

Si les tables systèmes sont exploitées par une clause SQL

comment on column

on peut supposer qu'une certaine pérennité est garantie dans les conséquences de cette clause.

Bien sur Firebird peut décider de ranger les infos de la clause

comment

dans une autre table auquel cas accéder directement à une table système constitue un risque.

D'où ma question : si on préfère ne pas accéder à des tables systèmes directement, existe t il des requêtes permettant de relire ces metadonnées, et rester indépendant des évolutions de FB ?

[Barbibulle]

Pas que je sache.

Et les tables systemes sont propres à chaque SGBD.

Donc les utiliser rend votre application moins facilement portable vers d'autres sgbd (ou même vers des versions majeures du même SGBD...).

Enfin comme je l'ai déjà dit votre développement sera dépendant du développement de FB. S'ils décident de supprimer des colonnes que vous utilisez dans les tables systems il ne vous demanderons pas votre avis.

Mais si ce risque est pour vous acceptable je vous conseille de créer des vues sur ces tables. Votre application devra utiliser uniquement ces vues (pour les lectures et mises à jours). Ainsi en cas de changement de la part de FB vous n'aurez qu'à changer ces vues (vers des tables que vous aurez crée ou un mixte) sans devoir changer votre application.

[frantzgac]

Oui, je suis bien d'accord sur l'indépendance vis à vis des versions. Un peu moins sur l'indépendance vis à vis des SGBD car le langage SQL n'est pas entièrement semblable d'un sgbd à l'autre (j'ai des tas de scripts Sybase qui ne fonctionne pas avec FB et il ne s'agit pas de TRANSAC SQL).

La clause COMMENT par exemple, est elle dans la dernière norme SQL ? J'avoue ne pas le savoir. Mais qu'elle soit ou non standard il est assez curieux qu'une clause prévoit de stocker des informations qu'on ne peut relire qu'en accédant à des tables systèmes. On peut imaginer que l'intention (non finalisée) des développeurs FB est précisément de fournir ce type de fonctionnalité dans des versions futures.

Ce qui est surprenant c'est que le DDL généré sur une table dont un champ a été commenté produit un UPDATE RDB$RELATION_FIELDS ... au lieu d'une clause COMMENT.

Il est vrai qu'il peut paraître curieux de vouloir utiliser les tables systèmes mais d'un autre coté pour ce genre de fonction, ce serait dommage de devoir réécrire dans une table 1/le nom des table, 2/le nom des champs, pour pouvoir les mettre en équivalence d'un nom plus civilisé. D'où le coté séduisant de la clause comment et son corollaire qui serait utile : une clause "GetComment on...."

[makowski]

Il y a un lieu pour déposer ce genre de proposition c'est le tracker :
http://tracker.firebirdsql.org/secure/Dashboard.jspa

Dans la norme sql (la 2008 en tout cas) il est prévu de pouvoir avoir des comments, et Oracle le fait d'ailleur aussi
mais rien n'est prévu à ma connaissance à part l'interrogation des tables système (et d'ailleurs ce n'est pas un problème, d'interroger les tables systèmes) pour retrouver l'info

[jose.ignacio.agata]

pour info, on utilise une nouvelle table pour gérer notre affichage tout en allant piocher dans les tables systemes les informations.

SELECT distinct b.rdb$field_name,affichage.*,b.rdb$field_name,a.RDB$FIELD_LENGTH,a.RDB$FIELD_type, b.rdb$default_source,b.rdb$field_name
FROM affichage ,RDB$FIELDS a , RDB$RELATION_FIELDS b
where b.RDB$FIELD_NAME = upper(AFFICHAGE_champs) and a.RDB$FIELD_NAME = b.RDB$FIELD_SOURCE
order by AFFICHAGE_ORDRE

A ce titre, le champs a.RDB$FIELD_type est très intéressant. Ou peut on trouver la signification des valeurs, même sil cela semble facile de les retrouver ?

[makowski]

7 smallint
8 integer
12 date
13 time
14 char
16 bigint
27 double precision
35 timestamp
37 varchar
261 blob