Zodd

Salut, peux-tu coller la structure exacte de ta/tes tables mysql ? Car c'est un peu flou là A+

Ne fonctionne pas enfin si mais le JS s'éxécute pas

Salut c'est pas con du tout je vais tester cette solution ce soir De plus y a pas le prob du Javascript désactivé vu que s'il est désactivé la bannière ne s'affichera de toute façon pas Merci à toi Zodd

Ce sont des bannières qui doivent être a un cartain endroit dans la page, en fin de page ca va pas

Bonjour, J'affiche des pubs pour une de mes régie publicitaire. Ces pubs sont du JS. Le problème c'est que parfois (comme actuellement en fait), leur serveur plante. Ce qui fait que le script JS qui fait appel a une page de leur serveur, plante lui aussi et c'est tout mes sites ayant leur tag qui bloque à l'endroit où se trouve le tag JS, et donc le site de vient inutilisable. Y a t-il moyen de contourner ce probleme? J'ai bien pensez à mettre des iframes, mais c'est un peu porcasse, et pas sûr que la régie accepte, car avec un Iframe ca sous entend que l'on peut afficher ça sur n'importe quel autre site pas forcément validé par la régie en question.... Bref Des solutions???? (A part changer de régie ) Merci Zodd

Peut-être que ton serveur est blacklisté. C'est un dédié?

Ok merci ca me rassure A+

Bonjour, pour l'un de mes site, je cache des calques avec du javascript, mais c'est purement dans un but fonctionnel, et au chargement de la page les calques sont visibles c'est un JS qui les cache. ( document.getElementById('envoi_ami').style.display='none'; ) En fait j'affiche à l'aide de JS certains calques et lorsqu'on clique sur un bouton le contenu change sans rechargement de page. C'est une fonction très appréciée des internautes. Surtout lorsque la page contient une vidéo, c'est gavant de devoir recharger la page. Est-ce que google pousse le vice jusqu'à scruter le code JS ? Ce n'est pas dans un but de tromperie des moteurs de recherche que je fais ca, c'est assez contraignant si google foure son nez la où ca ne le regarde pas! Merci

Hihi sans doute... moi de mon coté j'essaie de m'appliquer dans mon travail et parfois même de trop. Mon point de vue est peut-être faussé pour la raison que tu cites, je suis l'analyste et le concepteur dans ma boite. Donc je dénormalise directement car je connais à l'avance les contraintes matérielles. Et puis a force de créer des bases de données qui se ressembles souvent sur certains points (l'exemple clients/rue/ville/pays reviens souvent), on commence à agir par réflexe. Zodd

j'avais édité mon reply cp + ville + pays

Pourtant si on met cp et ville et pays dans la même table --> redondance de données possible, me trompe-je ?

Le rapport est qu'ils aurait pu faire une table "Localités" histoire d'économiser de la place, et de normaliser au max mais il ne l'ont pas fait car dans notre cas ce n'est pas vital à la gestion des données. Donne moi le nom de ton hébergeur que je n'y aille pas. Il y a plein d'hébergeur en mutu pour lesquels tu as du 500Mo pour une bouchée de pains... et puis même 50Ko sur 100 mo y a de la marge. Et rare sont les membres habitant la même rue, donc même si ta DB est 100% normalisée, peut de chance de gagner plus de quelques milliers d'octets.... et encore... à moins que la france entière s'y est inscrite. Lorsque j'ai présenté mon travail de fin, d'étude, j'avais tout normalisé. clients, fournisseurs adresses, (se rapportant a client ou fournisseur) rues, villes pays (se rapportant a adresse). La première remarque d'un des membre du juri est le pourquoi la séparation en plusieurs tables (rue ville pays etc..). Ma réponse : pour normaliser au max Sa réponse : Ca risque de poser des prob de performances si il ya beaucoup de client/ adresses etc... Et il avait raison. Ma requête prenait plus d'une seconde. avec peut d'enregistrements.... Zodd L'analyste peut aussi faire preuve de bon sens, en général l'analyse connais le but final d'un projet, et donc peut sur base de ca décider de normaliser ou dénorméliser certaines choses. En effet nous n'avons pas la même conception.

Ce que je listais ce sont des exemples de tables liées justement pour illustrer un exemple de cas dans lequel on va dénormaliser certaines données.

Encore une fois, j'ai bien précisé "Si ce n'est pas vital". A partir du moment où c'est le membre qui entre son adresse, quel importance que la rue va se répéter 3 ou 4 fois? A moins que ton site c'est mappy.com, ou que tu comptes faire des statistiques par rue, ou quelques chose du genre, je n'en vois pas l'intérêt. Economiser de la place? Si tu as 10000 membres, tu vas gagner quoi? 50Ko? même pas? A l'heure des DD de 200Go je pense qu'on optera pour la performance plutôt que l'espace disque utilisé. Sur ce forum par exemple, la ville est un champ libre. Et pourtant Invision board c'est pas un forum de merde je crois. Zodd

Ah bon? et comme ça c'est le merdier pour modifier tout ce qui concerne cette modification, un peu partout dans le code, Les dénormalisations se décident au début aussi, et non à la fin (de la programmation). En toute logique une fois le MCD établi, on peut facilement imaginer combien de jointures certaines requêtes demanderaient, et avec un peu d'expérience, se dire qu'a partir d'un certains nombre de jointures et en fonction du nombre d'enregistrements prévus dans chaque table, si cela fera ramer ou non le serveur. Quand tu as une requête SQL sur 5 ou 6 tables, Exemple de tables liées susceptibles d'être appelées parallèlement avec des jointures : "personne" "metier" "rue" "ville" "pays" "code_postal" Cela fait 6 tables. Un peu beaucoup... surtout si il y a des milliers de rues, des milliers de personnes etc... Ce genre de prévisions, on peut facilement les faire au début (en phase d'analyse) et donc à ce moment là décider de dénormaliser un peu. Par exemple pays ville cp et rue dans la même table (c'est ce qui se fait couramment). Cela fera des répétitions certe, mais il faut voir aussi si la séparation est vitale dans le projet en question. Tout ça se pense au début et non à la fin de la programmation... sinon c'est sujet à de multiples bugs imprévus, qui auraient pu être évités + perte de temps..... et donc d'argent! Zodd