60

57> c'est dans l'esprit "nombre plus vite que texte" que j'ai séparé mes noms dans une table séparée en reniflant qu'il y avait un intéret, mais je me suis trouvé con pour les remettre ensemble dans le select, d'où ma question ^^

Ce topic est intéressant smile

Où en est mysql sur le plan de la performance comparée avec les autres? c'est étudié ou les entreprises s'en fichent?

je viens de tester

SELECT log.* , users.login
FROM log, users
WHERE users.id = log.userid
AND NOT (
TYPE = "info"
)


et
top et en plus c'est vraiment moins dur que ce que je croyais. Il me manquait juste la syntaxe de FROM smile

61

le SQL de base est assez simple, le truc c'est que souvent tu dois faire plein de choses avec du simple cheeky (après, tu as toujours la possibilité de faire comme les feignansses : bosser 50% en SQL et 50% en scripting avec des tableaux, mais c'est pas très jojo ^^)
Rapport aux performances de mySQL, il y a des études, on en trouve un peu partout... ça reste quand même derrière un truc comme Oracle, mais c'est pas fait non plus pour faire le même travail ni pour le même public. Les solutions payantes sont souvent un tel investissement que pour une utilisation courante, on préfèrera rester sur une solution gratuite. Mais dès que tu travailles avec d'énormes charges, des réplications, etc. c'est pas dimensionné pour. Cela dit, il y a des gens plus experts que moi dans le domaine, donc je leur laisse la parole ^^
avatar

62

Faut dire qu'à 17500 euros / processeur la licence Oracle Standard Edition, c'est difficilement quelque chose d'orienté grand public ^^

63

Mais il me semble que MySQL 5 est pas vraiment a la rue compare a oracle (si on restreint oracle aux memes fonctionnalites de MySQL)

64

(Par contre, il faut voir qu'après Oracle est beaucoup diffusé sous forme de runtimes pour applications Client/Serveur, donc on peut disposer d'un serveur Oracle dédié à une application précise, mais dont on ne paye pas autant que les 17500 € ^^)
avatar

65

et si t'as une base oracle sur un quadriopteron tu payes... 70k€? eeek

66

squalyl
: 57> c'est dans l'esprit "nombre plus vite que texte" que j'ai séparé mes noms dans une table séparée en reniflant qu'il y avait un intéret,

Non ça par contre c'est très con tongue
avatar
I'm on a boat motherfucker, don't you ever forget

67

c'est vrai?

rends moi moins con alors: c'est pas plus rapide de chercher dans une colonne qui est un entier que dans une colonne TEXT? ou tu veux te foutre de ma geule une fois de plus?

68

non mais tu fais ta table avec tes trois champs je vois pas le problème confus

explique moi quelle requete serait plus rapide en séparant les tables
avatar
I'm on a boat motherfucker, don't you ever forget

69

(squalyl a spécifié qu'il n'avait jamais fait de SQL en passant happy)
(oui, c'est vrai... en fait, le problème de performance est un problème de choix d'index ou de critère de recherche, mais de construction de la table en elle-même... là, en séparant ta table en deux, tu crées une jointure pour rien, or une jointure, c'est du temps de calcul en plus)
avatar

70

Nil :

(squalyl a spécifié qu'il n'avait jamais fait de SQL en passant smile2.gif )


Oui mais il a aussi dit qu'il pensait que ce serait plus rapide en faisant ce qu'il fait, mais je comprends pas pourquoi il aurait bien pu penser ça parce que je ne vois aucun exemple où on pourrait le penser.
avatar
I'm on a boat motherfucker, don't you ever forget

71

Parce qu'il y a eu une remarque (de spectras ? vince ?) concernant le fait qu'une recherche avec des nombres était plus rapide... donc il a essayé un truc cheeky
avatar

72

oui mais je veux dire, quand ta table est réunie, elle a aussi un index avec des nombres (et donc trois champs) confus
avatar
I'm on a boat motherfucker, don't you ever forget

73

le but c'est économiser de la place parce que mon serveur perso c'est un celeron 600 avec un dur de 20 gigas et pas un cluster oracle.

la table est un log de news et qu'elle contient à peu près 10000 lignes en ce moment.

alors comme c'est pas critique pour le temps je préfère virer de la redondance et utiliser un INT(2) à la place d'un VARCHAR(128)

Ceci dit il me semblait que chercher une chaine (avec strcmp?)était plus long qu'un nombre mais là je peux me planter (c'est le cas on dirait. elles sont hachées les chaines?)

je suis pas trop sûr du fonctionnement d'un index, je vois ça comme un tableau de pointeurs vers les différentes lignes c'est ça?

74

On est d'accord que ton idée initiale c'était deux tables (id, time) et (id, title), avec id étant les même dans les deux tables ?
Je ne vois pas quelle place tu gagnes par rapport à (id, time, title). Tu en perds, même. Et tu perds aussi du temps.
avatar
I'm on a boat motherfucker, don't you ever forget

75

à priori tout le monde est d'accord mais personne ne se comprends...

Il ne faut pas faire :

Première table "noms" Id
Nom
1toto
2boo

Seconde table "prénoms" Id
Prenom
1tata
2@


Ca tue les perfs à cause de la jointure (qui souvent ne sont pas aussi performantes sur la durée à cause de la config du cache toussa) et on se prends en plus de la redondance d'infos (l'ID)


Il faut faire :

Table "personnes" Id
NomPrenom
1tototata
2boo@


Ca garantit une table intègre, et les données d'une entité peuvent être consultées en un seul select sur une seule table "SELECT * FROM `personnes` ORDER BY `Nom` ASCENDING LIMIT 1,100"


Dans le cadre d'une table de news, on peut en effet très bien avoir une chose de la sorte:

Table "auteurs" Id
NomPrenom
1tototata
2boo@

Table "news" Id
TitreDateId_auteurTexte
1Carnet Rose25/12/00001En judée, nombre de record en cette nuit du 25/12/0000
2Titre pourri12/12/20421Texte aussi pourri que le titre
3Autre titre naze06/06/20062Moi aussi je fais des news
Petite note : sur un grand nombre de SGBD, il est préférable de mettre le/les champ(s) de taille variable en fin, ça augmente sensiblement les perfs sur les actions de recherche (sur une des colonnes fixes situées devant elle grâce au fait que l'offset est fixe) et de jointure

Alors, pour récupérer les news, il suffira de faire "SELECT a.Titre, a.Date, a.texte, b.nom, b.prenom FROM `news` as a, `auteurs` as b WHERE a.id_auteur=b.id ORDER by a.date ASCENDING LIMIT 1,100" et ça donnera qqch du genre :
a.Titre
a.Datea.texteb.nomb.prenom
Carnet Rose25/12/0000En judée, nombre de record en cette nuit du 25/12/0000tototata
Autre titre naze06/06/2006Moi aussi je fais des newsboo@
Titre pourri12/12/2042Texte aussi pourri que le titretotototo




NOTE : par rapport au topic de l'open, faites comme à l'époque, des tableaux et tout de suite, c'est plus clair ^^
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

76

cross avec moumou mais bon ça prouve que c'était nécessaire de clarifier les choses

pour les requètes, je ne les ais pas testées mais bon ça devrait marcher sur mysql
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

77

bien vu, vince. Le premier cas rouge je comprends bien que c'est débile, on factorise ID et on peut tout mettre dans une table.

je suis dans le 2 e.

Typiquement une table qui contient des infos utilisateurs complètes (pas que le nom évidemment...) dont un numéro ID en index primaire et un login et d'autres trucs dont je me fous pour le moment , donc je les ai pas mentionnés dans mon exemple au début, j'aurais du, désolé;

et une 2e table qui est un log et qui contient que le numéro de l'utilisateur qui a fait l'action. Pas besoin de recopier 3000 fois le login dans un champ de la table log, ça fait double emploi vu qu'il est déja stocké dans la table des users.

bref, j'me comprends, merci pour le coup de la liste de tables dans la clause FROM je pensais qu'on pouvait en mettre qu'une! Ca permet énormément de choses que j'imaginais pas en sql!

78

squalyl
: et une 2e table qui est un log et qui contient que le numéro de l'utilisateur qui a fait l'action. Pas besoin de recopier 3000 fois le login dans un champ de la table log, ça fait double emploi vu qu'il est déja stocké dans la table des users.

Dans ce, cas, tu devrais donner aussi un index numérique (qui servira de clé primaire) à ta table de logs. (je ne sais pas si tu le fais ou pas, mais c'est juste une remarque, comme tu ne l'as pas précisé ici (peut être plus haut mais je ne me rappelle plus))
avatar
I'm on a boat motherfucker, don't you ever forget

79

oui, je mets toujours une clé primaire autoincrement dans mes tables, même si je m'en sers pas smile

80

pour revenir à la question sur les perfs, j'ai entendu plusieurs fois que contrairement à ce qu'on peut penser, MySQL n'a rien à envier à Oracle tant que les bases sont d'une taille raisonnable (< ~2go ?)
avatar
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez par ici :)

81

Ca dépends de l'utilisation, mais pour des sites webs par exemple, mysql est en effet plus souple et plus réactif que oracle par contre niveau outils, c'est clair que y'a du retard coté mysql mais ça vient progressivement
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

82

mais bon larry ellison ça a l'air d'être un bon gros connard (pas au niveau business mais au niveau personnel) donc bon c'est un argument (complètement irrationnel) pour ne pas utiliser oracle ^^
avatar
I'm on a boat motherfucker, don't you ever forget

83

squalyl :
et si t'as une base oracle sur un quadriopteron tu payes... 70k€? eeek

Ben......oui.
Et si tu l'as sur un SunFire 25k, ça fait mal aux fesses (jusqu'à 72 ultrasparc (dual-core + dual-thread, mais la licence oracle n'en compte que 72 malgré ça)).

84

Ca concerne uniquement les entreprises qui peuvent se le payer de toute façon.

Et les performances sont VRAIMENT au rendez vous? j'imagine pas le genre de bases qui peuvent nécessiter un truc pareil smile (j'ai beaucoup de choses à apprendre en BDD oui)

85

En général t'as pas un seul système qui tourne sur un serveur de ce type. Sur un serveur comme ça tu peux avoir une trentaine de Solaris et 5 ou 6 GNU/Linux qui tournent en même temps ^^
(imagine un peu un vmware matériel si tu veux; le vrai nom c'est des partitions)

Tout dépend des besoins.

86

Bah typiquement des bases comme des bases de statistiques de consommation chez EDF, des bases de voyages à la SNCF, les informations du recencement national... ce genre de trucs quoi happy
avatar

87

Non, les bases énormes et antédilluvienne sont sur DB2 sur MVS ou GCOS sur mainframe depuis des années et ça n'est pas près de changer...

l'exemple le plus classique : les bases financières ou bancaires pour lesquels la moindre opération atomique génère un set d'enregistrements complexe (un transfert de titre par exemple) et avec des métriques frisant l'irréaliste.
avatar
Webmaster du site Ti-FRv3 (et aussi de DevLynx)
Si moins de monde enculait le système, alors celui ci aurait plus de mal à nous sortir de si grosses merdes !
"L'erreur humaine est humaine"©Nil (2006) // topics/6238-moved-jamais-jaurais-pense-faire-ca

88

vince > je vois et je réalise. J'ai cherché des infos sur les marchés et j'imaginais mal quel genre de bécane pouvait gérer les échanges de titres, toussah. Je vois mieux maintenant grin ça a intérêt à être méga fiable ^^

spectras > j'imagine aussi ce dont tu parles, mais en tant que gros nioob assumé de ce domaine je vois pas encore bien les différences entre ces solutions:

* virtualiser plein de systèmes sur un gros machin multiprocesseur comme ton 72 ultrasparc dualcore hyperthreadé
* partager les systèmes sur un cluster de 72 bécanes contenant un ultrasparc dualcore

c'est les échanges de données entre les systèmes qui comptent? Des interfaces réseau multigigabit seraient un goulet d'étranglement?

89

tiens je viens de tomber sur ce screenshot depuis un autre topic http://www.fabforce.net/dbdesigner4/screenshot_image.php?screenshot=dbd4_ss_simplemodel.png

je remarque un truc, les relations sont construites sur une colonne commune.

Dans mon exemple précédent, je faisais avec les tables:

users: login, uid, [le reste]
log: time, userid, message

select log.time,users.login from log,users where log.userid=users.id

j'imagine que c'est ça une jointure, je mets deux colonnes en commun

une requête qui utilise JOIN ça serait possible et avec quelle syntaxe dans ce cas?

90

un truc comme ca:
select l.time, u.login from log l left join users u on l.userid = u.id
je crois...