Utilisation des Array

Version imprimable

1 pièce(s) jointe(s)

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:

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

Citation:

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

Pièce jointe 645697

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:

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

26/10/2023, 11h50
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?
26/10/2023, 12h19
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
26/10/2023, 13h50
qi130

1 pièce(s) jointe(s)

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)
Pièce jointe 645766

"Array" pourrait même intégrer la couleur : Cle_couleur PK-FK et assurer du 3D, non ?
26/10/2023, 14h05
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)

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:

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:

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 ?

26/10/2023, 15h44
SergioMaster

Citation:

Envoyé par alanglet

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

Citation:

Envoyé par Firebird

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

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

Citation:

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

Citation:

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 :bravo:

Salut à tous.

Code:

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.

27/10/2023, 06h51
SergioMaster

Citation:

Envoyé par Artemus24

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.

Citation:

Envoyé par Artemus24

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 ?
27/10/2023, 10h39
alanglet
Bonjour,

Citation:

Envoyé par Artemus24

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:

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:

1 2 3 update JOB set LANGUAGE_REQ=null where JOB_CODE='CEO'
Par contre:
Code:

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:

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é
30/10/2023, 16h57
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é?
30/10/2023, 17h14
Artemus24

Citation:

Envoyé par alanglet

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:

Unsupported conversion to target type ARRAY
13/11/2023, 10h54
SergioMaster

1 pièce(s) jointe(s)

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

Pièce jointe 646477
13/11/2023, 10h59
Artemus24

Merci SergioMaster.

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

@+
13/11/2023, 11h12
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
13/11/2023, 11h32
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é.