Discussion :

[chekkal]

Bonjour à tous,

j'ai une base de données volumineuse qui contient des données techniques de type de véhicule (motorisation, puissance, carburant...ect) et au fur et à mesure on la renseigne avec de données supplémentaire. Mon souci c'est que la base de données contient actuellement plus de 250 000 ligne(enregistrement) et par exple si je veut consulter des données en utilisant par exple le code

Code :

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

select * from BASES where (dat='01/02/2017')

la recherche est vraiment lente.

[SergioMaster]

Bonjour,

dat est elle une colonne indexée ? c'est la première chose à faire.

P.S. heureusement que le SQL n'est qu'un exemple car il est loin d'être parfait dat='01/02/2017' si pour vous il s'agit du 01 février 2017 Perdu !
un petit rappel https://firebirdsql.org/en/firebird-date-literals/
et un CAST('01/01/2017' as DATE) ne fera pas de mal

[Artemus24]

Salut à tous.

j'ai une base de données volumineuse

Volumineuse est une idée subjective.

Mon souci c'est que la base de données contient actuellement plus de 250 000 ligne

Vous appelez cela une base de données volumineuse ? Non, c'est une toute petite volumérie !

Code :

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

select * from BASES where (dat='01/02/2017')

Quelles remarques concerant votre requêtes :

1) on ne fait l'usage de l'étoile ("*") que pour des tests.
Normalement, on extrait uniquement les colonnes dont on a véritablement besoin.

2) quel est le type de la colonne "dat" ?
A priori, je pense que vous avez choisi de mettre du "varchar()".
C'est une erreur car il existe déjà un type, fait pour y mettre des dates. C'est tout simplement le type "date".

3) le format de votre date n'est pas correcte. Il faut écrire "YYYY-MM-DD".
Ne pas confondre le stockage de la date avec sa réprentation à l'affichage.

4) avez-vous mis un index sur la colonne "dat" ?
Pour des raisons de performances, il vaut mieux ne pas balayer la totalité de la table mais se rendre directement aux lignes contenant cette information.

5) la conversion de la date dans le bon format doit se faire à l'extérieur de la requête, c'est-à-dire dans le programme et non dans la requête elle-même.

6) qu'est-ce que vous appelez une "recherche lente" ? C'est plus de 1 seconde, 15 secondes, 1 minute, 30 minutes ? Au delà ?

Un problème peut souvent en cacher un autre !

Voici un petit exemple avec des statistiques :

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
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
172
173
174
175
176
177
178
179
180
181
182
183
184
185
186
187
188
189
190
191
192
193
194
195
196
197
198
199
200
201
202
203
204
205
206
207
208
209
210
211
CREATE DATABASE '..\Data\Base.fdb' page_size 4096 DEFAULT CHARACTER SET WIN1252;

-- ===========================
-- Création de la table 'test'
-- ===========================

create table test (
  id   integer generated by default as identity not null primary key,
  dat  date                                     not null
);

-- =========================
-- Création Index sur 'test'
-- =========================

create index idx on test (dat);

-- =====================
-- Insertion dans 'test'
-- =====================

insert into test (dat) values ('2017-12-01');
insert into test (dat) values ('2017-12-02');
insert into test (dat) values ('2017-12-03');
insert into test (dat) values ('2017-12-04');
insert into test (dat) values ('2017-12-05');
insert into test (dat) values ('2017-12-06');
insert into test (dat) values ('2017-12-07');
insert into test (dat) values ('2017-12-08');
insert into test (dat) values ('2017-12-09');
insert into test (dat) values ('2017-12-10');
insert into test (dat) values ('2017-12-01');
insert into test (dat) values ('2017-12-02');
insert into test (dat) values ('2017-12-03');
insert into test (dat) values ('2017-12-04');
insert into test (dat) values ('2017-12-05');
insert into test (dat) values ('2017-12-06');
insert into test (dat) values ('2017-12-07');
insert into test (dat) values ('2017-12-08');
insert into test (dat) values ('2017-12-09');
insert into test (dat) values ('2017-12-10');
insert into test (dat) values ('2017-12-01');
insert into test (dat) values ('2017-12-02');
insert into test (dat) values ('2017-12-03');
insert into test (dat) values ('2017-12-04');
insert into test (dat) values ('2017-12-05');
insert into test (dat) values ('2017-12-06');
insert into test (dat) values ('2017-12-07');
insert into test (dat) values ('2017-12-08');
insert into test (dat) values ('2017-12-09');
insert into test (dat) values ('2017-12-10');

-- ================
-- Vidage de 'test'
-- ================

select * from test;

          ID         DAT
============ ===========
           1 2017-12-01
           2 2017-12-02
           3 2017-12-03
           4 2017-12-04
           5 2017-12-05
           6 2017-12-06
           7 2017-12-07
           8 2017-12-08
           9 2017-12-09
          10 2017-12-10
          11 2017-12-01
          12 2017-12-02
          13 2017-12-03
          14 2017-12-04
          15 2017-12-05
          16 2017-12-06
          17 2017-12-07
          18 2017-12-08
          19 2017-12-09
          20 2017-12-10

          ID         DAT
============ ===========
          21 2017-12-01
          22 2017-12-02
          23 2017-12-03
          24 2017-12-04
          25 2017-12-05
          26 2017-12-06
          27 2017-12-07
          28 2017-12-08
          29 2017-12-09
          30 2017-12-10


commit;

-- ===========
-- Requête N°1
-- ===========

set stats on;

select * from test where dat = '2017-12-03';

          ID         DAT
============ ===========
           3 2017-12-03
          13 2017-12-03
          23 2017-12-03

Current memory = 12254232
Delta memory = 24312
Max memory = 12316640
Elapsed time= 0.007 sec
Buffers = 2048
Reads = 0
Writes = 2
Fetches = 12

-- ====
-- Show
-- ====

Show table   test;
ID                              INTEGER Not Null Identity (by default)
DAT                             DATE Not Null
CONSTRAINT INTEG_1:
  Primary key (ID)
Show Indexes test;
IDX INDEX ON TEST(DAT)
RDB$PRIMARY1 UNIQUE INDEX ON TEST(ID)

set stats off;

exit;

Database "E:\23.FIREBIRD\99.EXERCICES\DATA\BASE.FDB"
Database header page information:
        Flags                   0
        Generation              13
        System Change Number    0
        Page size               4096
        ODS version             12.0
        Oldest transaction      6
        Oldest active           7
        Oldest snapshot         7
        Next transaction        10
        Sequence number         0
        Next attachment ID      3
        Implementation          HW=AMD/Intel/x64 little-endian OS=Windows CC=MSVC
        Shadow count            0
        Page buffers            0
        Next header page        0
        Database dialect        3
        Creation date           Dec 9, 2017 19:08:32
        Attributes              force write

    Variable header data:
        *END*


Database file sequence:
File E:\23.FIREBIRD\99.EXERCICES\DATA\BASE.FDB is the only file

Analyzing database pages ...
TEST (128)
    Primary pointer page: 224, Index root page: 225
    Total formats: 1, used formats: 1
    Average record length: 13.00, total records: 30
    Average version length: 0.00, total versions: 0, max versions: 0
    Average fragment length: 0.00, total fragments: 0, max fragments: 0
    Average unpacked length: 12.00, compression ratio: 0.92
    Pointer pages: 1, data page slots: 1
    Data pages: 1, average fill: 22%
    Primary pages: 1, secondary pages: 0, swept pages: 0
    Empty pages: 0, full pages: 0
    Fill distribution:
         0 - 19% = 0
        20 - 39% = 1
        40 - 59% = 0
        60 - 79% = 0
        80 - 99% = 0

    Index IDX (1)
        Root page: 230, depth: 1, leaf buckets: 1, nodes: 30
        Average node length: 3.47, total dup: 20, max dup: 2
        Average key length: 2.43, compression ratio: 1.64
        Average prefix length: 3.57, average data length: 0.43
        Clustering factor: 1, ratio: 0.03
        Fill distribution:
             0 - 19% = 1
            20 - 39% = 0
            40 - 59% = 0
            60 - 79% = 0
            80 - 99% = 0

    Index RDB$PRIMARY1 (0)
        Root page: 229, depth: 1, leaf buckets: 1, nodes: 30
        Average node length: 4.07, total dup: 0, max dup: 0
        Average key length: 3.00, compression ratio: 0.66
        Average prefix length: 0.93, average data length: 1.03
        Clustering factor: 1, ratio: 0.03
        Fill distribution:
             0 - 19% = 1
            20 - 39% = 0
            40 - 59% = 0
            60 - 79% = 0
            80 - 99% = 0

Appuyez sur une touche pour continuer...

J'ai mis en rouge le temps elsaps de la requête.

@+

[chekkal]

P.S. heureusement que le SQL n'est qu'un exemple car il est loin d'être parfait dat='01/02/2017' si pour vous il s'agit du 01 février 2017 Perdu !

Non, j'ai pas besoin de faire le "cast" parce que pour moi '01/02/2017'=02 Janvier 2017

on ne fait l'usage de l'étoile ("*") que pour des tests.
Normalement, on extrait uniquement les colonnes dont on a véritablement besoin.

si j'ai fait * c'est que j'ai besoin de voir tous les champs.

quel est le type de la colonne "dat" ?
A priori, je pense que vous avez choisi de mettre du "varchar()".
C'est une erreur car il existe déjà un type, fait pour y mettre des dates. C'est tout simplement le type "date".

non "dat" est un champs date.

3) le format de votre date n'est pas correcte. Il faut écrire "YYYY-MM-DD".
Ne pas confondre le stockage de la date avec sa réprentation à l'affichage.

C'est faut, il faut seulement inverser le mois et jour.

4) avez-vous mis un index sur la colonne "dat" ?
Pour des raisons de performances, il vaut mieux ne pas balayer la totalité de la table mais se rendre directement aux lignes contenant cette information.

le Champs "DAT" fait partie de la clé primaire et je fait seulement un "select" maintenant pour le balayage c'est là la question?

5) la conversion de la date dans le bon format doit se faire à l'extérieur de la requête, c'est-à-dire dans le programme et non dans la requête elle-même.

j'ai pas besoin de convertir la date.

6) qu'est-ce que vous appelez une "recherche lente" ? C'est plus de 1 seconde, 15 secondes, 1 minute, 30 minutes ? Au delà ?

4 à 6 seconde, mais pour un code qui est utilisée 1000 fois par jour en moyenne ça fait beaucoup.

[SergioMaster]

Bonjour

Non, j'ai pas besoin de faire le "cast" parce que pour moi '01/02/2017'=02 Janvier 2017

Pour vous ok, mais nous ne sommes pas devant vous ni dans votre tête donc sans informations idoines ... pour preuve Artemus24 craint que vous ayez carrément utilisé un type VARCHAR pour votre colonne date (point 2).

Persuadé que vous aviez de bonnes habitudes j'ai pensé que vous traitiez les dates comme des colonnes de type DATE et pas comme une chaine de caractères formatée ce qui est vraiment pas une bonne idée dans une table! Pour ce qui est du point 3 d'Artemus24, pour moi, tout d'abord il n'y a pas de bon format sans bon type, ensuite quand on utilise une constante date pour une recherche à partir du moment où vous utilisez une des formes définies par Firebird, cf lien déjà indiqué, il s'agit d'un choix purement personnel qui peut devenir embarrassant dans le futur en maintenance d'application.,

d'autre part si j'ai indiqué que le CAST ne fait pas de mal je n'ai nullement indiqué un caractère obligatoire, dans ma vision il s'agit plutôt d'une pratique garde-fou
par exemple à cause du DIALECT de la BDD, de la différence entre TIMESTAMP et DATE je préfère être très explicite (comme pour le point suivant) pour mâcher le travail de Firebird

c'est que j'ai besoin de voir tous les champs.

C'est vous qui voyez, cela ne coûte pas grand chose de faire l'effort de mettre le nom de toutes les colonnes souhaitées (encore une bonne habitude à prendre à mon avis)

[EDIT]
à priori la réponse n'était pas finie d'écrire quand j'ai commencé à écrire la mienne

je reviens sur le point :

le Champs "DAT" fait partie de la clé primaire

c'est le fait partie le problème ! faire un index sur la colonne n'a rien à voir avec une clé composée de plusieurs colonnes . Créez cet index et comparez ! à l'occasion vérifiez le PLAN de votre requête, avec l'index sur la colonne DAT c'est ce dernier qui devrait être utilisé.

en POST SCRIPTUM si cette requête est utilisé par programme (DELPHI) telle que vous la présentez, là ma réaction sera sans appel vous n'avez jamais entendu parler de requêtes paramétrées et de prepare ?

[chekkal]

C'est vrai que j'utilise pas d'index en dehors de la clé primaire pour la simple raison que si il ya un problème sur la base de données à cause par exemple des coupure de courant, la récupération des données est vraiment difficile. En plus la base de données devient encore plus volumineuse sur disque.

[SergioMaster]

si il ya un problème sur la base de données à cause par exemple des coupure de courant, la récupération des données est vraiment difficile. En plus la base de données devient encore plus volumineuse sur disque.

Deux arguments totalement non fondés, c'est de la mauvaise foi ou de la non connaissance au sujet de Firebird ?

[Artemus24]

Salut à tous.

si j'ai fait * c'est que j'ai besoin de voir tous les champs.

Imaginez un seul instant que vous ajoutez une nouvelle colonne, en plein milieu de celles déjà existante, dans votre table.
En faisant un "select *", vous aurez un décalage entre l'affectation de vos valeurs et vos colonnes correspondante.
C'est pourquoi, même si vous utilisez toutes les colonnes, vous devez les nommez explicitement dans le select.

non "dat" est un champs date.

C'est bien !

C'est faut, il faut seulement inverser le mois et jour.

Voici comment FireBird va interpréter votre date ?

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
CREATE DATABASE '..\Data\Base.fdb' page_size 4096 DEFAULT CHARACTER SET WIN1252;
 
-- ===========================
-- Création de la table 'test'
-- ===========================
 
create table test (
  id   integer generated by default as identity not null primary key,
  dat  date                                     not null
);
 
-- =====================
-- Insertion dans 'test'
-- =====================
 
insert into test (dat) values ('01/02/2017');
 
-- ================
-- Vidage de 'test'
-- ================
 
select * from test;
 
          ID         DAT
============ ===========
           1 2017-01-02
 
exit;
 
Appuyez sur une touche pour continuer...

Le 02 correspond au jour et le 01 au mois, donc la date se lit "02 janvier 2017". Alors que la date se lit "01 février 2017".

le Champs "DAT" fait partie de la clé primaire

Oui et alors ? Cela n'empêche pas de mettre votre colonne "dat" aussi dans un index qui lui sera entièrement dédié.

je fait seulement un "select" maintenant pour le balayage c'est là la question?

On vous l'a expliqué :
--> problème de conversion.
--> pas d'index sur la colonne "dat".

Voici le cas où vous n'utilisez pas d'index :

Code :

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

1
2
3
4
5
6
7
8
SET PLAN OFF;
SET PLANONLY ON;
 
select * from test where dat ='2017-02-01';
 
PLAN (TEST NATURAL)
 
exit;

Ce résultat indique que votre requête n'utilise aucun index. Le même test avec l'usage d'un index :

Code :

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

1
2
3
4
5
6
7
8
SET PLAN OFF;
SET PLANONLY ON;
 
select * from test where dat ='2017-02-01';
 
PLAN (TEST INDEX (IDX))
 
exit;

j'ai pas besoin de convertir la date.

Vous faites comme vous l'entendez, mais ne venez pas vous plaindre si vos résultats sont faux !

4 à 6 seconde, mais pour un code qui est utilisée 1000 fois par jour en moyenne ça fait beaucoup.

En terme de performance, une requête acceptable doit être inférieure à 1 seconde.

Maintenant, si vous ne désirez pas suivre nos conseils, on ne peut rien faire pour vous.

@+

[chekkal]

Deux arguments totalement non fondés, c'est de la mauvaise foi ou de la non connaissance au sujet de Firebird ?

croire que firebird est infaillible et résiste au coupure de courant répétitif là c'est de la mauvaise foi ou tout simplement manque de pratique sur le sujet.
Faite l'essai ouvrez une base de données, insérer des lignes et avant même validation couper le courant, répétez l’opération plusieurs fois et vous allez voir le message d'erreur .

Artemus, je crois que vous m'avez pas bien compris, si j'ai fait "selet * from base" c'est dont un but d'analyse de données seulement. Pour le champs "dat", il reçoit ça valeur par l'utilisateur dans le format normal "jj/mm/aaaa' et moi dans le programme je fait la conversion entre jour et mois .

[SergioMaster]

Bonjour,

croire que firebird est infaillible et résiste au coupure de courant répétitif là c'est de la mauvaise foi ou tout simplement manque de pratique sur le sujet.

Vous mettez en doute mes presque 15 ans d'expérience avec Firebird ? libre à vous, et malgré tout je peux vous donner quelque chose de pire qu'une coupure de courant (paliable avec un onduleur) un surchauffe de processeur, des parasites sur un réseau filaire mal protégé des surtensions etc...

Faite l'essai ouvrez une base de données, insérer des lignes et avant même validation couper le courant, répétez l’opération plusieurs fois et vous allez voir le message d'erreur .

Et vous croyez sans doute que cela m'est jamais arrivé ? bon de fait à mes débuts quelques fois avec des programmes mal conçus. J'ai depuis toujours prôné pour des requêtes courtes, rarement au dessus de une ligne à la fois.

A lire vos remarques, voici les miennes
1- J'ai comme l'impression que votre programme gére très mal les transactions
2- Savez vous qu'un backup (je ne parle même pas du restore) permet de vider la "poubelle"
3- Si votre Serveur a des problèmes, et si la base n'est pas utilisé H24 il est très facile de prévoir un petit shell qui :

• fait un shut down de la base
• fait un backup
• restart la base

nettoyant ainsi les transactions en Limbo.
4- j'ai l'impression que vous avez abordé Firebird comme un gestionnaire de table (Paradox, Dbase) sans passer à la vitesse supérieure. Ce qui me donne cette impression votre clé primaire composée et vos remarques sur les index. Une bonne structure de table aurait intégré une colonne NUMERIQUE 0 décimale ou BIGINT autoincrémentée et servant de clé primaire, et des INDEX un avec vos colonnes composées Unique , un autre avec votre colonne DAT etc...
5- savez vous que par SQL on peut désactiver/réactiver des index ?

Voici comment FireBird va interpréter votre date

Point délicat, en fait la date est stockée en numérique si ISQL formate la date sous la forme YYYY-MM-DD c'est je dirais plus pour "internationaliser" l'affichage écran. (en aparté je me demande si on ne peut pas modifier une option de ISQL pour avoir un affichage différent). Non , Firebird interprète les dates en numérique et détecte le format saisi dans le cas d'un SELECT dat FROM TABLE WHERE dat= un chaine en fait un CAST implicite est fait pour transformer cette chaine en date, en gros tous les formats possibles sont testés.

Pour le champs "dat", il reçoit ça valeur par l'utilisateur dans le format normal "jj/mm/aaaa' et moi dans le programme je fait la conversion entre jour et mois .

[Hors Sujet Firebird] j'adore (ironie) votre "format normal" on voit que vous n'avez pas à faire d'internationalisation de votre programme et quand je dit internationalisation cela ne veut pas forcément dire installer le programme dans plusieurs pays, j'ai eu à faire un programme d'hôtellerie où les utilisateurs venaient de plusieurs pays avec leur PC et leur "format normal" de date du coup, c'est quoi le format normal ? vous préférez changer la manière naturelle de saisie des utilisateurs ? [fin Hors Sujet]
et transformer la chaine saisie par l'utilisateur en date (StrToDate) avant puis passer cette dernière en paramètre de votre requête (je suis toujours persuadé qu'il s'agit de Delphi) ça ne vous est jamais venu à l'idée ? mais bon cela fait que la deuxième fois que je le dit

[chekkal]

J'ai depuis toujours prôné pour des requêtes courtes, rarement au dessus de une ligne à la fois.

Allons dans votre sens et prônons pour le sql et prenons un exple pratique. j'ai une table contenant les pièces de rechange de voiture classé par type de voiture. L'utilisateur veut ajouter des lignes tout en voyant les lignes déjà saisie sur un type de voiture, code sql

Code :

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

select champ1,champ2,....ect from BASE where typevoiture=valeur

. si j'utilise la méthode "insert " du sql je suis obligé de créer une fiche de réception des données et ensuite les affecter à la base de données par la méthode "insert" et ensuite rafraîchir la base de données pour pouvoir voir la nouvelle avec les lignes précédemment saisie. ouf ça fait beaucoup d'opérations pour un simple ajout de ligne. Par contre , moi j'utilise toujours "Tdbgrid" que je trouve formidable et cohérent et les données sont visible et les opérations sont fait et vue dans le DBGRID. Maintenant si le sql peut faire ça dans un tableau , je suis preneur.

[SergioMaster]

Re,
On dérive du sujet Firebird pour passer à de la programmation, donc hors sujet qui est : améliorer le temps de requête qui passera par un ajout d'index

si j'utilise la méthode "insert " du sql je suis obligé de créer une fiche de réception des données et ensuite les affecter à la base de données par la méthode "insert" et ensuite rafraîchir la base de données pour pouvoir voir la nouvelle avec les lignes précédemment saisie. ouf ça fait beaucoup d'opérations pour un simple ajout de ligne.

c'est votre vision des choses, pas forcément la mienne.
OUI je préfére passer par ce type de présentation
et OUI ,dans l'exemple indiqué je passe par des Inserts (pas forcément par une fiche supplémentaire) . D'ailleurs sachez que si vous utilisez les composants Table (BDE, Firedac ou ZEOSDBO comme connexion à la base de données je ne me prononcerai pas pour les autres) vous le faites également sans le savoir et si vous faites ce remplissage DBGrid par des Querys vous avez certainement un SQLUpdate quelque part. Mais contrairement à vous ma méthode permet de clôture les transactions dès l'opération (SELECT,UPDATE,DELETE,INSERT)
enfin, pour étayer, à partir du moment où vous utilisez deux fois un programme (même poste ou deux postes différents) avec des Grilles après une première mise à jour de l'un l'autre affiche des informations fausses

Que vous utilisiez des TDBGrids est discutable, surtout en environnement multi-utilisateurs, mais c'est votre choix et ce n'est pas dans le forum Firebird que je développerai davantage

[chekkal]

à partir du moment où vous utilisez deux fois un programme (même poste ou deux postes différents) avec des Grilles après une première mise à jour de l'un l'autre affiche des informations fausses

C'est là le mal entendu, Si l'application est en Réseau (multi-utilisateur), un utilisateur n'a pas besoin de voir ce que un autre utilisateur saisie. par contre en mode "ADMINISTRATEUR" la mise à jour et affichée seulement on faisant

Code :

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

 database.connected:=false;database.connected:=true;

[Artemus24]

Salut à tous.

Point délicat, en fait la date est stockée en numérique si ISQL formate la date sous la forme YYYY-MM-DD c'est je dirais plus pour "internationaliser" l'affichage écran.

Le seul seul bon format de date est "YYYY-MM-DD". Je dirais même plus, ce format est celui du stockage dans la base de données.
Il existe des SGBD qui font une distinction entre le stockage et l'affichage d'une date mais je crois que ce n'est pas le cas de FireBird.

Ce format (celui avec les /), d'après la documentation est interprété comme le format US, à savoir "MM/DD/CCYY" et non ce format "DD/MM/CCYY".
--> https://firebirdsql.org/en/firebird-date-literals/

Si chekkal désire conserver cette représentation (celle avec des "/") et que son format est "DD/MM/CCYY" il devra remplacer le "/" par un "." (le point).
C'est une astuce que la documentation FireBird préconise.

Je recommande plutôt de conserver la représentation internationale "CCYY-MM-DD" qui ne porte aucune ambiguïté auprès de FireBird.

(en aparté je me demande si on ne peut pas modifier une option de ISQL pour avoir un affichage différent).

Je pense qu'il n'existe pas d'option pour choisir le format à l'affichage de la date sous FireBird.
Je parle bien sûr, d'un paramètre qui serait générale à tout FireBird.
Le seul format au stockage et à l'affichage reste "CCYY-MM-DD" qui est la représentation internationnale.

Les autres formats reconnus sont des formats où FireBird va faire une conversion afin de stocker dans le format international.
--> https://firebird.developpez.com/faq/...ates-et-heures

Non , Firebird interprète les dates en numérique et détecte le format saisi dans le cas d'un SELECT dat FROM TABLE WHERE dat= un chaine en fait un CAST implicite est fait pour transformer cette chaine en date, en gros tous les formats possibles sont testés.

C'est ce que l'on nomme des conversions implicites. Et ils sont fréquemment une source d'erreur !
Les formats reconnus sont :
--> CCYY-MM-DD
--> YY-MM-DD
--> MM/DD/CCYY
--> MM/DD/YY
--> DD.MM.CCYY
--> DD.MM.YY

ou avec le mois sous forme de trois caractères (JAN,FEB,MAR,APR,MAY,JUN,JUL,AUG,SEP,OCT,NOV,DEC).
--> DD-MMM-CCYY
--> DD-MMM-YY
--> DD,MMM,CCYY
--> DD,MMM,YY
--> DD MMM CCYY
--> DD MMM YY
--> DDMMMCCYY
--> DDMMMYY

@+

[Artemus24]

Salut à tous.

ouf ça fait beaucoup d'opérations pour un simple ajout de ligne.

Vous n'avez jamais entendu parlé du mode transactionnel ?
Si votre ligne est bloquée, c'est qu'elle est en attente d'une validation (commit) ou d'un rejet (rollback).

Comme je n'utilise pas du delphi, j'ai du mal à vous suivre.
Et puis, comme l'indique SergioMaster, ce sont des problèmes de programmations qui sont hors sujet par rapport à votre problème de performance sous FireBird.

Maintenant si le sql peut faire ça dans un tableau , je suis preneur.

Ne me dites pas que vous stockez un tableau dans votre ligne ?

Vous enfreignez la première loi des formes normales qui consiste à éviter les répétitions dans la ligne.

@+

[SergioMaster]

Bonjour,
je répond d'abord au dernier message avant de revenir sur le format des dates

Et puis, comme l'indique SergioMaster, ce sont des problèmes de programmations qui sont hors sujet par rapport à votre problème de performance sous FireBird.

mais ne peux le faire pour le reste du message

Comme je n'utilise pas du delphi, j'ai du mal à vous suivre.
Ne me dites pas que vous stockez un tableau dans votre ligne ?

Non, Chekkal utilise plutôt tableau comme synonyme de la Grille (DBGrid)

Vous enfreignez la première loi des formes normales qui consiste à éviter les répétitions dans la ligne.

bien que ce soit une loi fondamentale, j'ai au moins un exemple sous le coude où j'utilise un amendement, il est fort dommage que , comme pour Interbase, les array soit prévus mais qu'aucune API n'y accède

Pour en revenir à la date

Le seul seul bon format de date est "YYYY-MM-DD". Je dirais même plus, ce format est celui du stockage dans la base de données.

non, lire https://firebirdsql.org/file/documen...-datetime.html

In storage, a date value or date-part of a timestamp is represented as the number of days elapsed since “date zero”—November 17, 1898—whilst a time value or the time-part of a timestamp is represented as the number of seconds (with fractions of seconds taken into account) since midnight.

c'est bien un numérique qui est stocké

Il existe des SGBD qui font une distinction entre le stockage et l'affichage d'une date mais je crois que ce n'est pas le cas de FireBird.

et si donc, c'est bien le cas . c'est d'ailleurs pour cette raison que je me posai la question en aparté pour savoir si l'on pouvait par directive, changer l'affichage ISQL comme je peux le faire avec Flamerobin en changeant les options d'affichage dans la grille de données. A bien noter , j'ai écrit affichage ce qui n'a rien à voir avec un SQL saisi

[SergioMaster]

Re,

C'est là le mal entendu, Si l'application est en Réseau (multi-utilisateur), un utilisateur n'a pas besoin de voir ce que un autre utilisateur saisie. par contre en mode "ADMINISTRATEUR" la mise à jour et affichée seulement on faisant

Code :

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

 database.connected:=false;database.connected:=true;

Dans mon monde réseau entreprise, les utilisateurs ont accès aux données (par exemple commandes clients) sans distinction d'utilisateur. Cela ne veut pas dire que chacun peut faire tout et n'importe quoi, ni même voir toutes les données de la table (d'où mon bannissement des SELECT *) les ROLES ont aussi leur mot à dire.
Je ne comprend pas trop votre mode 'ADMINISTRATEUR' est-ce à dire que chaque utilisateur n'a droit qu'à une tranche spécifique de données ?

Quant au code ... pourquoi faire simple quand on peut faire compliqué ? un simple close/open de la table ou requête fait la même chose !
pour revenir à Firebird, contrôlez vous les tables monitoring ? MON$ATTACHMENT et surtout MON$TRANSACTIONS en charge courante pour ma part j'ai 22 connexions au moment où j'écrit, à peine 10 transactions en cours (dont les miennes) soit 8 en réalité
sur ces connexions, j'en ai deux qui passent par Internet, le reste en local et celle qui me pose le plus de soucis sont celle avec le protocole WNET (vieux programmes Delphi utilisant encore le BDE)
Mais l'important est surtout de regarder, dans la liste des transactions, quelle est la transaction la plus "ancienne" (OLDEST_TRANSACTION,OLDEST_ACTIVETRANSACTION)

[chekkal]

Dans mon monde réseau entreprise, les utilisateurs ont accès aux données (par exemple commandes clients) sans distinction d'utilisateur. Cela ne veut pas dire que chacun peut faire tout et n'importe quoi, ni même voir toutes les données de la table (d'où mon bannissement des SELECT *) les ROLES ont aussi leur mot à dire.
Je ne comprend pas trop votre mode 'ADMINISTRATEUR' est-ce à dire que chaque utilisateur n'a droit qu'à une tranche spécifique de données ?

je m'explique par un cas pratique, j'ai une application vente caisse pour supérette installée en réseau sur 10 postes, et il ya 2 mode d'accée (administrateur accée à tout/ utilisateur accée seulement à la vente). Dans le cas utilisateur l’opérateur (caissier) à accée qu' au ventes (tickets) qu'il a effectué et n'a pas accée au ventes des autres opérateurs.

Quant au code ... pourquoi faire simple quand on peut faire compliqué ? un simple close/open de la table ou requête fait la même chose !

j'ai déjà essayé en fermant seulement la table mais ça marche pas c'est pour ça que je ferme et j'ouvre la base de données

[Artemus24]

Salut SergioMaster.

Non, Chekkal utilise plutôt tableau comme synonyme de la Grille (DBGrid)

Je ne connais pas DBGrid et je ne sais pas trop à quoi cela peut servir.

bien que ce soit une loi fondamentale, ...

Ce n'est pas pour rien que l'on a définit les formes normales.
Car une base de données est une représentation ensembliste des données qui y sont stockées.

Sinon, oui, on peut faire du n'importe quoi avec, mais à quoi cela sert d'utiliser une base de données, si c'est pour gérer cela comme un fichier plat ?
Sur ce point, je ne vous rejoins pas du tout !

... j'ai au moins un exemple sous le coude où j'utilise un amendement, il est fort dommage que , comme pour Interbase, les array soit prévus mais qu'aucune API n'y accède

Le problème du tableau est le nombre d'éléments qui est variable.
Ce qui pose le problème de la réservation de la place d'occupation de la capacité maximale de ce tableau.
Pour résoudre ce problème, dans le cas des fichiers plats, il existe un format d'enregistrement où la taille de celui-ci est variable.
Ce qui permet de stocker que la partie renseignée du tableau et d'ignorer la partie vide. Et de ce fait, on gagne de l'espace de stockage.

Dans le cas d'une base de données, on dédie ce rôle à une table pour cet usage particulier où le nombre d'éléments est variable.
De ce fait, il faut voir les lignes d'une table comme étant les éléments d'un tableau.

Je prends le cas particulier des numéros de téléphone que l'on peut attribuer à un client.
La clef primaire sera en fait une clef étrangère pointant sur la table client auquel on peut ajouter un incrément pour distinguer tous ces numéros de téléphone.
La table des téléphones contiendra autant de numéros de téléphones que ce client peut en posséder.
Même remarque aussi sur les adresses.
C'est en cela que sert la modélisation d'une base de données, à résoudre des problèmes de représentation.

Je rappelle que le créateur du langage Pascal, Niklaus Wirth, avait défini qu'un programme = traitement + données.
Et qu'il est à l'origine de la séparation des données d'avec les traitements.
Les données ne doivent pas être conditionnées par les traitements dont ils dépendent !

c'est bien un numérique qui est stocké

Oui, je suis d'accord avec vous, mais ce n'est pas de cela dont je parlais. Peut-être que je me suis mal exprimé, sur ce point.
Je sais très bien que l'on stocke les dates, sous forme d'un nombre de jours à partir d'une date pivot.

Quand je parle du format de stockage, je ne parle pas de la façon dont FireBird va stocker cette valeur.
Je parle du format de la date, à l'insertion, celle qui va être stockée, et qui ne doit poser aucune ambiguïté dans l'interprétation de FireBird et sera compréhensible partout dans le monde.
C'est pourquoi, le format international ("CCYY-MM-DD") est bien la représentation sans ambiguïté. Au fait, c'est une norme W3C !
--> https://www.w3.org/QA/Tips/iso-date
Donc, je ne mérite pas un '-1' pour m'avoir mal compris.

et si donc, c'est bien le cas.

Je veux bien vous croire, mais je n'ai rien trouvé de tel dans FireBird.
Je tiens aussi à souligner que ce n'est pas le rôle d'une base de données de faire de la présentation de données.
C'est le rôle d'un programme informatique de s'occuper de cela !

@+

[Artemus24]

Salut chekkal.

Dans le cas utilisateur l’opérateur (caissier) à accès qu'aux ventes (tickets) qu'il a effectué et n'a pas accès aux ventes des autres opérateurs.

J'ai encore du mal à vous comprendre. Pourtant, vous dites au début de votre message :

il y a 2 mode d'accès (administrateur accès à tout / utilisateur accès seulement à la vente).

Comme le caissier à les mêmes autorisations qu'un autre caissier, en toute logique, il peut voir toutes les ventes de tous les caissiers.
Alors que vous affirmez qu'un caissier donnée n'a accès qu'à ces propres ventes, ce qui dans ce cas là, est faux.

Sauf que dans votre approche, vous ne savez pas faire la distinction entre tel utilisateur et tel autre, puisqu'ils accèdent toujours avec les mêmes autorisations.

est-ce à dire que chaque utilisateur n'a droit qu'à une tranche spécifique de données ?

En principe oui, sauf que nous devons spécifier ce que l'on entend par "tranche".

D'une part, les autorisations définies verticalement seront celles données par les permissions du rôle.
Ce sont les colonnes auquelles l'utilisateur à le droit de consulter.
Sauf qu'avec cette approche, l'utilisateur peut aussi consulter les colonnes des autres utilisateurs.

D'autre part, il faut définir aussi des autorisations horizontales, celle de l'accès aux lignes.
L'utilisateur devra s'identifier et tous les accès se feront au travers de vues (VIEW).
C'est pourquoi, il faut interdire l'étoile dans le select et ne mettre que les colonnes autorisées.
Ajouter la clause "where" sur l'identifiant de l'utilisateur.

Si par contre, il n'existe pas d'identifiant, genre compte utilisateur sous windows (ou autre), vous devez le gérer au travers de votre application.
Faire par exemple, la saisie d'un matricule + mot de passe avant d'accéder à la base de données.
Mais ce genre de sécurité peut facilement se contourner par la connaissance du matricule et du mot de passe d'un autre utilisateur.

Autre remarque qui a son importance du point de vue de la sécurité.
L'administrateur est normalement le DBA et il a toutes les autorisations sur la base de données.
Seule une personne de confiance est autorisé à avoir accès en tant que DBA, et certainement pas quelqu'un qui est impliqué dans la gestion des caissiers.

Ce que vous nommez "administrateur" est en fait un super utilisateur avec des accès restreints, vis-à-vis du DBA, mais supérieur à celle de l'utilisateur de base.
Comme par exemple, il est interdit de supprimer la base de données, les tables, voire même interdire les suppressions de lignes, ou même venir les modifier, ...
Vue que vous gérer des caisses, il faut aussi enregistrement toutes les erreurs de saisie.
Une suppression, ou une modification, c'est une nouvelle ligne qui vient annuler la précédente.
De ce fait, cela laisse une trace d'une quelconque intervention et votre caissier devra se justifier sur le pourquoi de cette intervention.

Dans le cas des utilisateurs et super utilisateurs, les seules permissions sont : select, insert.
Pour le super utilisateur, il aura accès à toutes les tables et à toutes les colonnes.
Tandis que pour les utilisateurs (les caissiers) les accès se feront au travers des vues.

@+