Reprise du message précédent :

20 minutes de retard, ça va sinon?

 
Pourquoi ce champ id dans une table relation ?

pour faire joli.

Merci tout de même
 
Et vous avez un bon logiciel gratuit pour MCDiser tout ça ?

 
l'id de ta table de relation ne sert a rien, tu mets les 2 autres champs comme clée primaire. (a moins que le chien possède plusieurs fois le "même" jouet... mais physiquement, a moins d'avoir un jouet quantique, ce n'est pas possible)

Le mieux c'est de faire un MCD avant la conception, t'oublie moins de truc comme ça. Ne serait ce que dans les propriétés des objets

Moi je mets des id partout pour être sûr de pas avoir de pb à la suppression (DELETE FROM matable WHERE id = ?) ...

Edit après avoir lu le message de Tamahome : Ah oué ok, on peut faire comme ça ...

bah l'id c'est le couple des id de tes 2 tables, là.

euh la en l'occurence, il l'aurait vu dans ses cardinalités

Sinon pour revenir au NDD, comment ça se passe quand :
 
j'ai un NDD avec tel service. Je veux changer de service, mais garder le même NDD, c'est facile à faire ?

oui

Oki ça me va alors

tant mieux

y'en a qui bossent

chais pas, c'est une habitude, c'est vrai que ça sert à rien mais bon, ça fait quoi comme mal ?

ça prend de la place dans la base.

et pis comme en plus j'imagine que tu le déclares en pk ça créé un index pour rien ( donc ralentissement runstat)

Moins y'a de colonnes mieux on se porte.
C'est la même chose que de ne pas écrire trop de code.
 
Principe KISS

comme je m'emmerde et que je connaissais pas the kiss principle ( j'aime beaucoup l'acronyme ceci dit), j'ai cherché sur google... bin kiss tout seul dans google s'pas terrible ... suis tombé sur une belle page plein de photos de springbreak

Sweet    

J'ai que des images du groupe de rock moi

 
google cible les réponses

http://fr.wikipedia.org/wiki/KISS-principe

   il est mignon    
 

http://images.google.fr/images?hl= [...] 7images&gb => 3eme ligne , 1ere image...

 
 
"A standing kiss in a river"  

 
Jusqu'à la 6ème image j'ai pareil que toi, après plus du tout ...

Chez moi 3e ligne 1e colonne c'est
 

 

 
(accessoirement les fullscreens en PNG/32 sur cette daube d'imageshack évite stp, c'est pas que j'ai pas que ça à foutre mais j'ai pas besoin de screenshots de 550ko, surtout quand IS est pas foutu de me les envoyer)

sorry    (en même temps t'avais le poids de marqué sur la miniature hein )

Toujours concernant les structures de BDD, il n'existerait pas une petite page web qui donnerait des recommendations sur les types de champ à utiliser pour tel ou tel type de données ? J'ai du mal à choisir...

Exemple au pif, un code postal ... CHAR(5) ? SMALLINT UNSIGNED ?

Et pourquoi le type de champ "timestamp" ne stocke pas un timestamp ? mais une date au format aaaa-mm-jj hh:mm:ss ...

Edit : Et tant que j'y suis, quand utiliser un TINYTEXT plutôt qu'un VARCHAR(255), et vice-versa...

Edit 2 : Bon, d'après ce que j'ai pu lire, rien ne sert de stocker des chiffres en type numérique s'ils ne sont pas amenés à être utiliser dans des calcul par exemple. Donc pour un code postal, un CHAR(5) devrait faire l'affaire.

le type timestamp (dans mysql) c'est un champ mis à jour automatiquement quand tu fais une update sur le record correspondant.
pour ton code postal, même si il contient des chiffres, ce n'est pas un nombre à proprement parler (la valeur du cp n'a aucun sens mathématique, et un 0 en début de cp est porteur de sens), donc tu prends un CHAR. pense aussi au fait que tous les pays du monde n'ont pas des CP de 5 chiffres (parfois plus, parfois moins, parfois des lettres, etc.)

Edit : Euh par contre pour le timestamp, c'est bien un type de champ, il n'est pas obligatoirement mis à jour automatiquement, sauf si on défini la valeur par défaut à "CURRENT_TIMESTAMP"

j'ai une question dans le même genre : les champs de type binary, ça sert à stocker des fichiers genre des images, non ? Si c'est bien le cas, est-ce que c'est vraiment recommandé ?

c'est pas trop recommander, ca gonfle la taille de la bdd pour pas grand chose ( un lien est plus utile )  
 
mais ca peut etre utile  
 
pour le CP -> varchar ( si tu ne veux pas avoir a rajouter les 0 devant a chaque traitement )

ca peut etre tres utile meme, pour plusieurs raisons :
 
- pas de liens morts : si on a accès a la BDD, on aura acces aux images. Ce qui n'est pas nécéssairement le cas quand on a un serveur de fichier a coté (qui peut etre innaccessible)
- plus facile pour livrer / maintenir : on livre un backup de base, et pas 15000 fichiers séparés. Ca se restaure en une opération, on oublie rien.
- plus facile pour gérer les droits et la sécurité : on sait qui a accés aux données puisque ca vient de la base : on ne tombera jamais dans le cas où un petit malin tape directement l'url de l'image par exemple (cas d'un site web) : ca peut aussi servir d'antileech du coup (dans certains cas, ca dépent comment on code ca bien sur).
 
etc...

T'as un lien pour expliquer ta méthode parce que je suis sceptique là
Et puis tes 15000 images, je préfère les avoir dans un système de fichier plutôt que dans une base de données. Suffit d'avoir la bonne idée de sélectionner plusieurs tuples pour faire ramer la base, ça a l'air top

Si il utilise MySQL <4.1, il n'a pas le choix, sauf à en mettre plusieurs dans la table et seul le premier sera mis à jour systématiquement.

j'ai pas dit le contraire

.. alors ça a changé "depuis le temps"

Ok Je tourne sous MySQL 5 dont pas obligé.

Sinon j'ai un problème avec l'affectation de mes clés étrangères, pour certains ça a marché, mais d'autre j'ai une erreur :

le champs USER_ID de ma table 1 est bien en tout point identique à mon champ ID de ma table 2 ...

Où c'est que ça coince ?

L'erreur :

Et apparemment sa signification est "MySQL error code 150: Foreign key constraint is incorrectly formed" ... mais je vois pas

Edit : 'tain j'ai des tables en MyISAM, je suis sûr que c'est ça, forcément

Bon c'était bien ça, par contre sur mes 9 clés, il y en a toujours une que je n'arrive pas créer, avec la même erreur, mais je ne vois pas pourquoi...
 
Même types de champ, même moteur de base, mais ça veut pas...

Salut tout le monde,
encore un petit problème en css
 
Comme vous pouvez le voir ici, j'ai le titre de mon h2 en plein milieu avec en gros "Le titre de la news ici".
 
Deux problèmes :
1) le background de ce h2 est partie en dessous des deux tableaux au dessus, on peut en voir dépasser un bout sur la droite, et je ne comprend pas pourquoi.
2) le texte écrit en plus petit se superpose à mon titre alors qu'il devrait aller en dessous.
 
Merci

last_news et last_wars sont en float:left
et ca provoque un space bug du fait que le contenu du H2 descend en dessous car il n'a pas la place pour rester, mais le h2 reste en haut.
 
faut un clear:both sur .contenu et basta