Reprise du message précédent :

 
moi je vais avoir des moultes jointures mais sur 3-4 niveau maximum..
et puis qu'un gars aille footre ses pates dans la bdd il en est hors de question! tout dois passer par ma librairie d'administration putain     (c'est le genre de truc qui me fait cauchemarder qu'un pov type bidouille la bdd.. )
 
mais bon.. ça me fait peur ce que vous dites tous sur mysql..  

 
la classe

   
 
pkoi protected ??? package protected ok, mais protected tout cour ?

 
L'interface me semblait un peu trop barbare, vu qu'il n'y aurait qu'une implem de l'interface.

 
ben chaipas j'aimerais comprendre la logique derriere tout ca : visiblement ca rends mon constructeur non visible en dehors du package, ce qui resoud mon pb, mais heuh ? Pour moi protected n'a pas (/ne devrait pas avoir)cette signification, je doit etre tout empetré dans mon C++

sinon ...
 
peut être qu'une inner classe static public avec un constructeur privé, ca marcherait

contrairement à l'idée reçue, protected c'est pas seulement visible depuis les sous-classes, mais aussi depuis les classes du même package ...

 
ah ben ok (j'etais donc bien empetré dans mon C++)

mais bon, en pratique c'est pas une bonne idée d'utilise ce truc juqtement parce que c'est plutot "innatendu"
 
c'est pour ca que j'étais   devant la proposition de -- de passer le construcetur en protected...

Y'a une raison a avoir boudé le concept de "friend" en java ?
 
(et perso je trouve ca quand meme moyen le coup du protected visible depuis tous le package)

jveux des explication sur ce que vous avez dit sur mysql!
 
 

Y peuvent pas !
C'est un fatra de on-dit et de préjugés.

je suis d'accord ...
 
sinon, pour friends ... je me souviens plus bien ...
ca rend la classe accessible à une autre classe, c'est bien ca ?
 
dans ce cas, ca veut dire qu'il faut connaitre au moment où tu écris la classe quelles sont les classes qui vont l'utilise ... c'est pas forcément évident  
 
et si y a moyen de rendre une classe friendly à postériori, dans ce cas là, c'est pas bcp mieux que le package protected

 
c'est bien ce que je pensais..    
 
je vois pas pourquoi ils ont peur de mysql..
enfin bref..
 
merci de me rassurer maras.. enfin plutot, merci de me guider sur le chemin de la vérité

en ce qui concerne les limitations: pas de vues, procédures stockées ou triggers, support des requêtes imbriquées limité (au select je crois, à partir de la 4.1), support SQL lui-même est plus ou moins limité (le UNION n'est possible qu'à partir de la 4.0)
 
Pour la gestion des relations (clés étrangères, tout ça) et des transactions, il faut que tu configures ton serveur toi-même pour que ça marche (tables InnoDB) voilà.

messieur dame bonjour

"messieurs dames"
 

 
nan pas exactement
 

(oublie pas qu'en C++ on a pas de package)
 
pratique dans certains cas  vu qu'avec la combo constructeur privé + friend tu restreint l'instantation a une seule classe

 
je comprend pas mais je pense que ça ne me sera pas utile.. donc spa grave  
 

 
j'utiliserais la toute derniere.. à savoir la 4.0.16  
et des que la 4.1 ne sera plus en beta je l'utiliserais  
 

 
ah ça j'en aurais pas besoin  
 
 
 
 
me voila rassuré!    
merci drasche  
 
(et je suis content parceque je m'apperçoi que mysql ça bouge beaucoup.. les version s'enchainent vite.. c'est cool)

Quoi ? Tu sais pas c'que ça veut dire ? Dès que t'as plusieurs utilisateurs qui effectuent des requêtes, bah les perfs dégringolent.. Bien sûr je parle pas de requêtes bidon style SELECT name, age FROM user WHERE age > 20
 

triggers, stored procedure, vues par exemple..
 
Je suis 1 mois en vacances le 4 décembre, j'm'étais fait une liste d'article à rédiger, je crois qu'un article sur les perfs de mysql comparé à d'autre SGDB est prévu.. Enfin, entre ce que je compte faire et ce que je dis, il peut y avoir une grande marge donc qui vivra verra
 

 
En fait tout dépends de ce dont tu as besoin.
 
Le principal avantage de MySql pour moi, c'est qu'il n'est pas nécessaire d'embaucher un DBA pour assurer le fonctionnement quotidien du serveur.
En revanche c'est le cas pour Sql Server, Oracle, et c'est presque vrai aussi pour Postgres. Pour ce dernier on peut s'en sortir avec quelques scripts de nettoyage, mais faut quand même aller voir de temps en temps si tout va bien.
 
Maintenant, si t'as des milliers de transactions par secondes sur des centaines de tables avec des triggers, des procédures stockées, des vérification d'intégrité, des transactions..., ben laisse tomber MySql. Si t'est courageux et fauché se sera Postgres, sinon Oracle ou même, à la limite SqlServer, mais vraiement si c'est pas possible d'avoir Oracle Et de toute façon, pour avoir des perfs, faut pas se leurer, la BDD ne fait pas tout. Il faut quand même du matos solide CPU(*), RAM(***), DISQUES/INTERFACES, REZO...

(personnelement je capte pas comment fais une bdd pour aller rechercher aussi rapidement les infos demandées)

 
nan mais ok.. gnaaarg je sais..
 
c'est normal que les perfs baissent en fonction du nombre de requetes.. mais jveux savoir à quel point..

Ah oui, y'a aussi FireBird (basé sur Interbase) qui est gratos, perso c'est ce que j'utilise même s'il est un peu chiant pour l'écriture des requêtes parce qu'il est très (trop ?) strict, enfin c'est pas plus mal

Moi je sens bien que nraynaud va te répondre avec tout des mots compliqués que y'a que lui qui comprend  

Tout stocké dans xGo de RAM !

ouais! tout stocker dans des HEAP tables

 
 
             
 
PS:  
nan j'aurais pas de triggers (meme si ça a l'air allechant)
pas de Procédures stockées.. ça c'est trop bourrin.. on peu pas mettre un gars en + à 100% sur la bdd..
 
les transactions aussi c'est hyper allechant sa race.. mais bon c'est quand meme rouller en rolls alors qu'on en a pas les moyens.. ça demande trop de boulot..
 
enfin pas pour l'instant tout ça..
je vais donc me contenter de mysql..
 
par la suite, si notre projet de develloppe bien.. on embauchera un bdd master et tout.. mais pas pour l'instant..
 
merci mara's..    
 
 
 
PS: on aura une putain de machine pour gerer la bdd donc stout bon avec sa race de ram cadencée à sa race de hertz! avec un HDD 10000trmin..

ouais, c'est bien ce dont je me souvenais (même si je l'ai mal exprimé).
 
et t'en penses quoi de ma remarque ? (qu'il faut connaitre à l'avance les classes qui vont utiliser cette fonction) Tu trouves pas que ca va un peu à l'encontre de la réutilisabilité de la classe ?

ps :
 
http://www.linuxfrench.net/rubriqu [...] brique=102
trop bien expliqué..  

 
bah, c'est tres rare qu'une classe ait besoin d'acceder aux fonctions private de l'autre, generalement quand tu fais ca c'est que t'as un design derriere, donc normalement tu connais les classes ayant besoins d'etre marquée comme amie.....
(Evidemment si plus tard ca venait a changer y'a risque d'avoir l'air con)
(ceci dit le friend fais pas l'unanimité, loin de la )

(et après mouinmouin va venir se plaindre que ça cause pas assez technique )

 
Pour baisser le niveau, je propose de poster des images de femmes nues

c'est ça
pis après tu vas encore te plaindre que tu te prends un ban

Dites, ya quoi comme possibilité de sauvegarde fréquente de la base avec mysql?
Mon boss voudrait savoir ce qu'on peut faire pour reprendre au plus vite le taf en cas d'incident...

-Bonjour je voudrais prolonger la location de mon appart
-votre nom ?
-chrisbk
-hummmm, le loyer de novembre, il est payé ?
 

 

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.

Bon, on oublie je crois...

 
ça va

 
j'y retourne

Urd-sama> c'est "pipes" et "habitudes alimentaires" ensemble que t'a fait quoter???