Faut dire qu'à 17500 euros / processeur la licence Oracle Standard Edition, c'est difficilement quelque chose d'orienté grand public ^^
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)
Nil Le 03/08/2006 à 17:17 (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 € ^^)
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?
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?
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.
I'm on a boat motherfucker, don't you ever forget
vince Le 03/08/2006 à 22:15 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
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!
Zeph Le 04/08/2006 à 00:06 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 ?)
All right. Keep doing whatever it is you think you're doing.
------------------------------------------
Besoin d'aide sur le site ? Essayez
par ici :)
vince Le 04/08/2006 à 00:17 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
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 ^^
I'm on a boat motherfucker, don't you ever forget
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.
vince Le 04/08/2006 à 16:40 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.
un truc comme ca:
select l.time, u.login from log l left join users u on l.userid = u.id
je crois...