Discussion :

[Yunie68]

Bonjour,

Je viens vers vous car dans le cadre du développement d'un projet,je me trouve face a des interrogations au sujets des bases de données.

Je souhaite développer un site internet comportant un forum, des utilisateurs et des événements. A terme le nombre de messages, d'évènements et d'utilisateurs pourrait bien devenir très important.

Les utilisateurs pourront télécharger des photos sur le site ce qui représente surement un volume très important également.

Sauriez vous m'éclairer sur le type de structure à utiliser? une seule base de données avec des tables pour chaque type d'éléments (utilisateurs, évènements etc.) ou cela sera t-il trop volumineux et donc pas assez performant?

Quelle sont les ordres de grandeur de ce genre de bases? Car je ne sais absolument pas vers où me diriger au niveau de l'hébergement à cause de cette histoire de capacité.

Je vous remercie d'avance et vous souhaite une agréable journée.

[StringBuilder]

Cela dépend avant tout du SGBD.

Avec l'épouvantable MySQL, je ne saurais donner de réponse précise... Une bonne tambouille avec une base de données par mois d'activité et une table par heure, ça pourrait presque être la meilleure solution (aïe ça y est, je me suis vomi dessus).

Avec un SGBD digne de ce nom (SQL Server, PostgreSQL, Oracle, etc.) pas d'hésitation possible : une unique base de données avec tout dedans, agencé proprement dans des tables bien modélisées, dans les règles de l'art.

Sinon, la volumétrie... Ca dépend surtout de ce qu'il va y avoir dans la base...

Compter "en moyenne" 200 octets par lignes de chaque table (c'est déjà pas mal).
Compter "en moyenne" 500 octets par message.
Compter "en moyenne" 50 Ko à 100 Ko par image (à condition qu'elle soit redimensionnée et compressée, sinon ça peut aussi être 50 Mo)

Donc après pour 100 utilisateurs, dont 25 actifs qui postent 5 message par jour et 2 photos par semaine, au bout d'un an, on arrive à :

100 * 200 + 365 * 25 * 5 * 500 + 365 * 25 * 2/7 * 50000 = 20000 + 22812500 + 130000000 = 152832500 octets = 152 Mo

C'est donc très petit.

Après, faut voir après modélisation et en jouant sur les paramètres (nombre de users, messages/users, etc.) On peut parfaitement aussi arriver à plusieurs Go par jour...

[Yunie68]

Merci de ta réponse,

Il me semble qu'OVH propose un abonnement de 500Go avec du SQL serveur, quelqu'un peut confirmer ce choix?

[SQLpro]

Merci de ta réponse,

Il me semble qu'OVH propose un abonnement de 500Go avec du SQL serveur, quelqu'un peut confirmer ce choix?

Pourquoi ne pas utiliser alors directement SQL AZURE ? Fournit par MS et sans doute moins cher et plus fiable (redondé sur 3 serveurs).
http://azure.microsoft.com/fr-fr/?WT...gle_FRAzureBG_

A +

[Yunie68]

Effectivement, je ne connaissais pas du tout, je n'ai encore jamais eu à chercher un SGBD donc je découvre un peu.

Par contre il n'y a pas de nom de domaine inclut dans l'offre je pense, donc enfaite c'est simplement un espace de stockage de base de données? ou je peux y mettre mes fichiers web également?

Une des caractéristiques annoncées ne me parle pas du tout cela dit, "Unités de débit de base de données" c'est en gros sa performance de réponse?


Merci bien de votre aide

[DotNetMatt]

Sur Azure tu payes pour ce que tu utilises. Donc le principe c'est d'optimiser les dépenses. A moins d'avoir un budget conséquent tous les mois, stocker les images dans une base SQL sur Azure n'est pas une bonne idée car le coût du stockage en base (+ les I/O) est plus élevé que le coût du stockage sous forme de blob, avec Azure Storage.

Azure Storage ce n'est pas juste un genre de disque dur ou tu envoies tes fichiers. Ca combine le stockage de fichiers, sous forme de blob ou sous forme de table (un peu à la sauce NoSQL, sans avoir les contraintes d'un SGBDR). Microsoft a publié lors de la DotNetConf 2015 une vidéo où ils expliquent que le forum du site dédié à Halo a été migré sur Azure Storage entièrement (https://channel9.msdn.com/Events/dot...ebsite-Evolved à partir de 24:40). Ils expliquent aussi la structure qu'ils ont utilisé.

Donc tu peux envisager un scénario où tu utilises SQL Azure pour stocker les données du forum sans les images (juste avec les meta données des images comme leur chemin par exemple) + Azure Storage pour stocker les images.
Tu peux aussi envisager de n'utiliser que Azure Storage.
Ou tu peux n'utiliser que SQL Azure si tu as le budget en conséquence.

Voilà le message à retenir c'est surtout "attention à la facture"