Discussion :

[escartefigue]

J'ai oublié de préciser que mon projet (site web / application mobile) doit être réalisé avec Java EE et le tout doit virtualiser ou en docker , je dois aussi utiliser des outils devOPS tels que Jenkins et GitHub
De préférence, je préfère travailler sous linux donc je pense utiliser docker. Dans vos choix, PostgreSQL semble multiplateforme et respectant la norme SQL au mieux. est-ce un bon choix pour un projet web (Java EE) ?

Je ne me prononcerai pas sur les outils et langages de développement sur lesquels je suis à peu près ignare .
Cela étant, il me semble qu'on peut avoir n'importe quelle base de donnée sous-jacente à partir du moment où les connecteurs SQL sont disponibles

Pour le reste, si on vous impose SQLite et/ou du NoSQL, alors il n'y a pas de question à se poser, mais même si vous avez des dizaines de millions de parking à gérer dans le futur, ca reste très modeste pour une base relationnelle et ça ne justifie en rien du NoSQL, surtout pas pour des raisons de rapidité.

[NarumiN]

Je ne me prononcerai pas sur les outils et langages de développement sur lesquels je suis à peu près ignare .
Cela étant, il me semble qu'on peut avoir n'importe quelle base de donnée sous-jacente à partir du moment où les connecteurs SQL sont disponibles

Pour le reste, si on vous impose SQLite et/ou du NoSQL, alors il n'y a pas de question à se poser, mais même si vous avez des dizaines de millions de parking à gérer dans le futur, ca reste très modeste pour une base relationnelle et ça ne justifie en rien du NoSQL, surtout pas pour des raisons de rapidité.

Pas de soucis. Vous m'avez énormément aidé et je vous en remercie.

Oui, ce modèle répond aux règles établies, par contre, la création des vues est un peu prématurée.
En principe, avec ce modèle, on dérive le script SQL de création des tables (après avoir choisi le SGBD). Ce script est généré automatiquement par la plupart des logiciels de modélisation. C'est le cas de looping.
Ensuite, il faut créer les index pour les critères de recherche (exemple : recherche par nom de personne, par nom de ville, par département...)
Quand c'est fait, on se crée un jeu de données avec suffisamment de volume (quelques centaines de milliers de lignes) pour tester les requêtes principales en qualité de résultat et en performances.
Une fois que tout ça est au point, on peut encapsuler les requêtes dans des vues

A partir du modèle que vous m'avez grandement aidé à réalisé, je peut créer le script SQL des tables ( pour PostgreSQL) à partir de looping et la fonction Script SQL ?
Pour la création des index pour les critères de recherche, comment je dois procéder ?

[escartefigue]

Oui le script SQL proposé par Looping est utilisable en l'état.
Pour les index, il faut identifier les colonnes ou combinaisons de colonnes qui serviront comme critère de restriction (WHERE) ou de jointure (JOIN)
Quand c'est fait, on peut créer les index correspondants.
Pour éviter les erreurs de syntaxe, il faut se référer au manuel de référence du SGBD et de sa version et rechercher l'ordre CREATE INDEX.

Attention toutefois :

• un index facilite la recherche seulement s'il concerne des valeurs discriminantes, créer un index sur une colonne ne pouvant prendre que deux ou trois valeurs n'a donc pas d'intérêt (hors index couvrant, mais c'est un autre concept).
• chaque index supplémentaire pénalise les mises à jour (insert, update et delete) et les servitudes (reorg, rebuild)
• même quand un index est pertinent, il n'est éligible que si le prédicat est dit "sargable"
  par exemple WHERE ma_colonne=@valeur ou WHERE ma_colonne like 'abcd%' sont sargable si @valeur est du même type que ma_colonne,
  mais WHERE ma_colonne <>@valeur, WHERE ma_colonne like '%abcd% et WHERE SUBSTRING(ma_colonne, 1, 5)=@valeur ne sont pas sargable

Il faut donc ne créer que les index utiles avec discernement

[Paprick]

Bonjour,

Je rejoints escartefigue sur le fait que les index doivent contenir des valeurs discriminantes. D'ailleurs, les meilleurs index sont les clés alternatives.
Au niveau de Looping, vous pouvez créer ces clés alternatives avec l'option UNIQUE proposée au niveau des rubriques.
Il est aussi possible de créer des index composés : il faut alors utiliser la zone "Index" prévue à cet effet, zone dont je pourrai vous expliquer le fonctionnement si vous en avez besoin.

Bonne continuation !

[NarumiN]

Oui le script SQL proposé par Looping est utilisable en l'état.
Pour les index, il faut identifier les colonnes ou combinaisons de colonnes qui serviront comme critère de restriction (WHERE) ou de jointure (JOIN)
Quand c'est fait, on peut créer les index correspondants.
Pour éviter les erreurs de syntaxe, il faut se référer au manuel de référence du SGBD et de sa version et rechercher l'ordre CREATE INDEX.

Attention toutefois :

• un index facilite la recherche seulement s'il concerne des valeurs discriminantes, créer un index sur une colonne ne pouvant prendre que deux ou trois valeurs n'a donc pas d'intérêt (hors index couvrant, mais c'est un autre concept).
• chaque index supplémentaire pénalise les mises à jour (insert, update et delete) et les servitudes (reorg, rebuild)
• même quand un index est pertinent, il n'est éligible que si le prédicat est dit "sargable"
  par exemple WHERE ma_colonne=@valeur ou WHERE ma_colonne like 'abcd%' sont sargable si @valeur est du même type que ma_colonne,
  mais WHERE ma_colonne <>@valeur, WHERE ma_colonne like '%abcd% et WHERE SUBSTRING(ma_colonne, 1, 5)=@valeur ne sont pas sargable

Il faut donc ne créer que les index utiles avec discernement

Merci a vous.

Pour choisir les colonnes ou combinaisons de colonnes qui serviront comme critere de restriction ou de jointure. je dois me servir de mes cas d'utilisations et leur description textuelle pour verifier ce que j'ai besoin d'acceder ?

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
Documentation des cas d'utilisation :

=========================================================

Cas d’utilisation : S’authentifier
Acteurs : Managers et Clients.
Objectif : Il permet à l’acteur de s’identifier en saisissant son login et mot de passe.
Précondition : L’acteur doit être présent dans la base de données.
Postcondition :
- Acteur authentifié.
- La page d’accueil s’affiche.

Scénario nominal :
1. L’acteur ouvre l’application,
2. Le système affiche la page d’authentification,
3. L’acteur saisit le login et le mot de passe,
4. Le système vérifie l’existence des données,
5. Le système affiche la page d’accueil.

Scénario alternatif :
1A. Erreur d’authentification : login ou mot de passe non valide.
Cet enchaînement démarre au point 4.
1B. Le système affiche un message d’erreur.
Le scénario reprend au point 2.
2. Champs obligatoires vides.
Cet enchaînement démarre au point 4.
Le scénario reprend au point 2.




==========================================================

Cas d’utilisation : Ajouter un parking
Acteurs : Client
Objectif : Il permet au client de parc d’ajouter un parking dans son profil.
Précondition : Succès d’authentification.
Postcondition : Parking ajouté.

Scénario nominal :
1. Le client choisit d’afficher son profil utilisateur.
2. Le système affiche le profil utilisateur,
3. Le client choisit l’ajout d’un nouveau parking,
4. Le système affiche le formulaire à remplir,
5. Le client saisit les informations à remplir sur le nouveau parking,
6. Le système vérifie les données,
7. Le système enregistre le parking dans la base de données.


Scénario alternatif :
1. Champs obligatoires non valides ou vides.
Cet enchaînement démarre au point 6.
2. Le système affiche un message d’erreur.
Le scénario reprend au point 4.
 
============================================================
Cas d’utilisation : Modifier un parking

Acteurs : Client
Objectif : Il permet au client de modifier les informations de son parking.
Précondition :
- Succès d’authentification.
- Succès de consultation de la liste de ses parkings.
Postcondition : Parking modifié.

Scénario nominal :
1. Le client choisit d’affiche la « Liste de mes parkings »,
2. Le système affiche la liste,
3. Le client choisit la modification des informations d’un parking,
4. Le système affiche le formulaire de modification,
5. Le client modifie les informations du parking,
6. Le système demande la validation des modifications,
7. Le client valide les modifications,
8. Le système vérifie les données,
9. Le système enregistre les modifications dans la base de données.

Scénario alternatif :
1. Champs obligatoires non valides ou vides.
Cet enchaînement démarre au point 8.
2. Le système affiche un message d’erreur.
Le scénario reprend au point 4.
 
===========================================================
Cas d’utilisation : Supprimer un parking 

Acteurs : Client
Objectif : Il permet au client de supprimer son/ses parkings de son profil utilisateur.
Précondition :
- Succès d’authentification.
- Succès de consultation de la liste de ses parkings.
Postcondition : Parking supprimé.

Scénario nominal :
1. Le client choisit d’afficher la « Liste de mes parkings »,
2. Le système affiche la liste,
3. Le client choisit la suppression d’un parking,
4. Le système demande la validation de la suppression,
5. Le client valide la suppression,
6. Le système procède à la suppression du parking de la base de données.

Scénario alternatif :
1. Le client annule la suppression.
Cet enchaînement démarre au point 4.
2. Le système affiche une notification.
Le scénario reprend au point 2.
 
================================================================
Cas d’utilisation : Consulter la liste des annonces de parkings 

Acteurs : Manager et Client
Objectif : Il permet aux acteurs de consulter la liste des annonces de parkings.
Précondition : Succès d’authentification.
Postcondition : Aucune.

Scénario nominal :
1. L’utilisateur choisit d’afficher la liste des annonces de parkings,
2. Le système affiche la liste des annonces de parkings,
3. Le système vérifie le type d’utilisateur connecté (si client ou Manager),
4. Si l’utilisateur est :
-	un client, le système fait appel aux cas d’utilisation interne « Réserver un parking ».
-	un client et le propriétaire du parking, le système fait appel aux cas d’utilisation interne « Modifier une annonce ».
- 	un Manager, le système fait appel aux cas d’utilisation interne « Modérer une annonce ».
Scénario alternatif : Aucun.


 
================================================================
Cas d’utilisation : Réserver un parking
Acteurs : Client
Objectif : Il permet à l’acteur de réserver un parking.
Précondition : Succès d’authentification.
Postcondition : parking réservé.

Scénario nominal :
1. Le client choisit d’afficher la « Liste des annonces ».
2. Le système affiche la liste de ses annonces.
3. le client choisit de visiter une des annonces.
4. Le système affiche l’annonce choisie.
5. Le client choisit de réserver le parking.
6. Si l’acteur n’est pas le propriétaire du parking, le système affiche le formulaire de réservation.
7. Le client remplit le formulaire de réservation.
8. Le système demande la validation des informations saisies.
9. Le client valide les informations.
10. Le système vérifie les données.
11. Le système enregistre la réservation dans la base de données.


Scénario alternatif :
1. Champs obligatoires non valides ou vides.
Cet enchaînement démarre au point 10.
2. Le système affiche un message d’erreur.
Le scénario reprend au point 6.
 
================================================================
Cas d’utilisation : Modifier une annonce de parking
Acteurs : Client
Objectif : Il permet à l’acteur de consulter ses annonces de parkings.
Précondition : Succès d’authentification.
Postcondition : annonce de parking modifiée.

Scénario nominal :
1. Le client choisit d’afficher la « Liste de mes annonces ».
2. Le système affiche la liste de ses annonces.
3. le client choisit de visiter une de ses annonces.
4. Le client choisit la modification des informations de l’annonce.
5. Le système affiche le formulaire de modification.
6. Le client modifie les informations de l’annonce,
7. Le système demande la validation des modifications,
8. Le client valide les modifications,
9. Le système vérifie les données,
10. Le système enregistre les modifications dans la base de données.


Scénario alternatif :
1. Champs obligatoires non valides ou vides.
Cet enchaînement démarre au point 9.
2. Le système affiche un message d’erreur.
Le scénario reprend au point 5.






================================================================
Cas d’utilisation : Modérer une annonce de parking
Acteurs : Manager
Objectif : Il permet à l’acteur de modérer une annonce.
Précondition : Succès d’authentification.
Postcondition : annonce de parking modérée.

Scénario nominal :
1. Le manager choisit d’afficher la « Liste des annonces ».
2. Le système affiche la liste des annonces.
3. le manager choisit de visiter une des annonces.
4. Le client choisit de modérer l’annonce.
5. Le système affiche le formulaire de modération.
6. Le client modifie les informations de l’annonce,
7. Le système demande la validation des modifications,
8. Le client valide les modifications,
9. Le système vérifie les données,
10. Le système enregistre les modifications dans la base de données.


Scénario alternatif :
1. Champs obligatoires non valides ou vides.
Cet enchaînement démarre au point 9.
2. Le système affiche un message d’erreur.
Le scénario reprend au point 5.

Bonjour,

Je rejoints escartefigue sur le fait que les index doivent contenir des valeurs discriminantes. D'ailleurs, les meilleurs index sont les clés alternatives.
Au niveau de Looping, vous pouvez créer ces clés alternatives avec l'option UNIQUE proposée au niveau des rubriques.
Il est aussi possible de créer des index composés : il faut alors utiliser la zone "Index" prévue à cet effet, zone dont je pourrai vous expliquer le fonctionnement si vous en avez besoin.

Bonne continuation !

Bonjour,

Je prend compte de vos suggestions et conseils.


Merci beaucoup.

[escartefigue]

En effet, dans l'exemple fourni, on voit que la recherche se fera sur le login saisi par l'utilisateur.
Un index sur le login est donc requis.
Mais comme le login est forcément unique, il y aura par défaut un index existant sur cette colonne *, du coup inutile d'en créer un autre pour ce cas d'utilisation

* en effet, la plupart des SGBD, sans doute tous, créent un index sur la ou les colonnes faisant l'objet d'une contrainte unique (et donc notamment les PK)