Discussion :

[Marie_7]

Bonjour,
J'ai essayé d'importer le fichier .sql contenant ce code dans wampserver mais j'ai obtenu cette erreur

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
-- Table structure for table `comments`
--
 
CREATE TABLE `comments` (
  `id` varchar(20) NOT NULL,
  `content_id` varchar(20) NOT NULL,
  `user_id` varchar(20) NOT NULL,
  `tutor_id` varchar(20) NOT NULL,
  `comment` varchar(1000) NOT NULL,
  `date` date NOT NULL DEFAULT current_timestamp()
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
MySQL a répondu : Documentation
 
#1067 - Valeur par défaut invalide pour '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
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
 
 
 
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
START TRANSACTION;
SET time_zone = "+00:00";
 
 
/*!40101 SET @OLD_CHARACTER_SET_CLIENT=@@CHARACTER_SET_CLIENT */;
/*!40101 SET @OLD_CHARACTER_SET_RESULTS=@@CHARACTER_SET_RESULTS */;
/*!40101 SET @OLD_COLLATION_CONNECTION=@@COLLATION_CONNECTION */;
/*!40101 SET NAMES utf8mb4 */;
 
--
-- Database: `course_db`
--
 
-- --------------------------------------------------------
 
--
-- Table structure for table `bookmark`
--
 
CREATE TABLE `bookmark` (
  `user_id` varchar(20) NOT NULL,
  `playlist_id` varchar(20) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
 
-- --------------------------------------------------------
 
--
-- Table structure for table `comments`
--
 
CREATE TABLE `comments` (
  `id` varchar(20) NOT NULL,
  `content_id` varchar(20) NOT NULL,
  `user_id` varchar(20) NOT NULL,
  `tutor_id` varchar(20) NOT NULL,
  `comment` varchar(1000) NOT NULL,
  `date` date NOT NULL DEFAULT current_timestamp()
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
 
-- --------------------------------------------------------
 
--
-- Table structure for table `contact`
--
 
CREATE TABLE `contact` (
  `name` varchar(50) NOT NULL,
  `email` varchar(50) NOT NULL,
  `number` int(10) NOT NULL,
  `message` varchar(1000) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
 
-- --------------------------------------------------------
 
--
-- Table structure for table `content`
--
 
CREATE TABLE `content` (
  `id` varchar(20) NOT NULL,
  `tutor_id` varchar(20) NOT NULL,
  `playlist_id` varchar(20) NOT NULL,
  `title` varchar(100) NOT NULL,
  `description` varchar(1000) NOT NULL,
  `video` varchar(100) NOT NULL,
  `thumb` varchar(100) NOT NULL,
  `date` date NOT NULL DEFAULT current_timestamp(),
  `status` varchar(20) NOT NULL DEFAULT 'deactive'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
 
-- --------------------------------------------------------
 
--
-- Table structure for table `likes`
--
 
CREATE TABLE `likes` (
  `user_id` varchar(20) NOT NULL,
  `tutor_id` varchar(20) NOT NULL,
  `content_id` varchar(20) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
 
-- --------------------------------------------------------
 
--
-- Table structure for table `playlist`
--
 
CREATE TABLE `playlist` (
  `id` varchar(20) NOT NULL,
  `tutor_id` varchar(20) NOT NULL,
  `title` varchar(100) NOT NULL,
  `description` varchar(1000) NOT NULL,
  `thumb` varchar(100) NOT NULL,
  `datep` date NOT NULL DEFAULT current_timestamp(),
  `status` varchar(20) NOT NULL DEFAULT 'deactive'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
 
-- --------------------------------------------------------
 
--
-- Table structure for table `tutors`
--
 
CREATE TABLE `tutors` (
  `id` varchar(20) NOT NULL,
  `name` varchar(50) NOT NULL,
  `profession` varchar(50) NOT NULL,
  `email` varchar(50) NOT NULL,
  `password` varchar(50) NOT NULL,
  `image` varchar(100) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
 
-- --------------------------------------------------------
 
--
-- Table structure for table `users`
--
 
CREATE TABLE `users` (
  `id` varchar(20) NOT NULL,
  `name` varchar(50) NOT NULL,
  `email` varchar(50) NOT NULL,
  `password` varchar(50) NOT NULL,
  `image` varchar(100) NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
COMMIT;
 
/*!40101 SET CHARACTER_SET_CLIENT=@OLD_CHARACTER_SET_CLIENT */;
/*!40101 SET CHARACTER_SET_RESULTS=@OLD_CHARACTER_SET_RESULTS */;
/*!40101 SET COLLATION_CONNECTION=@OLD_COLLATION_CONNECTION */;

Merci d'avance

[Séb.]

DEFAULT CURRENT_TIMESTAMP n'est disponible que pour les colonnes TIMESTAMP ou DATETIME, or tu utilises une colonne DATE

=> https://dev.mysql.com/doc/refman/8.0...alization.html

[Marie_7]

Merci infiniment

[escartefigue]

De plus, nommer une colonne "date", c'est à dire en utilisant un nom réservé SQL, contraint à encadrer ce nom de colonne avec des quotes inversées (Alt-gr + 7) dans toutes les requêtes. C'est très pénible.
Une technique simple pour éviter d'avoir des noms réservés comme noms d'objets, c'est d'utiliser un préfixe ou un suffixe différent pour chaque table.
Par exemple, pour la table "commentaires", on utilise le préfixe "COM", pour la table "user" on utilise "USR", etc.

Et surtout, utiliser du varchar pour un identifiant est une hérésie, c'est contre-performant et c'est un gros risque de contenu signifiant et instable.
Une PK doit être stable et concise, le type idéal pour les identifiants est donc l'integer (small ou big le cas échéant)
Il faut donc remplacer le type de tous vos identifiants et ajouter la contrainte primary key

Enfin, il faut également ajouter les contraintes de type référence pour garantir l'intégrité des données, du coup, il faut créer les tables dans le bon ordre (tables référencées avant les tables référençantes).

Le DDL devient donc (à completer) :

Code SQL :

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
CREATE TABLE USR_user
     (  USR_id    INT AUTO_INCREMENT  PRIMARY KEY
      , USR_name  VARCHAR(50) NOT NULL
     )
;                  
CREATE TABLE CON_content
     (  CON_id    integer AUTO_INCREMENT PRIMARY KEY
      , CON_title varchar(100) NOT NULL
      , USR_id    integer NOT NULL
      , FOREIGN KEY(USR_id) 
        REFERENCES USR_user(USR_id)
     )
;
CREATE TABLE TUT_tutor
      (  TUT_id ... à compléter
      )
;
CREATE TABLE COM_comments 
     (  COM_id   integer AUTO_INCREMENT PRIMARY KEY
      , CON_id   integer NOT NULL
      , USR_id   integer NOT NULL
      , TUT_id   integer NOT NULL
      , COM_commentaire  varchar(1000) NOT NULL
      , COM_date date NOT NULL
      , FOREIGN KEY(USR_id) 
        REFERENCES USR_user(USR_id)
      , FOREIGN KEY(TUT_id) ... à compléter
     ) 
;

Notez que grâce à l'utilisation d'un préfixe, les quotes inverses deviennent inutiles.

L'utilisation d'un logiciel de modélisation est fortement recommandée, ça évite certaines de ces erreurs (notamment concernant les contraintes d'intégrité !). Je peux vous recommander LOOPING, performant, intuitif et gratuit et que vous pouvez télécharger ICI

[Artemus24]

Salut à tous.

Vous devez remplacer votre "current_timestamp()" soit par "now()" ou soit par "current_date()".

Cordialement.
Artemus24.
@+

[binarygirl]

Une technique simple pour éviter d'avoir des noms réservés comme noms d'objets, c'est d'utiliser un préfixe ou un suffixe différent pour chaque table.
Par exemple, pour la table "commentaires", on utilise le préfixe "COM", pour la table "user" on utilise "USR", etc.

Question rhétorique peut-être, mais ne vaut-il pas mieux alors préfixer les colonnes avec les noms de tables ?

[Artemus24]

Salut BinaryGirl.

Quand on crée le dictionnaire des données, on se débrouille pour que les noms soient parlant.
Il n'est pas nécessaire que le nom soit unique dans toutes la base de données.
Par exemple, "ID" a le même sens et la même déclaration dans tous les tables et sert comme identifiant technique.

Quand aux noms réservés, on peut les utiliser, mais il faut les mettre entre apostrophe inversés ou faire usage d'un préfixe.
Une astuce est de les mettre en français et non comme on peut le voir, en anglais.
Dans le cas d'une date de naissance, je préfère utiliser "naissance", plutôt que date qui reste trop généraliste.
"Time" est un mot réservé alors qu'en français, c'est "heure" qui n'est pas un mot réservé.

Je trouve que préfixer toutes les colonnes n'a aucun intérêt.
De loin, je préfère un nom court mais parlant, plutôt qu'un nom à rallonge sans apporter un quelconque avantage.

Dans le cas de la date, tu peux lui adjoindre un sens un peu plus précis, comme "datedeb" et "datefin" pour délimiter un intervalle.
Et si tu n'aimes pas coller les mots, tu peux mettre un tiret comme séparateur.
Il y a très peu de mots commun au français et à l'anglais, qui sont aussi des mots réservés.

Cordialement.
Artemus24.
@+

[binarygirl]

<mode chieuse="on">

Quand on crée le dictionnaire des données, on se débrouille pour que les noms soient parlant.

Justement, c'est une raison pour lesquelles je n'aime pas tellement cette idée de rajouter des préfixes artificiels au noms de champs, pardon de colonnes
Je trouve aussi que ça ajoute souvent de la redondance et que ça peut diminuer la lisibilité.

Je trouve que préfixer toutes les colonnes n'a aucun intérêt.

On ne doit pas le faire systématiquement pour toutes les colonnes. Mais dans certains cas ça permet de lever les ambiguïtés et c'est nécessaire dans un join entre deux tables (ou plus) dès lors qu'on veut tirer une colonne dont le nom existe dans plus d'une table.

Évidemment, je recommande fortement d'éviter les noms réservés de toute façon.

De loin, je préfère un nom court mais parlant, plutôt qu'un nom à rallonge sans apporter un quelconque avantage.

Justement: si on crée un champ USR_id, okay... mais alors soyons plus explicites et écrivons plutôt user_id, user_name etc tout simplement. Ça me paraît se rapprocher des pratiques souvent observées.

Après, rien n'interdit de créer des vues pour aliaser s'il y a un besoin légitime ou pour rajouter de l'abstraction.

[Artemus24]

Salut BinaryGirl.

<mode chieuse="on">

Je ne vois pas pourquoi car tu es libre de poser tous les questions même les plus insignifiantes.

Mais dans certains cas ça permet de lever les ambiguïtés et c'est nécessaire dans un join entre deux tables (ou plus) dès lors qu'on veut tirer une colonne dont le nom existe dans plus d'une table.

La colonne "id" est fréquemment l'identifiant de la table mère.
Dans une table fille, la clef étrangère se nomme du nom de la table mère associée à la colonne "id.
Quand ma clef étrangère est unique, parfois, je la nomme tout simplement "clef-fk".

Justement: si on crée un champ USR_id, okay... mais alors soyons plus explicites et écrivons plutôt user_id, user_name etc tout simplement.

Pourquoi nommer ta colonne "user_name" ?
As-tu plusieurs nom (name) dans ta base de données ?

Si c'est oui, je peux comprendre qu'il faut les distinguer.
Dans ce cas pourquoi ne pas utiliser des synonymes : libelle, designation, blase, ...

Si c'est non, le nom "name" suffit pour identifier ta table.

Ça me paraît se rapprocher des pratiques souvent observées.

Je ne suis pas contre de préfixer les colonnes à la condition que cela soit le plus court possible.

Après, rien n'interdit de créer des vues pour aliaser s'il y a un besoin légitime ou pour rajouter de l'abstraction.

Je pense que ce n'est pas une bonne pratique d'utiliser des alias pour redéfinir les noms des colonnes.

Chacun fait comme il l'entend à la condition que cela ne soit pas trop contraignant.

Cordialement.
Artemus24.
@+

[Séb.]

Perso j'ai testé un peu de tout, et finalement j'ai adopté :
1. Tout en anglais => Le franglais bouh
2. MySQL en @@sql_mode = 'ANSI,TRADITIONAL' incluant ANSI_QUOTES => Quand il y a besoin de quotes j'utilise " et pas `, plus facile d'accès et portable
3. Noms de tables au singulier, généralement au format "domain_tablename" => Pour organiser les tables et palier au manque de distinction bdd/schéma qu'on a sur PostgreSQL par ex.
4. Tables nommées table1_has_table2 pour les relations (n,n)
5. Noms de colonnes courts et très récurrents au niveau de la BdD (id, code, label, name, type, status, created_at, imported_at, type_id, parent_id, etc.) => Permet de rapidement s'y retrouver sur toutes les tables
6. Noms de tables/colonnes jamais abrégés => Pour plus d'expressivité
7. Usage des alias

Ex. :

Code SQL :

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

1
2
3
4
SELECT ALL u.name, s.name
FROM user AS u
INNER JOIN user_has_sector AS uhs ON u.id = uhs.user_id
INNER JOIN sector AS s ON uhs.sector_id = s.id

[escartefigue]

Justement, c'est une raison pour lesquelles je n'aime pas tellement cette idée de rajouter des préfixes artificiels au noms de champs, pardon de colonnes
Je trouve aussi que ça ajoute souvent de la redondance et que ça peut diminuer la lisibilité.

C'est tout le contraire, avec ce système :

• il n'y a aucune redondance, chaque nom de colonne est unique ;
• les études d'impact sont facilitées, car on sait d'emblée d'où vient chaque colonne : dans la table COM_commande, on sait que la colonne CLI_ident vient forcément de la table CLI_client sans avoir besoin de consulter le DDL ;
• une même colonne porte le même nom dans toutes les tables où elle se trouve.
  ainsi, une foreign key numéro de client dans la table des commandes se nommera par exemple CLI_ident de la même façon que dans la table des clients.
  C'est d'ailleurs ce que font par défaut tous les logiciels de modélisation des bases de données, ce n'est pas pour rien !
• les requêtes sont simplifiées, car il n'est plus nécessaire de s'encombrer des quotes inversées, et comme une même colonne FK sont identiques dans toutes les tables, les jointures sont intuitives

Bref, quand on l'a pratiqué, on constate que c'est beaucoup mieux.

[Séb.]

il n'y a aucune redondance, chaque nom de colonne est unique

Dans ton exemple il y avait redondance entre USR_user.USR_id et CON_content.USR_id, mais peut-être parles-tu d'autre chose ?
De plus il y a redondance entre le trigramme préfixé sur les noms de tables et celui apposé sur les noms de colonnes
À mon sens ça alourdit et n'épargne pas l'utilisation des alias (à moins de pratiquer les NATURAL JOIN)

C'est d'ailleurs ce que font par défaut tous les logiciels de modélisation des bases de données, ce n'est pas pour rien !

Cela me fait surtout penser à une facilité pour proposer un nom de colonne à partir de l'existant sans action utilisateur

++

[escartefigue]

Dans ton exemple il y avait redondance entre USR_user.USR_id et CON_content.USR_id, mais peut-être parles-tu d'autre chose ?
De plus il y a redondance entre le trigramme préfixé sur les noms de tables et celui apposé sur les noms de colonnes

C'est ce que j'ai expliqué plus haut, quand il s'agit d'une clef étrangère, elle porte le même nom dans toutes les tables que dans la table où cette même colonne est PK. C'est le seul cas où un même nom est présent à plusieurs endroits.
Quand on n'utilise pas cette méthode, on trouve des homonymes. Typiquement, la colonne "ID" dont on ne sait jamais de quoi il s'agit si on n'a pas le nom de la table ou son alias.
Sans cette méthode, les jointures sont du genre ON table2.id_client = table1.id [...] on table3.client_id=table1.id bref sans avoir le DDL sous les yeux, impossible de coder les jointures.

À mon sens ça alourdit et n'épargne pas l'utilisation des alias (à moins de pratiquer les NATURAL JOIN).

Ça n'épargne en effet pas l'utilisation des alias, ce n'est pas le but, et il ne faut jamais utiliser NATURAL JOIN !

Cela me fait surtout penser à une facilité pour proposer un nom de colonne à partir de l'existant sans action utilisateur

C'est aussi le cas, mais c'est surtout pour avoir un dictionnaire de données propre, sans synonyme et sans homonymes, ce qui est une règle de base de la modélisation. Une colonne c'est un et un seul nom, y compris et surtout pour les FK.
Seule exception : cas où une colonne est présente plusieurs fois dans une table (ex : relation reflexive composant / composé ou parent / enfant), mais en ce cas, on ajoute un suffixe en conservant un radical commun (exemple : USR_ident_parent et USR_ident_enfant)

[Artemus24]

Salut à tous.

il n'y a aucune redondance, chaque nom de colonne est unique ;
une même colonne porte le même nom dans toutes les tables où elle se trouve.

Une contradiction en apparence dans ce que tu dis.

C'est aussi le cas, mais c'est surtout pour avoir un dictionnaire de données propre, sans synonyme et sans homonymes, ce qui est une règle de base de la modélisation.

La première étape de la modélisation est la création d'un dictionnaire de données.
Le but est de définir un référentiel en terme de vocabulaire qui sera utilisé dans les fonctionnalités du modèle entité-relation.

Ce n'est pas dans cette étape que l'on attribue ces métadonnées à des tables.
Il n'est pas question ici des aspects techniques liés aux SGBD et encore moins de définir un circuit des données.

Cette notion de clef étrangère n'a pas sa raison d'être dans un dictionnaire de données.
A vrai dire, ce qui va devenir par la suite une clef étrangère, est dans le dictionnaire un identifiant.
C'est pourquoi, il faut distinguer dans ce dictionnaire les identifiants, des données informationnelles.

Le choix du SGBD relationnel n'a pas sa place dans ce dictionnaire.
Il ne faut pas préfixer ces métadonnées par quoi que ce soit dans ce dictionnaire.

La métadonnée définie dans ce dictionnaire sera unique. Sur ce point, je suis d'accord.

Dans les étapes suivantes, on fait le regroupement de ces métadonnées en entité.
Il peut apparaitre des redondances car une même métadonnée peut apparaitre à plusieurs endroits dans le modèle entité-relation.

Lorsque tu passes enfin au modèle physique des données, tu tiens compte maintenant de ces aspects techniques.
Je ne vois pas l'intérêt de préfixer toutes tes colonnes dans une table.
La seule contrainte que tu rencontres est d'avoir des noms de colonnes uniques pour chaque table.

C'est pourquoi, je préfixe uniquement les clefs étrangères dans la table fille par le nom de la table mère.
Pourquoi ? Parce que c'est une contrainte technique et qu'il faut la distinguer de l'identifiant de la table mère.

Mais je peux avoir de la redondance dans une base de données. Je ne parle pas ici des clefs étrangères.
Les mêmes noms de colonne auront la même sémantique et le même type, celui défini par le dictionnaire de données.
Pour faire la distinction, on fera l'usage des alias des noms de tables.
Je parle du préfixe qui est définie soit dans le from ou dans les jointures par le mot réservé "as".

Maintenant, si tu trouves inadmissible d'avoir de la redondance dans ta base de données, il te suffit au niveau du dictionnaire des données de faire cette distinction sur ces aspects chronologiques ou de mouvement.
Mais comment vas tu faire pour justifier le fait que plusieurs métadonnées ont la même sémantique et ne porte pas les mêmes noms ?

Le nom de la colonne doit être le même que celui de ta métadonnée dans le dictionnaire des données.
Donc pourquoi changer ce nom des colonnes dans ta base de données ?

Cordialement.
Artemus24.
@+

[escartefigue]

@Artemus, il n'y a aucune contradiction : on établit le dictionnaire de données en interdisant tous les synonymes (noms différents pour le même attribut) et tous les homonymes (noms identiques pour des attributs différents). Quand c'est fait, on réalise le modèle conceptuel des données (le MCD) dans lequel il n'y a non pas des fonctionnalités (ça c'est du ressort des traitements), mais des entité-type, des associations, des contraintes, des cardinalités, des héritages...

Outre les avantages déjà cités plus haut, avec un préfixe ou un suffixe on simplifie certains noms.
Par exemple, pour les libellés qui apparaissent dans de nombreux types d'entités (et donc dans de nombreuses tables), plutôt que de les nommer
LIB_ARTICLE, LIB_MOYEN_PAIEMENT, LIB_PAYS etc. Avec ma méthode, j'aurai ART_lib, MOY_lib, PAY_lib, donc finalement un nom plus concis et plus facile à manipuler.

Les bons logiciels de modélisation (cas de Power AMC et de Looping par exemple) permettent de renseigner à la fois le nom usuel de l'attribut et le nom SQL, ainsi, on établit la bijection dès la modélisation conceptuelle.
Malheureusement, la plupart des utilisateurs de MySQL n'utilisent pas de vrai logiciel de modélisation, ils utilisent Workbensh qui attaque la modélisation au stade tabulaire , ce faisant, les synonymes sont légion et c'est bien dommage.

Dans les entreprises, il y a souvent des normes de codification, auquel cas on les applique sans se poser de questions.

Mais quand on a le choix, je continue d'affirmer par expérience que l'usage d'un préfixe ou d'un suffixe pour les noms de colonnes est bien pratique.
Je ne suis pas le seul à pratiquer ainsi, SQLPro par exemple utilise un système semblable, quoique plus compliqué, car il y ajoute d'autres notions dans la codification des objets, qui, quoi qu'utile, est un peu complexe à mon goût. Cinephil également utilise ce type de codifications. Il y en a d'autres.

[Artemus24]

Salut Escartefigue.

Avec ma méthode, j'aurai ART_lib, MOY_lib, PAY_lib, donc finalement un nom plus concis et plus facile à manipuler.

Dans le dictionnaire des données, c'est la métadonnée "libellé" qui apparait et non "Art_lib", "MOY_lib" et "PAY_lib", qui ne sont que des synonymes.
Je comprends que tu prends au pied de la lettre le fait que c'est un dictionnaire.
Tu as certainement une table des matières qui va renvoyer tous les synonymes vers les métadonnées.

Dans les entreprises, il y a souvent des normes de codification, auquel cas on les applique sans se poser de questions.

C'est même pire que cela, il y a ce que je nomme une censure, qui va valider vos documents avant de les passer à l'étape suivante.
Ces normes sont contraignantes car cela concernent toutes les bases de données de l'entreprise.

Mais quand on a le choix, je continue d'affirmer par expérience que l'usage d'un préfixe ou d'un suffixe pour les noms de colonnes est bien pratique.

Je ne dis pas le contraire car c'est une pratique que j'adopte aussi, mais je ne le fais as systématiquement.
Cela dépend de la complexité de la base de données et de la redondance des noms de colonnes.

Je privilégie toujours la lisibilité comme le souligne BinaryGirl.

Quand à celle de SQLPRO, elle donne des noms en rallonge que je trouve non justifiés. C'est son choix et sa méthode est certainement justifiée.

Quand est-il quand pour une table donnée tu as une multitude de View.
Doit-on nommer la vue à partir du nom de la table d'origine avec un préfixe sur le rôle qu'elle doit jouer ?
Par exemple, la table paye se nomme "paye". La vue concernant la comptabilité va-t-elle se nommer "comp_paye" ?
Et celle des utilisateurs, "user_paye", ...

Cordialement.
Artemus24.
@+