A partir de combien d'enregistrements virer MySQL ? - Divers - Programmation
Marsh Posté le 06-07-2004 à 15:53:45
Ca dépend beaucoup de opérations que tu souhaites faire sur tes tables : tri, recherche multi critères, ...
Marsh Posté le 06-07-2004 à 15:54:29
d'après ce que j'ai lu, le nombre d'enregistrement est limité à la capacité de stockage du disque.
par contre, question performance, je ne sais pas comment ça se comporte. pour info, ce forum tourne sous MySQL, et ça tient
Marsh Posté le 06-07-2004 à 15:57:54
Tout dépend la charge et le type d'opération que tu fais sur la table. Sachant qu'un index peut changer les perfs de manière assez impressionnante. Quand à migrer de mysql vers oracle ...
Marsh Posté le 06-07-2004 à 15:58:06
l'espace disque n'est plus un probleme aujourd hui,avec 120Go on a de l'avance je crois .
noldor>> y'a tout ca oué: tri ,sommes, insertion, modif, extraction ...
Marsh Posté le 06-07-2004 à 15:58:41
DarkLord a écrit : Quand à migrer de mysql vers oracle ... |
faudrait songer a acces alors
Marsh Posté le 06-07-2004 à 15:59:59
veryfree a écrit : l'espace disque n'est plus un probleme aujourd hui,avec 120Go on a de l'avance je crois . |
Moi je te parle de tera octet
sinon faut juste bien faire attention avec les index pis c'est bon
Marsh Posté le 06-07-2004 à 16:03:37
ouais, le volume réel des données, on s'en fout un peu, tant que la complexité des opérations est réduite.
M'enfin MySQL je le virerai au premier enregistrement quand même ....
Marsh Posté le 06-07-2004 à 16:05:20
nraynaud a écrit : ouais, le volume réel des données, on s'en fout un peu, tant que la complexité des opérations est réduite. |
Marsh Posté le 06-07-2004 à 16:08:17
JagStang a écrit : Moi je te parle de tera octet |
les index ne résolvent pas tout, une recherche comme celle-ci va prendre un temps fou, pour peu que tu aies beaucoup de tuples :
select id from matable where B-V<4
maintenant, si tu sais sur quels attributs va porter ta recherche, tu ajoutes un index sur B-V
Marsh Posté le 06-07-2004 à 16:09:05
nraynaud a écrit : M'enfin MySQL je le virerai au premier enregistrement quand même .... |
veux tu bien t'expliquer, s'il te plaît bien?
Marsh Posté le 06-07-2004 à 16:10:34
DarkLord a écrit : veux tu bien t'expliquer, s'il te plaît bien? |
MySQL est décrié car il ne possède(rait) pas toutes les fonctionnalités d'un véritable SGBDR
Marsh Posté le 06-07-2004 à 16:12:10
noldor a écrit : MySQL est décrié car il ne possède(rait) pas toutes les fonctionnalités d'un véritable SGBDR |
so what? A partir du moment où tu n'utilies pas les fonctionnalités en question ...
Marsh Posté le 06-07-2004 à 16:13:21
DarkLord a écrit : so what? A partir du moment où tu n'utilies pas les fonctionnalités en question ... |
oui, tout à fait si on est conscient des limites et qu'elles ne nous gênent pas, y a pas de probleme
j'essayais juste de deviner la pensée de nraynaud
Marsh Posté le 06-07-2004 à 16:13:49
DarkLord a écrit : veux tu bien t'expliquer, s'il te plaît bien? |
MySQL c'est génial. D'ailleur je me pogne dessus toutes les nuits.
Marsh Posté le 06-07-2004 à 20:55:35
bon j'ai appris que chez wanadoo il avait plus de 10 fois ce qu'on a et que ca tourne niquel.
en fait ils doivent avoir des centaines de millions d'entrés donc le prob viens de cet outils codé avec les pieds ( et quej e doit maintenir )
Marsh Posté le 06-07-2004 à 21:15:15
DarkLord a écrit : Quand à migrer de mysql vers oracle ... |
Dans ce sens là, ça va, c'est assez facile... MySQL supportant peu de choses que Oracle ne supporte pas, tandis que le contraire est impressionnant, je préfère MySQL -> Oracle plutôt que Oracle -> MySQL... Là ca demande redéveloppement intégral de l'application...
Marsh Posté le 06-07-2004 à 21:54:33
nraynaud a écrit : MySQL c'est génial. D'ailleur je me pogne dessus toutes les nuits. |
il me semblait bien
Marsh Posté le 06-07-2004 à 21:57:30
DarkLord a écrit : so what? A partir du moment où tu n'utilies pas les fonctionnalités en question ... |
Ouais mais bon, la corruption des tables ou des index en MySQL, ça arrive quand même plus souvent qu'avec d'autres. Que tu utilises des fonctions avancées ou pas
Marsh Posté le 07-07-2004 à 00:48:16
gizmo a écrit : Ouais mais bon, la corruption des tables ou des index en MySQL, ça arrive quand même plus souvent qu'avec d'autres. Que tu utilises des fonctions avancées ou pas |
Bof, au taff la dernière fois qu'on a redémarré le serveur Unix, ça a fait "proutch".
Datafile altéré dans la base Oracle...
On sait pas trop si c'est Oracle qui a merdé ou SunOS, mais en tout cas l'admin avait suivit la procédure normale...
Heuresement qu'on est des malins et qu'on avait fait un backup juste avant
Marsh Posté le 07-07-2004 à 10:02:39
gizmo a écrit : Ouais mais bon, la corruption des tables ou des index en MySQL, ça arrive quand même plus souvent qu'avec d'autres. Que tu utilises des fonctions avancées ou pas |
jamais eu ce genre de problème.
Marsh Posté le 06-07-2004 à 15:52:40
yo,
au taf on tourne sur mysql et y'a un table qui contiens plus d'un millions d'enregistrements maintenant.
Vous savez jusqu a combien monte ce forum ?
et a partir de quoi faut pensé a migrer vers autre chose?
et ce serait quoi ce autre chose, Oracle?
Merci de m'eclairer