SQL ou non-SQL ?

Raleur Pro X

Membre confirmé
6 Mai 2005
50
1
56
Bonjour,

Pour un projet je souhaiterais developper une application qui devrait être performante,
en utilisant

- une base de données
relativement peu de données (99,9 pct du texte), mais potentiellement beaucoup de records
- serveur web avec une interface à la base de données
- mailing vers les 'clients' , donc un serveur de messagerie est nécessaire
- un serveur RAID Apple :rolleyes: Xserve G5, ou un powermac dual avec deux disques en RAID

Ce qui n'est pas souhaitable, est un délais pour obtenir une réponse;

J'ai de l'expérience en Filemaker, mais il semblerait que le serveur ne peut avoir que 250 clients en même temps ou 100 via l'internet. Il se peut que cela soit suffisant dans un premier temps, mais je préfère quelque chose de évolutif... pour ne pas gaspiller mon énergie et mon argent (Filemaker Pro Serveur n'est pas si bon marché..)
Il faut dire que la pub du bicycle store sur le site de Filemaker illustre tous les aspects de mon projet (et bien plus), mais comme j'ai déjà écrit mas grande préoccupation sont les performances..

Que me conseillez-vous ?
SQL, mySQL, yourSQL, PostgreSQL,... :confused:

Equipement ? Quelle serveur pour le mail ? (en plus l'application doit pouvoir envoyer les emails de façon autonome..)

Autre chose, je ne me rappèle plus rien de SQL, j'imagine que cela reviendra très vite, cependant je repartirai à zéro... Le projet devrait être terminé fin février de préférence, cela veut y compris le testing..

Merci beaucoup pour votre aide ! ;)
 
A mon avis, mais ça n'engage que moi, le rapport simplicité/performances joue en faveur de MySQL. Ce n'est pas compliqué à exploiter en utilisant le PHP (qui permet d'envoyer des mails de manière automatique).
 
Anabys a dit:
A mon avis, mais ça n'engage que moi, le rapport simplicité/performances joue en faveur de MySQL. Ce n'est pas compliqué à exploiter en utilisant le PHP (qui permet d'envoyer des mails de manière automatique).
Moi aussi! :rateau: :D

Marc-André
 
yourSQL n'est qu'une interface pour mySQL, rien de plus

PostGreSQL moi j'aime bien mais j'utiliserais plutot SQLLite pour un projet facile à transporter (la base de données est stockée directement dans des fichiers textes).
 
Anabys a dit:
A mon avis, mais ça n'engage que moi, le rapport simplicité/performances joue en faveur de MySQL. Ce n'est pas compliqué à exploiter en utilisant le PHP (qui permet d'envoyer des mails de manière automatique).

Je clarifie, ce sont des emails du serveur vers les clients, et non des emails style "form" de l'utilisateur vers l'email du fournisseur de service...

Est-ce qu'on peut faire cela avec php ?? ;-) ??

Merci beaucoup..
 
geoffrey a dit:
yourSQL n'est qu'une interface pour mySQL, rien de plus

PostGreSQL moi j'aime bien mais j'utiliserais plutot SQLLite pour un projet facile à transporter (la base de données est stockée directement dans des fichiers textes).

Merci beaucoup je vais jetter un coeup d'oeil sur SQLLite...
 
Bien sûr ! PHP est exécuté côté serveur, tu peux donc envoyer des mails depuis le serveur vers le client, si la dépendance sendmail est satisfaite (le phpinfo() te donnera cette indication).

Il y a tout plein d'articles à ce sujet sur internet. Le premier truc que j'ai trouvé sur google en tapant "php mail lib" me paraît intéressant pour toi, il s'agit d'une classe qui se charge de tout. C'est par ici.
 
MySQL necessite un daemon qui tourne, SQLLite non. MySQL est tout de meme plus difficile à configurer que SQLLite.

Maintenant avec PHP, c'est clair que MySQL s'impose.
 
Raleur Pro X a dit:
- une base de données
relativement peu de données (99,9 pct du texte), mais potentiellement beaucoup de records
Tout dépend de ce que t'appelles "beaucoup de records" et surtout ce que tu fais avec !

Si tu fais juste des SELECT simple, même avec quelques centaines de milliers de records, je doute que tu voies une différence notoire entre les différents SGBD cités. Si tu fais des multiples jointures et autres requêtes imbriquées faites sur des tables de plusieurs dizaines de records et surtout que ton programme nécessite vraiment d'être rapide, alors là, il vaut peut-être mieux regarder de plus près. Dans mes souvenirs, je sais que PostgreSQL était plus rapide pour des gros trucs, mais MySQL a dû pas mal s'améliorer à présent.

Ensuite, il faut aussi voir combien de fois tu vas exécuter ton programme ? Si ton script tourne une fois par semaine seulement, qu'il mette 20 min ou 1h, est-ce bien grave ?
Autre chose, tu as l'air de parler d'e-mails. Est-ce que tu souhaites faire des envois massifs de courriers (newsletter) ? Si oui, je pense que tu seras d'abord limité par le serveur SMTP qui va limiter le nombre d'envoi par minute pour éviter le spam, plutôt que par le SGBD.

Ah oui et j'oubliais, si tu dois vraiment optimiser le temps d'exécution, utilise à bon escient les primary key et les index (très important), et lis bien la doc du SGBD, parfois il y a des conseils sur l'optimisation des requêtes. (dernièrement j'ai optimisé une requête de 30 min à 60 secondes simplement en suivant les conseils du SGBD)
 
Merci beaucoup, je pense que je vais me concentrer sur mySQL, parce que j'ai trouvé quelques livres qui traitent du sujet, en particulier la combinaison avec php, avec des examples pour faire des mailings et/ou un site de commerce électronique...

Merci beaucoup pour les conseils !!! :up:
 
MySQL est très bon dans la plupart des cas, cependant, on peut envisager PostgreSQL dans le cas ou les requêtes sont complexes.

Si le site est très gros, tu peux essayer firebird qui est gratuit également.

Et si c'est vraiment énorme, c'est vers Oracle qu'il faut aller, mais je doute que tu aies besoin de tels moyens.