que des features puantes pour datamodel ou client (lire software) foireux quoi.

euh y'a pas a configurer le serveur, si je ne m'abuse, tu peux betement creer ta table genre comme ça "CREATE TABLE (pouepouepouet) type InnoDB;" nan?

Selon la doc de MySQL? Uniquement les Dump
 
Edit: mais comme la notion de transaction leur est un peu étrangère, tu n'as pas de certitude que ton dump est consitant si tu le fais à chaud.

tu peux aussi betement faire une copie des 2 fichiers qui vont bien depuis le disque

ftp://ftp.lip6.fr

tu peux aussi betement faire une copie des 2 fichiers qui vont bien depuis le disque

1/ tu sais que je t'aime toi?
 
 
2/ dans la 3.23 en tout cas: non, en fait tu dois juste mettre les paramètres dans my.ini et puis seulement tu peux. Et j'ai jamais essayé en 4.0 avec une install clean donc je sais pas s'ils ont changé quelque chose à ce sujet.

et l'OS te dira que les fichiers sont lockés donc non, tu ne peux pas

1/ mais encore

2/ ah ok , autant pour moi; enfin c pas la mer à boire non plus

ha. oué. bah tu fais une pause de 3 secondes a 3h du mat, tu copie ton fichier, tu relances, et hop

non rien je vais m'arrêter là

 
1° Y a pas d'heure sur le net
2° Avec une grosse DB, tu mettra nettement plus de 3sec, même avec un rsync
 
 
 
... mais pourquoi je tombe dans ce troll pro MySQL?

non mais j'veux dire, j'ai pas saisi la teneur de tes propos, ironie ou agrément? (euh, cher tous powered, "agreement" quoi)

et, je me repete, SAPdb qui a été opensourcé recemment

6mb/s lorsque je telecharge linux sur free

taiste >
edit : taiste 2 > *CENSURE*

 
je n'ai viré que la sanction injuste, pour contredire chrisbk

Pff, minable
Au boulot j'ai déjà d/l à 8.2 Mo/s, en fait j'étais limité par le réseau local j'suis sûr, Renater powaa

euh oui, le dawa exprimait la connerie de ma suggestion.  
Je m'en doutait, d'où ma remarque...
et sinon, niveau troll, il est plutot du coté du "anti-mysql" non? il a de bons avantages, et les features qui lui manquent sont [a mon humble avis] completement inutiles.
Si tu les trouves inutiles, c'est ton problème, mais laisser une DB sans véritable contrainte référentielle, c'est inacceptable, autant prendre des fichiers excel dans ce cas-là. De même pour les requètes imbriquées.
mtnt, du coté du backup à chaud, effectivement il manque qqchose. mais je n'ai pas vu d'argument contre leur outil qui bloque je ne sais plus quoi (a part un troll deguisé sous la forme d'un "*formidable*" ), ni de démonstration de ce qui se fait de mieux ailleurs en la matière
Bah c'est simple: un dump, ca prend du temps. Leur outil de dump n'est pas transactionnel, donc il peut arriver à sauver une table, passer à une autre, et dans ce laps de temps, il y a eu des modifications dans ces deux tables qui sont liées, et tu te retrouve avec un dump erroné. Et leur système qui implique un lock des tables durant le dump revient exactement à geler la DB pour toute autre utilisation pendant la durée du dump, donc c'est une grosse merde.

 
m'en fous j'ai encore mes smileys ascii

non c'était pas ironique, seulement franc et sincère tellement je suis d'accord avec toi sur ce coup

t'as  aussi les chefs d'oeuvres d'yvelle :
 
 

Zavez vu ? les modos c'est mes hommes de paille, j'en fais ce que j'en veux

Rien que le fait qu'il y ait SAP dans le nom et que MySQL soit derrière me donne pas envie d'aller voir
 

 
hum.. ok c'est bon  
t'as dla chance que jte laisse t'en tirer comme ça hein  
 
   

ha ok
ben alors pq tu mentionnais ces faux problemes de mysql

Bah c'est simple: un dump, ca prend du temps. Leur outil de dump n'est pas transactionnel, donc il peut arriver à sauver une table, passer à une autre, et dans ce laps de temps, il y a eu des modifications dans ces deux tables qui sont liées, et tu te retrouve avec un dump erroné. Et leur système qui implique un lock des tables durant le dump revient exactement à geler la DB pour toute autre utilisation pendant la durée du dump, donc c'est une grosse merde.

retourne te cacher derriere ta poubelle

Si tu les trouves inutiles, c'est ton problème, mais laisser une DB sans véritable contrainte référentielle, c'est inacceptable

Bah c'est simple: un dump, ca prend du temps. Leur outil de dump n'est pas transactionnel, donc il peut arriver à sauver une table, passer à une autre, et dans ce laps de temps, il y a eu des modifications dans ces deux tables qui sont liées, et tu te retrouve avec un dump erroné.  

Et leur système qui implique un lock des tables durant le dump revient exactement à geler la DB pour toute autre utilisation pendant la durée du dump, donc c'est une grosse merde.

démonstration de ce qui se fait de mieux ailleurs en la matière  

juste pour te contredire, je demande ton TT

Juste pour savoir, un truc transactionnel, à part dire aux requêtes d'attendre le temps du backup, il fera quoi de plus qu'un lock de la DB ?

tout dépend du soft que tu as derrière.. evidemment si ta seule interface d'administration c'est une gui qui tape direct dans la db...
(filtre à troll activé: le passage sur les fichiers excel a été enlevé)
 
Leçon n°1 d'un cours sur l'administration de la DB: ne jamais faire confiance aux apis extérieures, quelqu'elles soient
 
j'avais bien compris, merci, prend moi pour un con
 
Et tu trouve que c'est un outil sérieux?
 
 
ce n'est pas optimal mais ça peut dépanner.
 
Si tu as 2 tondus et trois pelés, oui
 
toujours pas de [...]
 cf réponse à Taiche

alors
1/ l'avantage avec mysql justement c'est que t'as pas besoin d'un connard qui passe ses journées à mater que la db va bien. et mon api exterieure, je peux donc y faire confiance
 

 
2/ non, et?
 
bah c'est le seul outil qu'il officiel qu'ils fournissent, l'autre, c'est un script perl que qq'un leur a bidouiller.
 
3/ toujours pas de nom concret de ce qui se fait mieux ailleurs.
 
pg_dump, puiqu'il te faut absolument un nom. Mais tu peux faire la même chose avec presque toutes les autres DB sérieuses.

 
je n'ai viré que la sanction injuste, pour contredire chrisbk

pg_dump