[quote="meso"]Et pour te répondre ça serait 11 ![/quote]
Ben non : si la rubrique parente est rubrique_11, la clé étrangère pour les deux nouvelles rubriques sera la clé primaire de rubrique_11 : ce n'est donc pas 11 qui n'existe même pas encore mais... :?:

Ah ! Merci, je comprends mieux, évidemment !
Et pour te répondre ça serait 11 !
Merci pour cette explication.

Bon, je recommence. Voici la structure que ça va donner pour la table rubrique :
[code]+----------------------+
| rubrique |
+----------------+-----+
|rub_id | PK |
|rub_parent | FK |
|rub_nom | |
+----------------+-----+[/code]
VOici maintenant cette même table avec 4 lignes de données:
[code]+--------+------------+---------------+
| rub_id | rub_parent | rub_nom |
+--------+------------+---------------+
| 1 | 0 | rubrique_1 |
| 2 | 0 | rubrique_2 |
| 3 | 0 | rubrique_3 |
| 4 | 1 | rubrique_11 |
+--------+------------+---------------+[/code]
Comme tu peux voir, chaque ligne représente une rubrique différente. La rubrique_11 a sa propre ligne. Mais sur cette ligne, si tu observes la colonne rub_parent, toutes ont la valeur 0 sauf rubrique_11 qui a pour valeur 1 : Dans la structure, j'ai noté PK (Primary Key = clé primaire) et FK (Foreign Key = clé étrangère) : la clé étrangère correspond à la clé primaire de l'élément parent. Ce qui veut dire que si rub_parent vaut 1, pour trouver l'élément parent, il faut chercher la ligne où la clé primaire vaut 1 : on trouve rubrique_1. On peut donc faire le lien suivant: rubrique_11 a pour rubrique parente rubrique_1.

Suppose à présent que tu veuilles pour une raison quelconque subdiviser rubrique_11 en sous-sous-rubrique et que tu aies rubrique_111 et rubrique_112 : Quelle serait selon toi la valeur de rub_parent pour les deux nouvelles lignes créées ?

[quote]Est-ce que tu visualises plus clairement comme ça ?[/quote]

Non, pas du tout, désolée !
Si "rubrique_1" et "rubrique_11" sont dans le même champ de la même table. Comment tu définis que "rubrique_11" est une sous rubrique de "rubrique_1".
Pour le moment, j'ai ça :

MENU_TBL :
id_menu
nom_menu
nom_table

RUBRIQUE_TBL :
id_rub
id_menu
nom_ssrubrique

"id_menu" est identique dans les 2 tables. Donc quand on sélectionne un "nom_ssrubrique" on sait a quel menu il appartient.

Pour la champ rub_parent, supposons le cas suivant:
Tu as les catégories de base rubrique_1, rubrique 2 et rubrique_3. Tu as aussi une rubrique_11 qui est une sous-rubrique de rubrique 1. Si tu les enregistres dans cet ordre, tu auras les clés primaires 1, 2, 3 et 4. Tu auras une valeur par défaut dans la colonne rub_parent : 0 pour les rubriques racines. Mais la rubrique_11 qui est une sous-rubrique de la rubrique_1, le champ rub_parent aura pour valeur la clé primaire de la parente, donc ici 1.

Est-ce que tu visualises plus clairement comme ça ?

D'abord, désolée pour le mauvais endroit du poste. J'avais hésité entre méthodologie et SQL !

Pour répondre à cyrano :

Le champ "table" dans les menus serait pour utiliser des variables pour me connecter à la bonne table.

[quote][i]En ajoutant dans l'entité Rubrique une propriété "rub_parent", tu peux d'avance planifier d'avoir des sous-rubriques qui seront obligatoirement filles d'une rubrique-mère[/i][/quote]
Je ne suis pas sûre d'avoir compris.
"rub_parent" reprendrait le "id_menu" de la table menu. Non ?
Si c'est bien ça, je l'ai déjà fait. Mais j'ai donné le même nom de champ dans les différentes tables à savoir "id_menu". C'est risqué de faire ça ?

Et pour répondre à albat :
Et si je faisait une seule table de contenu, est-ce que tes cheveux se dresseraient moins sur ta tête !
Finalement, ça m'arrangerait ! Dans cette table, il y aurait une petite dizaine de champ et au final de 80 à 100 lignes. Mais il est vrai avec des types de données différentes.
Je me doute que ce n'est pas très orthodoxe. Mais est-ce que ça peut fonctionner vu que c'est un petit site.

Merci à tous les 2.

Difficile de commenter ta proposition, car trop peu d'informations.
Toutefois, l'indication "1 table par rubrique" me fait dresser les cheveux sur la tête.

Rappel : les tables sont construites selon les structures/types de données
et non selon les valeurs qu'elles sont destinées à recevoir.

Je dirais que pour définir tes tables, il faut commencer par modéliser le tout:
[code]+-------------+ +----------+
| Rubriques | __________ | Menus |
+-------------+ 0/n / contient \ 1/1 +----------+
| rub_id |-------------------------| Men_id |
| rub_nom | \__________/ | Men_nom |
| rub_parent | +----------+
+-------------+[/code]
Là, on a une entité "Rubriques" et une entité "Menus"
Rubrique peut contenir [i]0[/i] à [i]n[/i] menus , mais Menus appartient à une et une seule Rubrique.

Lors de la création des tables, tu auras donc dans la table Menus une clé étrangère "[i]rub_id[/i]"

En ajoutant dans l'entité Rubrique une propriété "[i]rub_parent[/i]", tu peux d'avance planifier d'avoir des sous-rubriques qui seront obligatoirement filles d'une [i]rubrique-mère[/i]

Par contre, je saisis mal l'idée du champ "table" dans tes menus...

Bonjour,

Je voudrais savoir si je m'y prend bien pour construire ma base ou si mon raisonnement est totalement idiot !

Voilà, c'est pour un site avec environ 8 rubriques et 30 pages. D'autres seront créées plus tard via phpMyAdmin. Il n'y aura pas de back-office. Et un menu déroulant (avec rubrique et ss-rubrique) en css et dynamique dont les infos viendront d'une base MySQL.

Dans ma bdd, j'ai créer :
- 1 table par rubrique
- 1 table menu avec comme champs id_menu, nom_menu et nom_table (pour utiliser ce champs pour se connecter à la bonne table)
Donc comme ceci :

MENU_TBL

id_menu I nom_menu I nom_table
1 I présentation I PRESENT_TBL
2 I services I SERVICES_TBL
3 I Actualités I ACTU_TBL

Avec le id_menu repris dans chaque table.

Avant d'aller plus loin, j'aimerais avoir votre avis.
Merci