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 ?