Discussion :

[SergioMaster]

Bonjour,

Je me suis toujours posé la question des ARRAYs et de leur utilisation.

Je me suis, enfin, décidé à tenter l'expérience en testant sur la base de données employee, la table JOB qui contient la colonne Language_REQ , un array [5] de VARCHAR dont je ne connais pas la taille
Avec Flamerobin, DBeaver pas moyen d'obtenir de valeurs.
Flamerobin (0.9.3) la structure détectée n'est pas la bonne

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE JOB
(
  JOB_CODE JOBCODE NOT NULL,
  JOB_GRADE JOBGRADE NOT NULL,
  JOB_COUNTRY COUNTRYNAME NOT NULL,
  JOB_TITLE VARCHAR(25) NOT NULL,
  MIN_SALARY SALARY NOT NULL,
  MAX_SALARY SALARY NOT NULL,
  JOB_REQUIREMENT BLOB SUB_TYPE 1,
  LANGUAGE_REQ VARCHAR(15),
  CONSTRAINT INTEG_10 PRIMARY KEY (JOB_CODE,JOB_GRADE,JOB_COUNTRY)
);

Avec DBeaver (23.2.0) la structure détectée est comme celle de Flamerobin avec un petit plus en allant sur l'onglet data on obtient le message

SQL Error [0A000]: Types.ARRAY: SQL type for this field is not yet supported.

cependant, avec Firedac et Delphi j'obtiens quelque chose de plus efficace



Ce qui me permet de me dire que tout n'est pas perdu, simplement que je n'ai pas le bon outil graphique (GUI) pour gérer les ARRAYs (de là à en faire un, il y a un pas que je n'oserai franchir).
Bien sûr, il me reste ISQL .

Questions :
Quelqu'un a-t-il déjà utilisé les arrays ?
J'ai tenté une recherche sur un des élements de la table i.e SELECT * FROM JOB WHERE Language_REQ[3]='French' sans succès alors que

Code :

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

SELECT * FROM JOB WHERE CAST(Language_REQ AS VARCHAR(125)) CONTAINING 'French'

fonctionne
* Note pourquoi 125, obtenu en deux fois, j'ai pansé d'abord à 15*5 à cause du varchar de Flamerobin

[qi130]

Bonjour Sergio,

Je ne sais pas à quoi fait référence le 125 de la dernière phrase...

Globalement, pour les arrays, ce doc https://www.ibexpert.net/ibe/pmwiki.php?n=Doc.Array énumère les inconvénients, et il y en a plus que les avantages...

Perso, je n'arrive pas à trouver l'utilité d'un tel datatype...
A 1 dimension, notamment pour la base employee, une table de relation permet à tout le moins d'éviter les redondances.
A 2 dimensions ... quel cas d'usage?

[SergioMaster]

Bonjour,

Pour ce qui est des dimensions, j'ai un exemple assez facile
prenons un article chaussure (je passe l'explication modèle/coloris) celui-ci peut avoir diverses pointures (en moyenne 12 ou 24 pouvant toutefois aller jusqu'à 32, voire plus)
Dans ma GPAO je m'arrête à 24. Dans ma structure, j'utilise des PT1,PT2....PT24 comme colonne et des QTCMDE1..QTCMDE24, QTLIV1...QTLIV24,QTFAC1..QTFAC24 pour les quantités
un array Integer [3,24] ne serait pas malvenu à la place (sauf qu'il n'existe aucune fonctions qui pourrait faire les sommes)

le 125 de la dernière phrase correspond à la taille totale du blob.

Merci d'avoir pointé le document IBExpert

[qi130]

Je pense que la table de relation peut marcher pour 2 dimensions :

Pour tenter de coller à ton exemple : (je ne garantis pas le bon sens des flèches)


"Array" pourrait même intégrer la couleur : Cle_couleur PK-FK et assurer du 3D, non ?

[SergioMaster]

Oui, c'était une solution possible, abandonnée, car peu facile à utiliser au sein des programmes (Grille de saisie par pointure)
C'est les solutions des ERPs "classiques" mais avec de telles redondances d'informations que cela en devient horrible.

En fait, je voulais surtout aborder un système de tags (proposé par exemple par PostgreSQL) pas revoir ma copie concernant mon ERP qui après plus de 22 ans de bon et loyaux services va être remplacé par justement un de ces ERP (solution SOLUNE)
Moi, je pars à la retraite, la solution reprise par un intervenant Delphi n'ayant pas été retenue, l'entreprise va certainement devoir pas mal changer ses habitudes mais bon ...

J'envisageais que les tags puissent être dans un tableau, mais AMHA un blob et quelques fonctions feront aussi bien le job. Dommage quand même que rien ne soit envisagé en ce sens (du moins à ma connaissance) pour les nouvelles versions de Firebird (V5 en Bêta ou même V6)

[alanglet]

Bonjour,

L'utilisation du type array n'est pas encouragée. En tête du chapitre 3.8 Array types de la doc de référence de FB4 figure la mention:

Code :

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

1
2
3
4
5
Note
Firebird does not offer much in the way of language or tools for working
with the contents of arrays, and there are no plans to improve this.
This limits the usefulness and accessibility of array types.
Therefore, the general advice is: do not use arrays.

Juste pour essayer, j'arrive bien à lire ces tableaux comme dans l'exemple suivant:

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
select JOB_CODE
  ,JOB_GRADE
  ,JOB_COUNTRY
  ,JOB_TITLE
  ,MIN_SALARY
  ,MAX_SALARY
  ,JOB_REQUIREMENT
  ,LANGUAGE_REQ[1] as "LANGUAGE_REQ[1]"
  ,LANGUAGE_REQ[2] as "LANGUAGE_REQ[2]"
  ,LANGUAGE_REQ[3] as "LANGUAGE_REQ[3]"
  ,LANGUAGE_REQ[4] as "LANGUAGE_REQ[4]"
  ,LANGUAGE_REQ[5] as "LANGUAGE_REQ[5]"
  ,char_length(LANGUAGE_REQ[3])
from JOB
where LANGUAGE_REQ[3] starting with 'French'

Mais je n'ai trouvé nulle part la syntaxe pour les écrire dans un update ou un insert. Comme, si j'ai bien compris, un ARRAY est stocké dans un champ de type BLOB spécial, il n'y a pas de moyen simple par SQL, comme avec les blob de sous-type Text. Je sais le faire avec Lazarus pour le sous-type binaire, mais pas dans ce type spécial ?

André
PS: Firedac commet une erreur en donnant comme nom de champ LANGUAGE_REQ[0] car par défaut le tableau commence à l'index 1.
Autre curiosité, char_length(LANGUAGE_REQ[3]) retourne un longueur de 7 caractères pour French qui pourtant n'en fait que 6 ?

[SergioMaster]

Autre curiosité, char_length(LANGUAGE_REQ[3]) retourne une longueur de 7 caractères pour French qui pourtant n'en fait que 6 ?

Oui, j'ai remarqué qu'en fait, il y avait une fin de ligne supplémentaire

L'utilisation du type array n'est pas encouragée.

tout ça parce qu'il manque les IBPP nécessaires

PS: Firedac commet une erreur en donnant comme nom de champ LANGUAGE_REQ[0] car par défaut le tableau commence à l'index 1.

c'est vrai qu'il y a une sorte de confusion mais ce n'est qu'un nom de champ (peut-être à signaler à qui de droit niveau Embarcadero, je verrai), de plus, comme tu l'indiques, il s'agit de la base par défaut si tu déclares ARRAY [0..4] la base sera bien une base 0 et non 1.
Mais effectivement ISQL donne cette structure

SQL> show table JOB;
JOB_CODE (JOBCODE) VARCHAR(5) Not Null
CHECK (VALUE > '99999')
JOB_GRADE (JOBGRADE) SMALLINT Not Null
CHECK (VALUE BETWEEN 0 AND 6)
JOB_COUNTRY (COUNTRYNAME) VARCHAR(15) Not Null
JOB_TITLE VARCHAR(25) Not Null
MIN_SALARY (SALARY) NUMERIC(10, 2) Not Null DEFAULT 0
CHECK (VALUE > 0)
MAX_SALARY (SALARY) NUMERIC(10, 2) Not Null DEFAULT 0
CHECK (VALUE > 0)
JOB_REQUIREMENT BLOB segment 400, subtype TEXT Nullable
LANGUAGE_REQ ARRAY OF [5]
VARCHAR(15) Nullable
CONSTRAINT INTEG_11:
Foreign key (JOB_COUNTRY) References COUNTRY (COUNTRY)
CONSTRAINT INTEG_10:
Primary key (JOB_CODE, JOB_GRADE, JOB_COUNTRY)
CONSTRAINT INTEG_12:
CHECK (min_salary < max_salary)

Donc base 1 et non 0.
Reste qu'il est assez incompréhensible qu'un blob de 5*15 varchar nécessite d'être casté en un VARCHAR(125)


PS. Je n'avais pas pensé au STARTING WITH pour la requête

[Artemus24]

Salut à tous.

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
select language_req,
       language_req[1],
       language_req[2],
       language_req[3],
       language_req[4],
       language_req[5]
  from job;
 
     LANGUAGE_REQ LANGUAGE_REQ    LANGUAGE_REQ    LANGUAGE_REQ    LANGUAGE_REQ    LANGUAGE_REQ
================= =============== =============== =============== =============== ===============
           <null> <null>          <null>          <null>          <null>          <null>
           <null> <null>          <null>          <null>          <null>          <null>
           <null> <null>          <null>          <null>          <null>          <null>
           <null> <null>          <null>          <null>          <null>          <null>
           <null> <null>          <null>          <null>          <null>          <null>
           <null> <null>          <null>          <null>          <null>          <null>
           <null> <null>          <null>          <null>          <null>          <null>
           <null> <null>          <null>          <null>          <null>          <null>
           <null> <null>          <null>          <null>          <null>          <null>
           <null> <null>          <null>          <null>          <null>          <null>
           <null> <null>          <null>          <null>          <null>          <null>
           <null> <null>          <null>          <null>          <null>          <null>
           <null> <null>          <null>          <null>          <null>          <null>
           <null> <null>          <null>          <null>          <null>          <null>
           <null> <null>          <null>          <null>          <null>          <null>
           <null> <null>          <null>          <null>          <null>          <null>
           81:1e0 Japanese
       Mandarin
       English
 
 
 
           <null> <null>          <null>          <null>          <null>          <null>
           81:1e1 English
        German
         French
 
 
 
           <null> <null>          <null>          <null>          <null>          <null>
 
     LANGUAGE_REQ LANGUAGE_REQ    LANGUAGE_REQ    LANGUAGE_REQ    LANGUAGE_REQ    LANGUAGE_REQ
================= =============== =============== =============== =============== ===============
           <null> <null>          <null>          <null>          <null>          <null>
           <null> <null>          <null>          <null>          <null>          <null>
           <null> <null>          <null>          <null>          <null>          <null>
           81:1e2 English
        German
         French
 
 
 
           81:1e3 English
        Spanish
 
 
 
 
           81:1e4 English
        German
         French
 
 
 
           81:1e5 English
        French
 
 
 
 
           81:1e6 German
         French
         English
        Italian
 
 
           81:1e7 Japanese
       English
 
 
 
 
           81:1e8 Italian
        German
         French
 
 
 
           81:1e9 English
        French
         Spanish
 
 
 
 
 
exit;
 
Appuyez sur une touche pour continuer...

Les libellés sont les suivants :
--> Japanese
--> Mandarin
--> English
--> German
--> French
--> Spanish
--> Italian

Il y a une marque de fin de chaîne de caractères qui fait passer à la ligne suivante.

Les Array sont destinés à la lecture uniquement d'après ce que j'ai pu comprendre.

Je ne vois pas trop l'intérêt de faire l'usage des Array. C'est contraire aux règles des bases de données où il faut éviter de la redondance d'information. Le mieux est de créer une table avec ces libellés et d'y pointer une clef étrangère.

[SergioMaster]

Je ne vois pas trop l'intérêt de faire l'usage des Array. C'est contraire aux règles des bases de données où il faut éviter de la redondance d'information. Le mieux est de créer une table avec ces libellés et d'y pointer une clef étrangère.

Encore une fois, il ne s'agit pas de savoir si c'est contraire ou non aux règles des bases de données (régles qui peuvent évoluer). Justement, cela aurait été, dans l'exemple cité pour les articles chaussant, un moyen d'éviter une table, mais surtout des complications pour l'interrogation des données (toujours cette grille de pointure plus facile à lire horizontalement que verticalement).

De toute façon, là n'est pas ma "voie". J'envisageai l'array comme piste pour la simulation d'un nuage de tags (une manière faignante, AMHA, pour ne pas utiliser un ensemble de tables simples, nommées et permettant des contrôles), en y réfléchissant, de toute manière, un array est limité a contrario d'un simple blob.

Les Array sont destinés à la lecture uniquement d'après ce que j'ai pu comprendre.

C'est une chose que je n'ai pas encore vérifiée. C'est probablement le cas avec ISQL et la plupart des GUI mais, par programmation c'est une chose que je tenterai ?

[alanglet]

Bonjour,

Il y a une marque de fin de chaîne de caractères qui fait passer à la ligne suivante.

Les Array sont destinés à la lecture uniquement d'après ce que j'ai pu comprendre.

Je ne vois vraiment pas à quoi ça pourrait servir s'il était impossible d'y écrire.
D'ailleurs la copie depuis un autre enregistrement et la suppression fonctionnent:

Code :

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

1
2
3
update JOB
set LANGUAGE_REQ=(select LANGUAGE_REQ from JOB where JOB_CODE='SRep' and JOB_COUNTRY='Switzerland')
where JOB_CODE='CEO'

Code :

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

1
2
3
update JOB
set LANGUAGE_REQ=null
where JOB_CODE='CEO'

Par contre:

Code :

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

1
2
3
update JOB
set LANGUAGE_REQ=('French''English''German''Spanish''Italian')
where JOB_CODE='CEO'

passe bien la phase de préparation mais provoque une erreur lors de l'exécution:

Code :

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

1
2
3
Unsupported conversion to target type ARRAY
Overflow occurred during data type conversion.
GDS Code: 335544861 - SQL Code: -413 - Error Code: 541

et je n'ai pas trouvé quel séparateur est autorisé.

André

[qi130]

Concernant le BLOB, j'ai lu qq part que FB tentait de le mémoriser dans la page "courante", améliorant du coup la perf à la lecture.

Mais sur les petites tailles de page la probabilité de place libre dans la page n'est pas toujours favorable... c'est encore moins favorable en cas de réécriture avec des données plus encombrantes.
On peut imaginer que ce BLOB dédié ARRAY a une taille incompressible contenant l'adresse de la page contenant effectivement les datas d'une array.

MySQL met en oeuvre un truc un peu similaire pour les colonnes TEXT qui sont stockées off page (off page storage) à une adresse occupant 20 octets dans la ligne de concernée (dans la table).

@Sergio: as-tu tenté une array de 6 (au lieu de 5) pour constater la taille du BLOB associé?

[Artemus24]

Je ne vois vraiment pas à quoi ça pourrait servir s'il était impossible d'y écrire.

Tu peux construire le tableau en le plaçant dans la colonne, mais pour modifier un élément, il faut réinstaller la totalité du tableau.
N'est-ce pas ce que tu fais déjà en modifiant une colonne de n'importe quel type ?

Je n'ai pas trouvé la fonction (si elle existe) qui puisse insérer un élément dans le tableau.
J'ai cherché mais je n'ai pas trouvé la structure de ce Array.

Comme toi, Alanglet, j'ai obtenu l'erreur :

Code :

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

Unsupported conversion to target type ARRAY

[SergioMaster]

Juste pour info, voilà comment se compose le contenu d'un array

[Artemus24]

Merci SergioMaster.

As tu trouvé des fonctions de manipulations de ces ARRAY ?

@+

[SergioMaster]

Firebird non.
Via une fonction firebird : à étudier
Via une UDF : je n'ai pas regardé si cela existait dans FreeAdhoc, sinon, une de mon cru avec Delphi ou C++ avec cette structure cela va être "coton", un iteme de plus dans ma TODO LIST mais avec une priorité faible

[Artemus24]

Si pas de fonctions, les Array ne sont pas très utiles en l'état.

Je préfère de loin ne pas les utiliser car contraire aux règles de normalisation. C'est contraire à la première règle : "tout attribut contient une valeur atomique".

En dehors des normalisations, je ne vois pas son utilisé.