Bonjour,
Il paraît qu'il existe une version "lite" de MySQL. Je n'en sais pas plus, et j'aimerais savoir, si ça existe, si c'est basé sur un simple fichier, à la SQLite, ou s'il faut aussi installer un serveur, combien ça peut supporter en matière de volume de données.
Personnellement, je dois manipuler des bases de plus de 500 Mo. Est-ce que MySQL, que ce soit cette hypothétique version "lite" ou une autre version, pourrait répondre à mes besoins ?
Sachant que les requêtes à effectuer sont généralement assez simples, avec des jointures ne dépassant pas 2 tables. J'ai une grosse table qui contient quelques millions de lignes.

je ne pourrais pas t'en dire plus sur MySQL Lite  ni sur les capacités 'volumiques' de mysql .... (google est ton ami)
Ce qui m'étonnerait en tout cas c'est de voir ce sgbd sans serveur !!  
 
si ca peut élargir ton champ de recherches, PostGreSql est gratuit et opensource et est a mon avis nettement plus puissant que mysql...
 

Je ne voudrais pas trop m'avancer, mais je suppute que 500Mo est tout à fait concevable pour du MySQL, toujours sans m'avancer, je pense que le forum HFR est sur une base MySQL (sinon, pourquoi Joce se surnommerait-il MySQL Gourou ?) et pour finir toujours sans m'avancer, je pense que la base du forum HFR dépasse largement les 500Mo.
Par contre, jamais entendu parler d'un MySQL Lite, en revanche, j'ai testé SQLite et c'est bof, tout la base est géré dans un fichier alors un fichier de 500Mo, ça ne doit pas être terrible à parser.

Je confirme : avec SQLite c'est merdique pour les gros fichiers. Je dirais que 100 Mo est un maximum pour avoir de bonnes performances et pour utiliser les vraies capacités de SQLite. Pour la base de données du forum de Hardware.fr, je suis pas sûr que ça dépasse les 500Mo... Enfin j'en sais rien, mais ça m'étonnerait quoi.
Cette version hypothétique version "lite" me paraît étrange aussi, d'autant plus que j'ai encore rien trouvé sur le site officiel de MySQL.
Je vais faire un tour du côté de PostGre pour voir, suite au prochain numéro.
Par contre, je sais pas encore exactement, mais je pense qu'il me faut un système avec peu d'administration. Je ne suis qu'un petit stagiaire au milieu de cette entreprise, donc je décide pas.
Merci en tout cas !

pour le forum hfr, on dépasse largement les 15Go...
 
Et pour postgres, y a pas non plus de version "lite", mais tout comme MySQL, il consomme très peu de base.

15 Go waw, faut que je revoie mes notions d'espace mémoire    
Bref, j'ai oublié de préciser quelque chose aussi : on bosse en C++, et pour l'instant j'avais réalisé une magnifique classe qui permet de gérer des bases de données SQLite. Bref, si jamais on choisit de prendre PostGreSQL ou MySQL, ou même tout autre SGBD, il faut que je puisse réaliser une classe portable Windows/Linux (2000 et Red Hat 7.1), la tendance actuelle étant à la "déMFCisation". J'ai vu qu'apparemment ya des interfaces en C et en C++ pour PostGre, mais bon, reste à savoir si c'est portable.

En fait la portabilité n'est pas si importante dans nos critères de choix. Postgres m'a vraiment l'air bien en fait. Apparemment il existe une interface graphique pour le backend donc ça devrait aller pour ce qui est administration.

MySQL peut gerer de gros volumes. j'ai eu qq soucis de tables perdues apres qu'elles ait depassées 2Go. Mais rien n'empeche de scinder. Y'a peut-etre une histoire de parametrage à la compilation...

franchement, je plussoie sur PostGre...
depuis la version 8 c nettement plus compatible 'oracle' que MySql, et passé quelques ptits problèmes d'admin au début, tu t'en sortiras ..
et c 200% portable....

Ben justement là j'ai téléchargé la version 8.0.3. Si j'ai bien compris, il faut lancer un des serveurs qui sont fournis avec, puis on peut tenter de se connecter dessus, soit à l'aide de pgAdmin (ce que je vais faire au début, pour effectuer mes tests) soit au moyen d'un truc fait soi-même, et là on peut réaliser toutes les opérations que l'on souhaite, comme dans tout SGBD C/S ?
J'ai essayé de lancer le "postmaster" mais le problème c'est que je n'ai pas de fichier postgres.conf. En fait, lors de l'installation, il ne m'a carrément pas créé le répertoire data qui est censé contenir ce fichier de conf.
Vous savez où je peux en récupérer un ? Ou alors, pouvez-vous m'indiquer comment le créer (paramètres à indiquer, syntaxe à utiliser, etc) ?

tu es sous quel OS?

Windows 2000

Pourquoi ils en fournissent pas un à la base ? Parce qu'en plus, j'ai regardé sur le site officiel, et je ne trouve pas d'exemple, ou d'explication sur les variables à y mettre, etc.
En plus je viens de m'apercevoir qu'il y a d'autres fichiers de conf, que je n'ai pas non plus : pg_hba.conf et pg_ident.conf.

sur windows t'as juste à lancer l'installeur et il te fait tout tout seul. Après soit tu as demandé qu'il install PgSQL en service et il sera lancé au prochain démarrage (ou alors tu le fais manuellement) soit tu vas simplement dans le menu PostgreSQL et il te démarre le tout comme un grand, avec tout ce qu'il faut pour être déjà opérationnel.

J'ai trouvé un fichier postgresql.conf mais ça m'a l'air foireux :
Quand je lance postmaster, il me sort cette erreur :
FATAL:  unrecognized configuration parameter "tcpip_socket"
J'ai pourtant cherché sur le net, et il faut bien ce paramètre de configuration...

Je lui ai pas demandé de l'installer en tant que service justement, et à l'aide du menu, ben c'est foireux...
Bon je vais le réinstaller, je pense que j'ai du faire une connerie, c'est pas possible sinon.
Edit :
Après réinstallation, toujours rien...
J'ai essayé de lancer la base à l'aide de Démarrer->programmes->postgresql->lancez la base de données, puis j'ai essayé de m'y connecter avec pgAdmin, mais ça ne marche toujours pas. Pire, quand il y a une erreur lors de la connexion avec pgAdmin, il ne m'affiche même plus le détail de l'erreur...

        Ouf j'ai enfin réussi à l'aide d'un tutorial à créer une BD.
Voici l'URL, qui m'a été très fortement utile :
http://techer.pascal.free.fr/postg [...] /ch03.html
 
J'arrive maintenant à me connecter au serveur, il m'envoie plus chier, je peux faire tout ce que je veux, c'est la fête !
Bref, le sage a dit : Face à la difficulté, ne jamais abandonner tu devras  

Par contre, je comprends pas à quoi servent les "schémas"

Vive le monologue...
Les schémas, c'est la structure de la BD

oui, je sais, sur un autre forum on m'a dit que je faisais un one man show... Mais bon, fallait voir la durée qui s'écoulait entre le moment où tu postais et la première réponse.
Si j'ai bien compris, les tables que je veux créer, je les crée dans le schéma "public" ?
Et là, c'est le drame : les blobs n'existent pas avec Postgres... Il y a bien les types bytea et oid, mais faut stocker dans un fichier à part, ce qui risque d'être très lourd : je peux avoir des millions de blob dans une table  

gni?
 
Non, au contraire, faut essayer de ne rien mettre dans le schema public, faut essayer de ranger au maximum ce qu'on crée.
Et pour les bytea sont bien stockés dans la DB, pas dans des fichiers à part. Mais en général, on y regarde à deux fois avant de mettre des données binaires dans une DB...
 
EDIT: et les oid n'ont rien à voir, ce sont juste des identifiants de ligne, et il ne faut pas trop compter dessus.

Oulà ok j'ai encore des progrès à faire. Les bytea sont stockés dans la base, ben c'est parfait alors. Je sais bien qu'il vaut mieux y regarder à deux fois avant de mettre des données binaires dans une BD, mais là j'ai pas le choix. C'est pas pour stocker des images ou autre. C'est des trucs qui peuvent faire quasiment rien en taille, mais ça peut aller jusqu'à 16Ko.
En fait, si jamais j'arrive à trouver une interface C ou C++ pour manipuler des bases Postgres, je pourrai faire une requête de ce genre : sprintf (szBuf, "INSERT INTO truc (donneesbinaires) VALUES ('%s')", mes_donnees_binaires_sous_forme_de_char_*);
???
(Tout ceci en faisant gaffe bien sûr à ce que ma chaîne de char ne contienne pas de \0 intempestif).
EDIT : j'ai renommé le sujet, qui ne correspondait plus du tout au sujet initial

Autre problème :
Je voudrais me servir de libpqxx, mais au niveau de la compiltaion, ça passe pas. On a donc installé Cygwin, téléchargé la libpqxx, décompressé libpqxx dans le répertoire Cygwin, puis tenté un configure. On a d'abord eu droit au "je trouve pas pg_config", j'ai donc spécifié où il se trouvait en argument de configure, et là il me sort ça :
 
checking for pg_config... C:\Program Files\PostgreSQL\8.0\bin\pg_config.exe
./configure: line 1: C:\Program: command not found
configure: using PostgreSQL headers at
./configure: line 1: C:\Program: command not found
configure: using PostgreSQL libraries at
checking for ANSI C header files... (cached) yes
checking ability to compile programs using the standard C library... yes
checking /libpq-fe.h usability... no
checking /libpq-fe.h presence... no
checking for /libpq-fe.h... no
configure: error:
Can't find libpq-fe.h in .  Are you sure the libpq
headers are installed correctly?  They should be in the directory returned by
"pg_config --includedir".
 
If you do have libpq (the C-language client library for PostgreSQL) installed,
make sure you have the related development materials--mainly its header files--
as well as the library binary.  Some system distributions keep the two in
seperate packages with names like "alibrary" and "alibrary-dev", respectively.
In that case, make sure you have the latter installed as well.
 
 
Or le répertoire retourné par pg_config --includedir contient bien les headers. Qu'est-ce que c'est que ce merdier ?

Truc simple.
 
N'importe quel SGBD supportera sans aucun problème 500 Mo (même Access, c'est pour dire).
 
La taille n'a donc pas d'importance.
 
Ensuite, en comptant sur un minimum d'optimisation, et une machine à peut près correctement dimensionnée, toujours en partant de ces 500 Mo, le problème de performances devrait être assez restreint.
 
Reste donc la véritable question, qui ne s'est pas encore posée dans ce topic je crois : de quels mécanismes as-tu besoin dans ta base ?
 
En effet, selon ce dont tu as besoin, Access peut s'avérer mieu que MySQL ou PostGRE, et vice-versa.
 
Si t'as besoin juste de faire des requêtes "simples", pas de PS, ni trigger ni rien, alors MySQL semble le meilleur choix, puisque ne te limitera en rien, et sera le plus léger/rapide des trois.
Si t'as besoin de faire des requêtes complexes, sans pour autant utiliser de PS/Triggers, alors Access est un tout aussi bon choix que PostGRE, alors que MySQL est à bannir immédiatement, à moins que tu tentes le coup d'utiliser une version béta.
 
Ensuite, si t'as besoin d'utiliser des fonctionnalités avancées des SGBD, telles que les PS, Triggers, etc., à ce moment, il ne reste plus que PostGRE.
 
A noter, vu que tu es sous Windows 2000, qu'il existe aussi MSDE, notamment la version 2005, qui est basée sur SQL Server 2005, qui sera, dans tous les cas, ce que tu pourras trouver de mieu en gratuit.
 
Ensuite, l'histoire de base stand-alone, genre SQLLite, oublie. Chacune des bases citées dans ce topic s'installent en 2 minutes sur n'importe quel tromblon, y compris sur des OS "workstation", c'est à dire ne nécessitent pas de "serveur" à proprement parler. A partir de là, aucun intérêt d'utiliser un base mono-poste merdique, qui n'apporteras rien, et au contraire te privera de toute évolutivité de ton soft.

De part mon experience personnelle, MySQL est plus performant que PostgreSQl. J'ai eu a faire un choix il y a 3 ans entre les deux et j'ai tranché en faveur de MySQL pour des raison de performances meilleures et de crash recovery plus aisé a implementer. Le support egalement est meilleur en cas de probleme specifique (les delais et pertinences des reponses etaient très competitifs, et la doc très claire!).Cependant, j'ai une plus grande experience sur MySQL et mon avis peut etre un peu biaisé. Les gros moins etaient au niveau des procedures stockés, des triggers et des UDF qui n'existaient pas, mais aujourd'hui cela semble reglé avec les version 4.1!

Merci pour ces réponses, mais je suis maintenant bien lancé dans Postgres, qui m'a l'air très bien : j'ai laissé tombé libpqxx (interface C++) pour libpq, l'interface en C. C'est facile à utiliser, ça répond à mes besoins, et ya pas trop de trucs superflus. Je pense que c'est le plus adapté. SQLite, je l'ai testé. Et il n'était pas question de faire une base par poste : une seule base à laquelle on accède tout simplement grâce à une classe que j'ai crée, il suffit de passer le chemin vers le fichier. Mais c'est vrai que c'est merdique au niveau des perfs, c'est d'ailleurs pourquoi je me suis tourné vers MySQL ou PostgreSQL. Le truc c'est que Postgres s'adapte en fonction de la charge, alors que que MySQL a tendance à se péter un peu la gueule. Je suis pas anti-MySQL, j'aime bien l'utiliser avec du PHP pour des sites internet, mais je pense que Postgres est plus adapté à notre utilisation, même si a priori, je n'aurai pas à utiliser de triggers ou même de PS.
De toute façon, si les perfs ne sont pas satisfaisantes avec Postgres, j'essaierai avec MySQL, et je pourrai me vanter d'avoir testé en l'espace de deux mois tous les SGBD du monde (Bon, j'exagère à peine, mais bon...).

Ma classe qui gère les bases PostgreSQL est maintenant bien avancée, elle est même fonctionnelle : j'arrive à me connecter à une base, à créer ou droper des tables, par contre lors des insertions j'ai un petit problème.
 
Voici la requete de création de ma table :
CREATE TABLE reperes(ind SERIAL PRIMARY KEY, nom VARCHAR(100), lib VARCHAR(100), unite VARCHAR(50), typef INT2, min FLOAT8, max FLOAT8);
 
Et voici mon insert (qui fonctionne si je l'exécute à l'aide de pgAdminIII) :
INSERT INTO reperes (nom, lib, unite, typef, min, max) VALUES ('Repere0', 'libellé repère', 'unité', 0, 0.000000, 0.000000);
 
Voici maintenant la ligne de code qui exécute ma requête :
m_PgResult = PQexec(m_PgConn, szReq);
 
Et voici l'erreur que j'obtiens en récompense :
ERROR:  invalid byte sequence for encoding "UNICODE": 0xe92072
 
Qu'en pensez-vous ? De toute évidence, c'est ma ligne de code qui est foireuse, mais je ne vois pas en quoi.

en somme il faut utiliser MYSQL  
je veux utiliser Vb.net avec une base Mysql  
est ce que c est possible?  
est ce que je dois utiliser des pilotes spéciales?
ou il faut les telechercger ?
et pour migrer d'access vers Mysql comment faire et ou telecharger les logiciels possobles pour faire cette migration?
 
 
mirci

Et bien il ne faut pas se fier aux évidences (et d'ailleurs finalement je trouve que j'ai été très con, et que c'était évidemment pas ma ligne de code qui foirait : UNICODE aurait dû me mettre la puce à l'oreille, mais bon) : en fait c'est que j'avais des accents dans les valeurs de ma requête.

Youpi ça a l'air de marcher, mais comment faire en sorte qu'il prenne les accents ??? Prochain numéro : performances / récupération des données binaires compressées et encodées qui ont été insérées.

 
 
en quel honneur

Essaie de voir s'il y a un type "nvarchar()" comme avec SQL Server : c'est un varchar supportant l'unicode.
 
PAR CONTRE !
 
Si un varchar(100) peut contenir 100 caractères, ce n'est pas le cas d'un nvarchar(100), qui peut ne supporter que 50 caractères !
 
En effet, le jeu de caractères unicode utilise 1 ou 2 octets pour chaque caractères (et même plus si tu utilise de l'UTF-32 par exemple, qui monte à 4 octets !)
 
Par contre, ce qui est étrange, c'est que les éè etc. sont inclus de base dans le jeu de caractères ASCII, et donc supportés sans problème par un varchar().
 
Regarde au niveau de ta class si tu peux pas l'empêcher de bosser en UNICODE (à moins que tu en aies besoin), et utilise plutôt un jeu de caractère ISO, qui est compatible avec le format ASCII (remplacement de la définition des caractères ASCII)

 
Tu as pas l'impression de squatter un topic !
 
Tu as cherché sur le net avant ?
Y'a toutes les réponses à tes questions.

Le nvarchar() n'existe pas, par contre, peut-être qu'un text pourrait régler mon affaire ? Je ne peux pas tester pour l'instant, j'ai mon test de perfs qui tourne, il devrait se terminer d'ici 1h environ si tout se passe bien.
En tout cas, c'est vraiment bizarre que les accents soient pas passés...    
PS : j'osais pas le dire pour le squattage de topic    
EDIT : Arf merde, mon test de perfs s'est pas terminé. Il a planté alors qu'il était fait à presque 75% (en matière de temps)   . Faut savoir que mon test consiste à insérer 8640000 lignes dans une table. Il ne m'en a inséré que 4304500. Il y a une limite avec Postgres ? J'avais pgAdminIII ouvert, connecté au même serveur que celui qui contient ma base, ça peut être à cause de ça ? A moins qu'il y ait un timeout pour les connexions... Auquel cas cela s'expliquerait. Car maintenant que j'y pense, il m'a fait le même coup ce matin, après à peu près la même durée. Je me souviens plus de la magnifique boîte d'erreur que j'ai obtenu, mais il y a marqué ça dans la console qui a lancé mon serveur :  
LOG:  could not receive data from client: Aucune connexion n'a pu Ûtre Útablie car l'ordinateur cible l'a expressÚment refusÚe.
Avec les accents foirés et tout, c'est pas beau ça ?  

Nope, c'est en 5.0. (pour les UDF, je ne sais pas)

MySQL fournit le pilote nécessaire sur son site pour utiliser ADO.NET.

non, y a pas de limite à ce niveau, du moins pas aussi peu. Mais bon, pour une insertion massive, j'ose espérer que tu as utilisé COPY au lieu de INSERT...
 
Pour ton problème avec les accent, c'est vraiment bizare car je n'ai absolument pas ce problème. La locale est bien définie comme étant "C" (pour les latins) ?

Ben non justement je ne fais pas de COPY, le but c'est de tester la rapidité moyenne des INSERT, avec une base telle qu'elle sera lors de sa vraie utilisation. Dans la vraie vie, il n'y aura pas de COPY, juste des insert arrivant un par un d'un peu partout, environ 100 par seconde ! Donc pas question de faire de COPY.
Et les problème des accents, c'est la puissance de l'invite de commandes MS-DOS  

Il est bien pensé ton test? parce que y a une différence entre 100 insert/secondes sur divers connexions et un script qui fout des tas d'insert nettement plus rapidement sur une seule connexion.

Bon mon test, c'est effectivement qu'une seule connexion qui balance la sauce. Mon but est juste de comparer par rapport à ce que j'ai obtenu avec SQLite, dans les mêmes conditions. Et je ne veux pas faire de 100 inserts/s volontairement, je veux voir jusqu'où il peut aller. Le peu que j'ai pu voir, c'était du 700 ins/s environ. Mais il me faut quand même ma base entière pour faire mes tests de select !!!    
bref, je cherche du côté du timeout, mais pour l'instant, rien trouvé...
Ah au fait un truc con : est-ce que les insert sont plus rapides s'ils sont tous regroupés dans une même transaction ou est-ce que c'est pareil, voire plus lent que sans transactions ?
parce qu'avec SQLite, c'est TRES TRES nettement plus rapide avec transaction, car ce con ouvre et ferme une transaction pour chaque insert sinon.