Reprise du message précédent :

Oui je savais mais je croyais quand faisait display:block bah ça n'était plus un élement inline
 
XaT

Bon ca me donne ça :  

 
C'est pas vraiment ce que je voulais mais c'est intéréssant
 
XaT

Les règles css sont uniquement des règles d'affichage et elles ne changent jamais la nature des éléments.
T'imagines le bordel que ça serait pour faire des page (x)html valide si la nature des éléments changeaient tu tout au tout en fonction de la feuille de style utilisé ou de l'absence de feuille de style (option "aucun style" dans firefox par exemple)?

Bah je parlais pas uniquement en CSS, je pensais que y'avais un truc en JS genre onmouseover ou je sais pas quoi
 
XaT

Hello
 
J'ai besoin d'un petit coup de pouce de compatibilité IE !
Je bosse sur ce site en ce moment: http://www.surrenales.com
 
Bien sur y a qques petites différences de rendu sous IE et les autres navigateurs, mais une est particulièrement embêtante, ce sont les sommaires qui prennent toute la largeur qui leur sont disponibles
 
En fait je constate le problème avec n'importe quelle liste ( <ul> dans ce cas ) qui n'adapte pas sa taille à son contenu sous IE mais qui prend toute la place dispo !
En fait rien à voir avec ça, je continue mes recherches, ça a l'air plutot d'etre un probleme de table imbriquées
 
Connaissez vous une astuce pour résoudre ce problème ?
 
Merci bien pour toute aide

Un serveur MySQL peut il héberger plusieurs centaines de bases de données sans problème ? Ou est-ce qu'il risque d'y avoir un problème de perf ? (bon après ça dépend du serveur toussa, mais déjà est-ce que le fait d'héberger les datas de 1000 client dans une seule base équivaut en terme de perf à héberger les datas de 1000 clients dans 1000 bases différentes par exemple ?

Ca dépend.

 
J'ai parié avec moi-même que quelqu'un allait la faire ... j'ai gagné
 
Et encore, pour pas trop mettre sur la voie j'ai du changer mon texte
 
J'avais écris "vaut il mieux héberger 1 client dans 1000 tables ou 1000 clients dans 1 table"

Ah ou sinon y'a aussi la possibilité de :
 
1 BDD => 1000 * X tables avec un prefix different par client

et 40 bdd => 25 * X tables ?

Oui aussi
 
Enfin bref, quel est la meilleur solution quoi

Fort de mon expertise du monde en général, je dirais le juste milieu

Merci de ton aide précieuse, je ne sais pas comment j'aurais fait sans toi

A l'avenir, contente toi d'un MP

lolilol, je veux faire un <textarea> qui s'étire en fonction du contenu via JS (jamais de scrollbar, en gros), je galère actuellement, c'est possible ou je laisse tomber ?

Il me semble que MD fait justement ce genre de chose, pour la modification de messages.

http://kmichel.info/bdel/balls <-- pour ceux que ça peut intéresser de voir si on peut faire de la 3D en js/html, j'lai retouchée un peu et viré 2 bottlenecks (le zsort et la modif de style via css) c'est vachement moins lent sous ffx mais pas encore ça (webkit est fillrate-limited à coté ...)

euh, lolilol?

 
Ben quoi, quand tu code un forum, tu fais pas une table par topic avec un préfixe différent par table ?

si si. D'ailleurs un site d'expert appelé TDWTF est tellement impressionné par mon taf qu'ils envisagent une série spéciale sur une semaine.

 
t'as recompilé mysql pour augmenter le nombre de tables par bases, t'arrivait plus à créer de nouveaux posts  ?

Plutôt rapide sous opera !
Attends, je vais tester avec un vieux portable avec ff3b5 et opera 9.5b2    
 
Mais, en gros, c'est le software renderer ré-inventé ! A quand une API Javascript exploitant nos cartes 3D ?
 
Edit : ha ben ouais ! C'est beaucoup plus rapide sous Opera ! \o/

exact test

edit : c'est juste à l'ouverture du message, calculé coté serveur, ça se fait pas en temps réel.

edit/2 : j'étais persuadé que PhpMyAdmin le faisait mais je retrouve plus où

 
Elle existe déjà, suffit de faire un ptit applet java qui charge jogl+rhino et offre un callback pour faire passer une grosse chaine de caractère, cette chaine est passée à rhino coté java qui l'évalue, et voila, t'as du javascript avec accès à tout les packages java, donc à la 3D accélérée, au son etc..

 
Nan mais c'est bon hein, c'était juste pour compléter l'énumération des possibilité

oui nan mais 1000 bases c'est encore plus lolilol hein.

 
Pourquoi ?
 
Je vois pas ce qu'il y a d'illogique à ce qu'un client ait sa propre base T'es franchement lourd avec des phrases à la con et tes smileys qui ne valent pas mieux. Ça te trouerait le cul d'argumenter ? Quitte à rien dire autant fermer sa gueule non ?
 
Si je pose la question c'est que je ne sais pas quelle est la meilleure solution, tu crois qu'un "lolilol" va m'aider ?
 
Et comme je l'ai dis, je ne vois pas pourquoi créer une BDD pour chaque client serait pas faisable.

http://en.wikipedia.org/wiki/Partition_(database)
 
Naturellement, c'est mieux quand la db est suffisament intelligente pour gérer ça toute seule

une piste de réflexion serait de savoir si une majorité des informations sont susceptible d'être commune a l'ensemble de tes clients, si c'est pour que ce soit quasi identique mais dans des bases différentes alors bof. Encore qu'un mix des deux est surement possible.
Aussi savoir si tes clients ont ou doivent avoir un accès direct a la base, je suppose que non mais bon...
Et est ce qu'a un moment tu risques de devoir recouper les informations de tes différents clients.
Sinon en terme de perfs qqu'un s'est surement amusé a faire une comparaison, je suis assez curieux si qqu'un trouve un article, c'est un débat qui revient souvent.

Non mais tu causes sérieusement en plus?
Tu veux pas aussi déployer une nouvelle version de ton appli à chaque nouveau client tant que t'y es?
Et les données qui n'ont pas de rapport avec le client, tu les dupliques dans une nouvelle base à chaque nouveau client pour pouvoir continuer à faire des jointures?
Tu te rends compte du bordel pour administrer une horreur pareille?

Dénormaliser un peu pour améliorer les perfs avec quelques tables qui sémantiquement font doublon ok, si on peut éviter c'est mieux mais c'est tout à fait défendable, mais faire n'importe-quoi à ce point je ne pensais quand même pas avoir besoin d'argumenter...

oui, voilà. C'est pas le boulot du programmeur, ce genre d'optis, pour moi, même si je conçois qu'on puisse vouloir le faire pour gagner des perfs quand le moteur du sgbd ne le fait pas...

 
Aucune information ne sera commune entre les clients.

...et si ça vous parait pas évident qu'on ne crée pas une nouvelle base à chaque nouveau client, arrêtez la conception, putain. Ou alors n'infligez jamais la maintenance à personne d'autre.

 
Quel rapport ? Tous les forums tourneront sous le même script, mais chacun aura ses propre catégories, ses propres membres, ses propres posts, ses propres permissions ...

hein?
Mais tu as quoi dans ta base, là? Explique, parce-que dans ce cas c'est plusieurs instances de la même appli que tu veux faire, pas une appli avec plusieurs utilisateurs.

Contexte très particulier, dans ce cas. Ce n'est plus une seule appli, ce sont plusieurs instances de la même appli qui dans ce cas précis utilisent le même script.

[edit]

...et tu ajoutes au-dessus de ça une appli pour toutes les gérer.

Sauf quand tu utilises une DB poorie qui le gère pas genre MySQL
 
Après, c'est clairement une optimisation, donc un truc qu'on considère quand les perfs actuelles sont largement insuffisantes et que les autres optims (caches, dénormalisations basiques, ...) sont insuffisantes pour atteindre les performances nécessaires

 
Je n'ai jamais dis le contraire, moi tout ce que je voulais savoir c'est si c'est mauvais pour les perfs d'héberger 1000+ base de données sur un même serveur
 
Ou s'il vaut mieux 1 seule base de données avec les datas de 1000+ clients mélangées mais avec un identifiant par client.
 
L'avantage des BDD séparées et que s'il y a une couille dans l'une, les 999 autres sites fonctionnent encore, dans le cas contraire, tous les sites tombent.

 
ya énormément de paramètres à prendre en compte, là.
 
1) Sous mysql (puisque c'est ta cible), il se passe quoi quand tu fais ça? Augmentation du nombre de process, de la conso mémoire pour chaque nouvelle base?
2) Quel serveur?
3) Quelle volumétrie envisagée pour chaque base?
4) Quel impact sur les requêtes (en éclatant les bases tu vires des jointures)?
 
Puis t'as pas mal de questions annexes :
 
5) Complexité d'administration / sauvegardes?
6) Complexité du code php commun?
7) Il se passe quoi si le serveur ne supporte plus l'ajout d'une nouvelle base?
...

j'ai beau réfléchir j'arrive pas à trouver un seul avantage au fait d'avoir tant de bases...on m'a tjs appris que si t'en viens à te demander comment créer plusieurs centaines de tables pour résoudre ton problème, c'est que t'as mal posé la question
 
quand tu vois aussi que les bonnes pratiques de dev te poussent à avoir des environnement de dev, d'intégration, de test, de valid/recette, de maintenance, de prod, soit 4-5 environnements, si tu as 1000 bases je te laisse calculer la complexité du bordel à administrer...