Insertion + clés etrangères

[identifiant_bidon]

Bonjour à tous,

Dans le cadre d'un projet, je dois développer un site d'annonces immobilières.
Je dispose de 2 tables :

annonces_immobilier

Code :

1
2
3
4
id_annonce_immobilier
id_annonce_immobilier_texte
prix 
surface

annonces_immobilier_texte

Code :

1
2
3
id_annonce_immobilier_texte 
sujet_annonce
body_annonce

A chaque ligne dans annonces_immobilier correspond une ligne dans annonces_immobilier_texte. Mon problème se situe au niveau des insertions.
Voici, comment je comptais faire :

Code :

SELECT count(*) FROM annonces_immobilier

pour savoir combien j'ai d'annonces et ensuite :

Code :

1
2
INSERT INTO annonces_immobilier VALUES ("résultat de la requête précédente +1", "TOTO", prix, surface, ...);
INSERT INTO annonces_immobilier_texte VALUES ("résultat de la requête précédente +1", sujet, body);

avec TOTO = clé primaire de la table annonces_immobilier_texte correspondante -> donc "résultat de la requête précédente +1"

Cette façon de faire est-elle la bonne ? Et n'y a-t-il pas plus simple (par exemple, se débarrasser du SELECT COUNT)?
Comme je voudrais utiliser des AUTO INCREMENT, les clés primaires ne sont pas forcément nécessaires mais dans ce cas-ci, le sont-elles vraiment ?

Merci beaucoup

[Maljuna Kris]

Saluton,
Puisque c'est id_annonce_immobilier_texte qui est une clé étrangère dans la table annonces_immobilier, il serait préférable de créer d'abord la ligne dans la table annonces_immobilier_texte, de récupérer l'id via lastinsert_id puis de créer la ligne dans la table annonces_immobilier.

[identifiant_bidon]

Aaaah ok, merci Maljuna Kris. Je ne connaissais pas du tout LAST_INSERT_ID.
J'essaie ça dès ce soir.

[ericd69]

salut,

petite question pratique: pourquoi scinder ton annonce en mettant le texte et le titre à part sachant qu'on fait cela uniquement si on a besoin d'avoir plusieurs textes et titres pour une annonce



tu n'as donc aucun intérêt à faire 2 table alors que ça serait plus performant de tout rassemblé en une seule...

[identifiant_bidon]

Salut Eric. Ta question est intéressante. Ça m’intéresse grandement qu'on en discute d'ailleurs.

Comme il s'agit d'un projet de "dépôt" d'annonces immobilières (utilisé avec PHP), je me dis qu'il y a 2 parties : La première est l'insertion d'une annonce (donc l'insertion dans ces 2 tables) et la 2ème est la recherche puis affichage des annonces correspondant aux critères de recherche. Cette recherche peut être longue et ne se fera que sur les champs de la première table (et non pas sur les champs de la 2ème - titre et texte de de l'annonce). Du coup, pour avoir une recherche plus rapide, je ne ferai mon select que sur la 1ère table.

Voila, j'espère que j'ai été assez claire dans mon explication et surtout, j'espère que ce choix est plutôt cohérent.

Mon souci constant est d'avoir quelque chose d'optimisé mais je n'ai pas d'experience de DBA donc, je fait ce qui me semble A PRIORI logique.

[ericd69]

pas de soucis...

disons que la logique implique de comprendre un peu comment les choses se passent aussi "en dessous"...

par exemple faire des indexes augmente les performances sauf si tu les fais n'importe comment

mal dimensionner la taille des champs est un autre exemple

ces 2 paramètres jouent par exemple sur le nombre et la taille des fichiers générés pour une table... donc les temps d'accès, la quantité de mémoire consommée, le temps de traitement du processus...

de même les sgbd ne sont pas toujours capables de tout faire ou optimisés pour tout faire (parfois les gens confondent un sgbd avec un tableur par exemple... une table c'est pas une matrice... y a l'exemple dans le forum...)

tu peux faire des recherches de texte avec des regex par exemple mais pas des remplacements de texte avec... d'où le fait de savoir ce que tu dois faire comme traitement entre l'extérieur et le sgbd...

certaines fonctionnalités impliquent de pouvoir accéder au paramétrage du serveur ou avoir telle ou telle version minimum

bref rien n'est simple

[identifiant_bidon]

Ok, Eric

Donc toi, tu ferais une grosse table ?

Pour la recherche d'annonces, ça me semble dommage de parcourir une table avec des colonnes qui ne m’intéressent pas encore (surtout avec une colonne "texte de l'annonce" qui pourra faire jusqu'à 300 caractères).

Je le vois plutôt comme ça :
- L'utilisateur renseigne la surface et le prix (enfin des fourchettes à chaque fois).
- Je construis ma requête uniquement sur ces 2 critères / colonnes (j'en ai un peu + en fait - par ex. département, nb_pieces, ...). Du coup, je parcours ma 1ère table (celle où ne figurent pas le titre et le texte de l'annonce)
- J'ai mes tuples qui me sont retournés. J'affiche ces infos dans une page.
- Lorsque je clique sur une des annonces qui m'est renvoyé (pour en visualiser le détail), il m'est facile de passer l'ID dans l'URL, vu que les ID sont les mêmes dans les 2 tables - puisque les insertions ont été faites ensemble.
- dans la page détails de l'annonce, je fais un select avec l'id que j'ai transmis sur la 2ème table et j'affiche le titre et l'annonce en question.

J'ai du mal à comprendre, comment un fonctionnement en une table peut me faire gagner du temps en fait ! Je suis peu être trop fatigué, j'vais rentrer dormir ...

[ericd69]

oui...

tu devras récupérer aussi les documents, annexes (photos par exemple)

déjà un petit rappel ton select n'a pas besoin de tout renvoyer à chaque fois donc tu ne bufferiseras pas tout...

sur des dizaines de milliers de lignes on pourrait discuter de la performance de que tu fais...

mais là je trouve bizarre que tu n'affiches pas au moins le titre lors d'une recherche dans la liste des éléments trouvés... du coup ça mettrait seulement la description à part

or si ta description est définie en type text (ou dérivé de celui-ci) seul les 255 premiers octets sont dans le fichier de données de la table le reste est stocké dans un autre fichier...

et dans la manipulation des fichiers, on peut déplacer le pointeur sans lire le contenu

donc mysql ne bufferise que les champs que tu demandes (d'où ne jamais utiliser * sauf cas très particulier)

la création de l'index sur ta clé étrangère (un fichier supplémentaire) pour lire la table des texte et le temps de la jointure... tu vois ça fait du traitement...

lire une table implique donc la bufferisation des données demandées seulement et de l'intégralité des indexes.

faire une recherche sur des champs numériques ou varchar ou char compacts c'est donc très rapide même sur des milliers d'enregistrements avec autre chose sur les lignes passées en revue...

vu que je suppose que tu vas faire un outils de recherche pour affiner et afficher une liste de biens semi détaillée...j'ai pas raison?