Quel base de donne choisir pour de nombreuses connexions
(style site netvibes)
et de preference gratuit
 
merci

postgre parce que si je dis mysql on va me tomber dessus

ouais
 
(ceci dit, postgre a un seul défaut : sa montée en charge digne d'Access 2.0, donc pour un site web chargé c'est pas forcément le meilleur choix )
 
sinon, la question qu'on doit se poser, c'est pas la question de performances.
tu peux prendre une usine à gaz, et faire en sorte d'avoir un paramétrage correct et un serveur digne de ce nom pour pallier aux problèmes de performances.
par contre, une fois ton outils en place, tu ne pourras plus rien faire pour résoudre les problèmes de fonctionnalités manquantes.
 
alors pose-toi plutôt la question de ce dont tu as besoin en terme :
- d'hébergement (quelle plateforme ? serveur dédié ? etc.)
- fonctionnalités du SGBD (PS, triggers, jobs, etc.)
- connectivité (outils sattelites qui doivent accéder à la base, réplication inter-site, etc.)
- administration (personnes qualifiées pour administrer et tuner la base, etc.)
 
bref, que tu doives utiliser un P200MMX avec 32 Mo EDO ou à un Quadri Xeon 5GHz 32 Go de DDR-2 pour avoir le même résultat, c'est bien la dernière des questions à se poser. Ce n'est qu'une question de budget mineur par rapport aux coups de développement et maintenance qu'impliquent une mauvaise décision causée par l'ignorance des 4 autres questions fondamentales (et il y en a d'autres)

pour rappel, le site de Microsoft par exemple, était très longtemps codé en ASP et utilisais massivement des bases Access 2.0 pour certains éléments dynamiques (j'en sais quelquechose, j'ai écris des templates de pages pour ce site au début de ma carrière).
Pourtant, Microsoft.com est certainement le second site le plus consulté au monde après Google, et l'ASP certainement une des technos les moins robustes et rapides du marché (sans parler d'Access 2.0).
Preuve qu'à partir du moment où la solution technique répond aux besoin, on peut sans problème répondre aux exigences de performances. Une ferme de 6000 serveurs derniers cris, ça coûte toujours moins cher qu'une rupturede service suivie d'une refonde totale de l'outil informatique à cause d'une limitation fonctionnelle qui impose de tout recommencer.

- Ca n'est pas forcément de vrai nombreuses connexions, ca peux etre son appli qui à de nombreuses visiteurs simultanés, mais en fait ton appli ne va ouvrir que quelques connexions au sgbd.
 
- Mysql à un avantage, c'est le mode non transactionnel. Si tu n'à pas besoin des transactions, dans ce cas mysql est le plus rapide de tous les SGBD parce qu'il n'à pas besoin de gérer les transactions, c'est aussi possible cependant d'utiliser mysql en mode transactionnel.
 
- La pluspart des SGBD actuels sont très performants, donc la vrai question c'est combiens de ram du peux dédier au SGBD sur ton serveur, plus tu as de ram plus tu aura de cache ram moins ton SGBD aura besoin d'accèder au disque et plus il sera performant. En clair il va y avoir une énorme différence entre un serveur dédié puissant avec 6 giga de ram et un serveur mutualisé fatigué avec 250 Mo de ram.  
 
Pour choisir un SGBD tu as un comparatif des SGBD en français ici : http://fadace.developpez.com/sgbdcmp/

Sinon tu peux aussi regarder IBM DB2 Universal Database Express-C ou Oracle Express Edition
[gout personnel]je préfère la 1ere[/gout personnel]

C'est comme je disais, tu as probablement pas besoin de transactions, tu as besoin de ram pour tout stocker en ram, donc la soluce c'est RAM + MySQL.
 

En effet, dans ton cas MySQL semble plutôt préconisé, étant donné que :
1/ Il est en effet parmi les SGBD les plus rapides
2/ Le volume de données (en nombre de lignes) peut rapidement grossir, ce qui n'est pas un problème pour MySQL
3/ T'as aucun traîtement complexe, donc le moteur pourri de MySQL ne sera pas pris au dépourvu.

Curieux. Pour quelle utilisation ?

pourquoi tu utilise pas un cookie ?

et aussi pour les gens qui ont plusieurs PC (boulot, perso, cyber café, etc.)

 
je veux bien mais ça parlait de s'inscrire pour sauvegarder
 
qui dit inscription dit authentification
 
qui dit authentification dit session utilisateur
 
et pour moi, session utilisateur => cookie
 

 
bah je vois pas le rapport vu qu'il faudra s'authentifier

m'enfin
 
tu utilise les 2 exactement comme le forum, y'a déjà d'autres sites qui font ça, et ils utilisent des cookies

et tu peux utiliser les cookies pour les deux, ça sert à rien de tout coller en session ou de devoir lire une table à chaque fois
 
et j'ai jamais dit QUE les cookies

ben si, parceque imagine qu'il a 25 000 bidules que t'as mis 3 plombes à tout bien organiser sur ton PC de bureau.
tu rentres chez toi, faut repasser 25 plombes pour tout remettre en place.
 
c'est comme les couleurs perso du forum, ta signature du forum ou autre : tu les règles une fois pour toute, et une fois que c'est en base, tu les retrouves sur n'importe quel PC, t'as juste à te loguer, pas à refaire tous tes règlages...

flo_053 tu as raison en base de données c'est mieux. Ca prends beaucoup plus de ressources SGBD certe, mais c'est fiable.
 

(t'ain j'avais pas lu le reste... y'a un de ces paquet de noeuds dans ce que vous dites les gars )
 
Bon, déjà :
authentification => session = FAUX
session => cookie = A MOITIE FAUX
 
Pour le premier en effet, .NET par exemple (mais c'est pas le seul, puisque Java et PHP le permettent aussi) peut conserver les informations de session non pas en session, mais en variable de POST ou de GET(via formulaire caché et déclenché sur tous les liens), l'uri ou cookie . C'est pas pour rien si tous les éditeurs de serveurs web déconseillent TRES GRANDEMENT l'utilisation de sessions car trop consommatrices en mémoire/accès disques et autres. C'est parcequ'il existe différents moyens économiques de s'en passer.
 
Pour le second, une session est effectivement identifié chez l'utilisateur par un cookie de session, qui contient (uniquement) son SESSIONID. Ce cookie sera toujours inscrit, même si l'utilisateur désactive ses cookies, car c'est un cookie automatique et non modifiable directement (on peut décider de changer de sessionid, mais en aucun cas forcer sa valeur). Pour le reste, si tu utilises des sessions, c'est justement pour t'affranchir des cookies et autres.
 
Ensuite, ce que veut faire flo_053, c'est visiblement un module qui permet de modifier le layout d'une page, et il veut conserver l'information au cas où le gars revienne.
 
Dans ce cas, y'a pas 36 solutions, mais une seule (avec des variantes)
=> Que l'utilisateur s'enregistre ou non, générer un CLIENTID et lui coller en cookie d'office. En l'abscence de ce cookie, rendre impossible la personnalisation du site.
=> Stocker la valeur de ce cookie en BDD ainsi que les paramètres de positionnement des fenêtres. (*1)
=> Quand l'utilisateur s'enregistre, mettre à jour la ligne qui correspond à son CLIENTID avec son identifiant (champ supplémentaire) (*2)
=> Quand l'utilisateur s'authentifie, forcer son CLIENTID à celui qui est dans la base et qui correspond à son identifiant (*3)
=> Quand tu reçois un CLIENTID en cookie, aller chercher dans la BDD les informations de positionnement et procéder à l'affichage personnalisé. (*4)
 
*1 accessoirement, on peut décider, afin de ne pas polluer la base et devoir faire du ménage régulièrement, de stocker les informations de positionnement dans des cookies. Mais ça va tout de suite être chiant à maintenir, puisqu'il y aura deux sources possibles pour la personnalisation
 
*2 si on a opté pour la solution des cookies avant enregistrement, alors on récupère depuis les cookies les infos de personnalisation pour les stocker en base, puis on efface les cookies (sinon on saura plus où chercher les infos)
 
*3 accessoirement, on peut en même temps stocker les infos de personnalisation en session afin d'économiser des connexions à la base
 
*4 ou chercher les infos en session si elles existent
 
Voilà, avec ce système, n'importe qui peut mettreses fenêtres comme il veut et les retrouver quand il revient. Et s'il est enregistré, quel que soit le PC utilisé, il retrouvera son affichage personnalisé lorsqu'il s'authentifiera.

bein oui un truc dans le genre
 

 
alors là pour moi cookie refusé = cookie pas écrit (avec php en tout cas sans cookie de session ni SID GET/POST il redémarre une nouvelle session à chaque chargement)
 
et la priorité est simple cookie avant et bdd ensuite
 
si le mec se reconnecte ou mets à jour son profil, ça crée un nouveau cookie  (et ça évite de se taper un fichier de session à écrire à chaque page)

Non, le cookie de session est toujours écrit, toujours, même si tu veux pas de cookie, en tout cas avec IIS. Ca c'est plus que sûr et certain, j'avais passé des heures à tester tous les cas quand on a cherché à me convaincre d'utiliser des sessions plutôt que des cookies à mes débuts.
En fait, on peut pas vraiment dire que ce soit un cookie, puisqu'il est invisible dans la collection de cookies quand tu veux le lire. Mais il existe bel et bien, ça c'est sûr et certain. Ensuite, PHP ne sait peut-être pas écrire un cookie de session tel que IIS l'entend...
 
Sinon, le coup de stocker tout le bordel en cookie, perso, j'aime pas du tout parceque :
1/ Y'a plein de gens qui n'acceptent pas les cookies, donc c'est se faire chier pour rien
2/ Selon ton serveur, la session c'est pas forcément un fichier sur le disque (avec IIS par exemple, c'est un objet en mémoire, ou un blob dans une BDD)
3/ Perso, je préfère tout recharger en base à chaque fois : c'est pas plus lent que de transporter 2 Ko de cookies à chaque chargement de page, et au moins t'es sûr d'être toujours à jour (et accessoirement, tu peux modifier les paramètres de l'utilisateur "dans son dos", genre ouvrir automatiquement un élément qu'il aurait fermé, car il y a un nouveau truc à lui afficher)

rho c'est limite mauvaise foi là
 
je vois pas comment IIS pourrait donner forcer mon brouteur à prendre un cookie c'est RFC compliant y'a pas à tortiller (maintenant il est peut être pas modifiable car marqué sécurisé mais un serveur force pas un navigateur à accepter un cookie)
 
1 > les gens qui refusent les cookies > tant pis pour eux, essaye de faire une journée de surf sans cookie tu verras que ça devient obligatoire
 
2 > session en RAM bonjour les emmerdes, sur BDD ça reste un fichier non ?
 
3 > c'est un choix comme un autre, je préfère garder de la ressource parce qu'avoir X lectures pour n'afficher aucune infos (uniquement de la préférence utilisateur en gros là) je trouve ça dommage (et puis avant d'en avoir 2Ko y'aura une bonne marge quand même )