Clause LIKE

par **dunbar** » 16 oct. 2008, 19:38

tu peux garder les champs OM72 (et fils) dans un champ nom mais pour savoir s'il est père ou fils un id effectuant la relation est ce qu'il y a de mieux et facile.

J'ai décider de faire comme ceci:
J'oblige a passer par le parent pour encoder l'enfant ce qui me permet de prendre l'id du parent
et pour récupérer les enfants il me suffit de de faire un WHERE avec l'id du parent

merci

par **dunbar** » 23 sept. 2008, 16:37

Je te permet

et surtout te remercie je vais travailler en suivant vos conseils.

par **Truc** » 23 sept. 2008, 10:02

permet moi d'insister puisque la conception peut être revue sans problèmes

placer un id auto-incrémenté (donc un int surtout pas de blob pour 5 caractères ) pour tout le monde... ajouter un champ "maitre".

pour l'entrée OM72 qui est un "maître" ce champ vaut null
pour les élèves ce champ contient l'id du maître (OM72).... tu peux donc facilement retrouver tous les élèves avec une jointure en partant du maître.

tu peux garder les champs OM72 (et fils) dans un champ nom mais pour savoir s'il est père ou fils un id effectuant la relation est ce qu'il y a de mieux et facile.

par **dunbar** » 22 sept. 2008, 18:40

2 solutions :
Lorsque le maître change, que deviennent les enfants ?
exemple :
le maitre portait le numéro OM72 et devient OM80

Si les enfants doivent devenir OM80a, OM80b, ... alors il faut que tu décomposes le numéro des enfants en (numéro parent/id enfant)

Et si tu me dis que ce n'est pas possible, j'ai envie de te répondre que le client trouve toujours le moyen que ça devienne possible (genre, le parent est remplacé et tous les enfants doivent changer de parent )

Ce n'est pas possible car en réalité j'ai donner comme exemple élèves, enfants, maîtres, etc....
Mais la réalité est que c'est un réseau existant d'ampli primaire, ampli secondaire (télédistribution) je crée un programme qui va me permettre de faire l'inventaire du réseau et il n'est pas possible (techniquement)de changer de maître car cela voudrait dire changer la structure même du réseau se qui est inimaginable, par contre les élèves eux pourrait changer de maître. Voilà pourquoi je cherche un moyen simple de pouvoir manipuler la numérotation.
De plus c'est des techniciens qui encode les données donc c'est même pas la peine de penser à faire un truc compliqué si on veut qu'ils encode correctement cela doit être trés simple.
Quand au client c'est vraiment pas un facile. (c'est moi

).
Et un détail aussi la numérotation existe et je dois composer avec.

Plus sérieusement la conception peut être revue puisque je débute le projet.
Mon idée de départ est de créer une TABLE pour mes primaires, et une TABLE pour mes secondaires dans les deux TABLES un champs auto_increment.
Donc les champ numéro primaire OM27
et le champ du secondaire OM27a
Et les champs numéro secondaire OM27a

pour relier les deux j'utilise un LIKE om27_

par **zeus** » 22 sept. 2008, 18:24

En fait, tant qu'il est possible, nous essayons de donner le cheminement qui nous parrait le plus sain, et nous pensons que revoir la conception (s'il y en a eu une) peut être une bonne voie d'apprentissage.

Et comme notre but est avant tout que les membres qui posent une question apprennent de leurs erreurs, cette manière de faire nous parrait bien.

Mais en aucun cas nous pouvons te reprocher d'avoir donné une réponse, surtout qu'elle répond à la problématique. Nous nous sommes juste permis de donner notre avis et ce qui nous semble le mieux

par **Invité** » 22 sept. 2008, 18:18

...
Ou comment faire compliqué quand on peut faire simple

Je préfère une BDD bien faite que l'utilisation de "stratagèmes"

[/quote]
...

Oui bien sûr le problème est avant tout au niveau de la conception : il vaut bien mieux faire du relationnel plutôt que du bricolage car il s'agit typiquement d'une relation 1..n. Mais bon il s'agit aussi de répondre à la question posée car nous sommes loin d'avoir tous les éléments sous la main pour savoir s'il vaut mieux revenir à la conception.

A+

RV

par **zeus** » 22 sept. 2008, 17:57

2 solutions :
Lorsque le maître change, que deviennent les enfants ?
exemple :
le maitre portait le numéro OM72 et devient OM80

Si les enfants doivent devenir OM80a, OM80b, ... alors il faut que tu décomposes le numéro des enfants en (numéro parent/id enfant)

Et si tu me dis que ce n'est pas possible, j'ai envie de te répondre que le client trouve toujours le moyen que ça devienne possible (genre, le parent est remplacé et tous les enfants doivent changer de parent

)

par **Truc** » 22 sept. 2008, 17:54

placer un id auto-incrémenté (donc un int surtout pas de blob pour 5 caractères

) pour tout le monde... ajouter un champ "maitre".

pour l'entrée OM72 qui est un "maître" ce champ vaut null
pour les élèves ce champ contient l'id du maître (OM72).... tu peux donc facilement retrouver tous les élèves avec une jointure en partant du maître.

par **dunbar** » 22 sept. 2008, 17:30

Salut,

Et merci, j'avais peur d'avoir mal conçu ma base avec mes 40 champs.
et en effet chaque donnée a sont propre champs.
Par contre.
Imaginons une hiérarchie de pc avec un pc maître est ces éleves
Le pc maître porte comme numéro -> OM72 = champs de la base un champ BLOD
Et ces éleves portent comme numéro OM72a, OM72b, etc.... egalement un champ BLOD
Je ne voie pas comment il serais plus préférable d'enregistrée la numérotation.

Et dans ce cas précis le mouen le plus simple de connaître les éleves des maître est bien de faire un LIKE OM72_%

Ou y a t'il une meilleur méthode

Il est impossible de savoir combient il va ya avoir de maître et encore plus d'élèves je sais c'est bizarrre mais bon

par **zeus** » 22 sept. 2008, 16:37

il vaut mieux, et de loin, une table avec 80 champs de 1 caractère qu'une table de 1 champ de 80 caractères, c'est une règle de base.

Chaque champ doit contenir une données simple (vs composée de plusieurs données) afin que tout traitement SQL portant sur cette données soit simple.

Imaginons que le 5eme caractère soit un critère de recherche souvent utilisé dans le WHERE.
Avec ta solution (cad extraire le 5ème caractère du champ), MySQL va devoir remonter toute la table, extraire le caractère sur le 5ème champ, le tester et retourner les lignes qui correspondent.
Avec la solution standard (cad prendre la valeur dans le 5eme champ), MySQL optimise la requête en restraignant directement le choix sur les lignes voulues.

Et si tu veux mettre un index pour améliorer les performances, avec ta solution, c'est tout simplement impossible.

Voilà pourquoi il vaut mieux suivre les standards et créer beaucoup de champ, plutôt que de mettre en place des bidouillage pour gagner quelques champs.
Surtout qu'utiliser 80 champs de 1 caractères au lieu de 1 champs de 80 caractères n'est pas significativement plus lourd pour la base, mais infiniment plus rapide en traitement.

par **dunbar** » 22 sept. 2008, 16:15

Ou comment faire compliqué quand on peut faire simple

Je préfère une BDD bien faite que l'utilisation de "stratagèmes"

Tu pourrais développer stp
Et plus particulièrement ci tu avait à faire une table qui comprendrait 40 Champs.

[Note : ce message a été posté de manière anonyme avant d'être réattribué à son auteur]

par **Truc** » 22 sept. 2008, 10:21

....
L'autre solution consisteraità utiliser les expressions régulières de MySQL pour dire que tu veux les chaines commençant par 'OM26A' et obligatoirement suivi d'au moins un caractère alpabétique en minuscule...
...
HTH
Salut,

Je suis tout a fait d'accord avec toi, et comme j'ai une tare sur les expressions régulières, j'ajouterai que l'on peut s'en passer en gardant la même idée de conception mais en utilisant la fonction length de MySQL. Ici on testera seulement la présence d'au moins un caractère (et non pas minuscule), mais dans ce cas ça devrait faire l'affaire!

A+

Rv

Ou comment faire compliqué quand on peut faire simple

Je préfère une BDD bien faite que l'utilisation de "stratagèmes"

par **Invité** » 20 sept. 2008, 11:34

....
L'autre solution consisteraità utiliser les expressions régulières de MySQL pour dire que tu veux les chaines commençant par 'OM26A' et obligatoirement suivi d'au moins un caractère alpabétique en minuscule...
...
HTH

Salut,

Je suis tout a fait d'accord avec toi, et comme j'ai une tare sur les expressions régulières, j'ajouterai que l'on peut s'en passer en gardant la même idée de conception mais en utilisant la fonction length de MySQL. Ici on testera seulement la présence d'au moins un caractère (et non pas minuscule), mais dans ce cas ça devrait faire l'affaire!

A+

Rv

par **dunbar** » 20 sept. 2008, 10:44

edition question stupide

par **Ryle** » 20 sept. 2008, 10:12

Un LIKE sans joker, c'est possible, dans le jargon technique on appel ça communément un égal

Et autant le = va pouvoir se baser sur les index pour satisfaire ta requête rapidement, autant le LIKE (avec ou sans joker) va devoir se fader à chaque fois un fullscan de ta table...

Maitenant je comprend pas bien ton problème... si le numéro de ton prof est OM26A et que tu fais un LIKE 'OM26A%' il ne te retournera que les valeur commençant par OM26A... s'il te retourne tous les OM26, c'est que t'a oublié de coller le "A" dans le numéro du prof....

En revanche, un 'OM26A%' te retournera également le OM26a. Tu peux éviter cela de plusieurs manières. La première, c'est que par défaut MySQL est insensible à la casse pour certains type de champ. Cela peut se modifier, de manière à ce que 'OM26A' et 'OM26a' soient bien 2 chaines différentes (comme c'est le cas dans toute bonne bdd digne de ce nom

)
L'autre solution consisteraità utiliser les expressions régulières de MySQL pour dire que tu veux les chaines commençant par 'OM26A' et obligatoirement suivi d'au moins un caractère alpabétique en minuscule...

HTH

Clause LIKE

Répondre

Étendre la vue Revue du sujet : Clause LIKE