CREATE TABLE + COMPUTED BY

Bjr

la doc IB fait allusion à une clause COMPUTED BY dans la définition des champs d'une table. Le code suivant exécute via FlameRobin vers un serveur FB déclenche pourtant un erreur :

Code:

---

1 2 3 4 5

create table TEST ( A integer COMPUTED (select sum(B) from TEST), B integer not NULL );

---

Erreur :

Engine Code : 335544569
Engine Message :
Dynamic SQL Error
SQL error code = -104
Token unknown - line 4, char 4
select

c'est possible si :

Code:

---

COMPUTED BY ((SELECT ...))

---

mais franchement c'est suicidaire

:aie:

Citation:

---

Envoyé par makowski

c'est possible si :

Code:

---

COMPUTED BY ((SELECT ...))

---

mais franchement c'est suicidaire

---

Ah bon, et pourquoi ? Il ne s'agit pas de faire des calculs sur des milliers de lignes...

Enfin merci, je vais essayer.

En effet ça fonctionne, encore merci.

Je trouve que c'est une alternative élégante à la création d'un trigger qui fait un calcul dans l'évenement insert,update ou delete d'une table. L'inconvénient est que l'évaluation du champ calculé se fait même à la lecture mais le tout est d'être raisonnable quand au volume du calcul demandé.

Comme dit le proverbe "un couteau n'est ni vrai ni faux, mais celui qui l'empoigne par la lame est dans l'erreur":mouarf:

Si la table ne contiendra jamais plus de quelques enregistrements, pourquoi pas...

Mais de là à dire que c'est une manière élégante je ne suis pas d'accords :)

Personnellement je ne ferais pas comme ça, ma table ne contiendrait que la colonne B.

Car A n'apporte rien (il a la même valeur quelque soit la ligne lue) et surtout si un jour votre table contient beaucoup d'enregistrements une simple lecture deviendra vite catastrophique.

Il n'y a qu'à voir en remplissant avec seulement 1000 enregistrements si on veut lire cette table FB devra effecter 1000*1000+1000= 1 001 000 de lectures.

Plus d'un million de lecture !!!

Si vous ne voulez pas faire 2 requetes depuis le client (une pour le select sum(B) from test) et une pour le select B from Test, vous pouvez faire une procédure stoquée :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20

SET TERM ^ ;   CREATE PROCEDURE PS_TEST RETURNS ( A integer, B INTEGER) AS BEGIN select sum(b) from test into :a; FOR select b from test INTO :B DO BEGIN SUSPEND; END END^   SET TERM ; ^

---

un simple select A, B from PS_TEST; sera bien plus performant. (1000+1000=2000 lectures)

Ou autre solution créer une vue :

Code:

---

1 2 3 4 5

CREATE VIEW V_TEST( A) AS select sum(B) from TEST;

---

Puis un

Code:

---

1 2	select V.A, T.B from TEST T, V_TEST V;

---

Vous retournera le résultat. Avec les mêmes performances que la procédure stoquée.

PS : LA solution du trigger n'est pas terrible non plus car d'une celà vous oblique à stoquer le champ A et de deux à chaque Insert/update sur la table vous aller devoir mettre à jours TOUS les enregistrements de la table. Celà va donc faire baisser les perfs des inserts/updates et surtout sera une grosse contrainte en terme d'accès concurrentiels...

Barbibulle

Tout ça est vrai.

Toutefois l'exemple donné était assez trivial pour aller vite.

Il est certain qu'avec une formule du type sum(a) c'est un peu idiot car en effet on aura la même valeur dans toutes les lignes. Mais imaginez que la table soit celle des clients (Table T1) et que l'on souhaite obtenir le montant des factures (table T2) adressées à ces clients. Alors la formule sera un select sum (T2.montant) from T2 where T1.id_client = t2.id_client.

La CPU consommée est plus modeste, on fait l'économie d'un trigger (et d'une vue). La CPU est consommée quand on a besoin de lire et non quand on écrit dans T2.

Tout dépend de la fréquence relative des écritures et des lectures...:yaisse2:

Tout compte fait ça aurait été plus vite de nous donner cet exemple en 1er :)

Ça vous aurait épargné : " C'est du suicide" et mon laïus sur les vues et PS. :mrgreen:

mouais

la meilleure solution dans ce cas c'est la vue, pas le computed by