bonjour,
quelles sont les bases de données efficaces que je peux utiliser en c++ tout en étant ( mon code ) portable sur windows (je développe sous linux).
merci
Version imprimable
bonjour,
quelles sont les bases de données efficaces que je peux utiliser en c++ tout en étant ( mon code ) portable sur windows (je développe sous linux).
merci
MySQL existe sous Windows et Linux.
ODBC, l'API d'accès aux bases de données existe sous Windows et sous Linux
Donc si on fait la somme de tout : Mysql pour la base de données et ODBC pour l'API d'accès à la base de données
je ne savais meme pas qu'il fallait une api pour acceder a la base de donne.
j ai vue des exempes entre autre pour mysql . ou il me semblai coder directement en c++ pour acceder a la base de donnee...
j ai egalement lue :
Inconvénients de la technologie ODBC
tu en pense quoi ?Citation:
Bien que ODBC permette un interfaçage avec des bases de données indépendamment du SGBD, cette technologie reste une solution propriétaire de Microsoft.
Cela se traduit par une dépendance de la plateforme (ODBC ne fonctionne que sur les plateformes Microsoft Windows). D'autre part, ODBC est fortement lié au langage C (utilisation de pointeurs), et ODBC utilise des paramètres non standards, ce qui le rend difficile à mettre en oeuvre directement dans les programmes.
mysql est sous licence gpl (voir payant)
j ai vue que postgresql et bds. quelqu'un sais si il fonction bien , efficace, difficile a integrer ?
En fait c est quoi l'interet de rajouter une couche avec l odbc ?
Une base de données peut s'accéder de 2 manières différentes :
- soit en natif. Dans ce cas là, tu utilise directement l'API dédiée de la base de données
- soit en utilisant une API standard (ODBC par exemple).
L'avantage du Natif est qu'il est a peu près indépendant de la plateforme (pour MySQL au moins).
L'inconvénient du Natif, c'est que si un jour tu changes de base de données pour utiliser Oracle ou SQL Server par exemple, il faut tout refaire.
ODBC quant à lui est indépendant de la base de données. Il suffit d'avoir les drivers du moteur concerné et cela marche de manière uniforme.
Autre avantage, ODBC pour Oracle ou pour MySQL, c'est pareil vu de l'application. Donc tu as besoin d'apprendre 1 seule fois l'API.
Lu ici
- Cette API, dénommée SQL/CLI pour SQL Call Level Interface a été normalisée aussi bien par l’Organisation internationale de normalisation que par l’institut national américain des standards en 1993 et a été par ailleurs annexée à la norme SQL-92. Cette spécification a été publiée en 1992 sous la dénomination de Microsoft Open DataBase Connectivity (ODBC), mais Microsoft n'en est pas le seul auteur.
- Le terme ODBC est fortement corrélé à la société Microsoft, ce qui pourrait faire croire, à tort, que l’API ODBC est une API propriétaire. N'importe quel fournisseur de bases de données ou de logiciels peut mettre en œuvre cette API, qui est, de facto, disponible sur de très nombreuses plates-formes, et pour de très nombreuses bases de données
- Et enfin, le gestionnaire ODBC est présent sur de nombreuses plates-formes, notamment des plates-formes Microsoft Windows et de type Unix.
Attention toutefois à ne pas oublier que la plupart des bases de données ont leur propre dialecte SQL, et que de ce point de vue là, la portabilité est loin d'être assurée.
Sinon, pour de petites à moyennes base de données, il y a l'option SQLlite, qui a l'avantage d'être plus facile à déployer
[TROLL]
Et entre Mysql et PostgreSQL, je recommanderai plutôt le second
[/TROLL]
C'est vrai, je l'avais oublié celle là.Citation:
Envoyé par white_tentacle
Tu peux argumenter ou c'est vraiment pour troller ?Citation:
Envoyé par white_tentacle
Je peux, mais ce n'est pas le bon forum et ça va partir en troll je pense :).Citation:
Tu peux argumenter ou c'est vraiment pour troller ?
Cela dit, il suffit de regarder ce que pense le fondateur de MySQL de la sortie de la version 5.1 pour voir quelle notion de "qualité" ils ont. L'API C (ou Php) et la manière de construire les requêtes SQL font peur, aussi.
bref pour resumer, si je veux changer de db il faudrait mieux que j utilise une api odbc.
si je veux plustot changer d'os je serai mieux en natif.
avec une api odbc vue que c est standard je ne peux pas a la fois changer d'os et de base de donnee ?. je sais j en demande peux etre beaucoup.
concernant litesql. ou meme les autres. comment definir une petit et moyen base de donnee ? ( je n y connais rien du tout ). Actuellement je me suis fait temporairement une arborescence sur 3 niveau de dossier et dans chaque niveau il y a un fichier d'indexation. C est pas genial dans le concept , mais c est assez simple et fait le job pour l'instant. a titre indicatif.
dans le premier niveau il y aurai entre 3000 et peu etre un jour max 30000 dossier ( autant de ligne dans mon fichier d'index, avec 10 champs d'environ 20 caracteres par ligne).
second niveau il y a entre 2 et 5 dossiers ( un fichier index de 2 a 5 ligne, champ similaire )
et le dernier niveau il y a entre 200 et 400 fichier a utiliser et un fichier d'indexation similaire au autre.
1. ODBC est spécifé par Microsoft mais pas nécessairement "développée" par Microsoft.Citation:
Envoyé par lezurp
2. ODBC existe sous Windows, UNIXs (Linux inclus), Mac et peut-être aussi ailleurs. Je ne connais que ce systèmes.
3. ODBC n'a rien à voir avec le langage C (à part peut-être le fait que "ODBC" soit souvent implémentée en C). ODBC est une spécification d'une API. Il y a des APIs "ODBC" pour le C (C/C++), C# (bref, .NET : ODBC.NET), PHP, ...
4. Utilise des paramètres non standard ? Je n'ai rien compris ...
Encore une raison de choisir ODBC. ODBC a son propre dialecte SQL (qui est biensûr conforme au standard SQL). C'est l'API qui traduit la requête (SQL ODBC) en SQL natif pour la BD. La portabilité est assurée.Citation:
Envoyé par white_tentacle
Avec ODBC, tu peux changer de matériel, de système, ou de base de données sans changer ton programme. Que demander de plus ;) ? Euh ... un tutoriel peut-être : ODBC en C :).Citation:
Envoyé par lezurp
Tu es sûr de ça ?Citation:
Encore une raison de choisir ODBC. ODBC a son propre dialecte SQL (qui est biensûr conforme au standard SQL). C'est l'API qui traduit la requête (SQL ODBC) en SQL natif pour la BD. La portabilité est assurée.
Parce que je l'avais déjà entendu, puis j'ai aussi entendu l'inverse... Est-ce que ce n'est pas plutôt une question que "certains drivers odbc" feraient cette conversion ?
Absolument sûr et certain.
Et dans les remarques sur la fonction SQLExecDirect :Citation:
Envoyé par MSDN
Citation:
Envoyé par MSDN
Hé ben je me coucherais moins idiot ce soir...
Au boulot, Notre projet MFC qui utilise ODBC contient un switch() pour chaque requête un peu compliquée, avec une requête par SGBD supporté par le projet...
Je suis surpris aussi car pour une requête, j'avais été obligé de faire cela aussi car ce n'était pas la même entre SQL Server et MySQL. Je n'ai pas pour habitude de faire ce genre de bricolage si cela n'est pas utile.Citation:
Envoyé par Médinoc
Si j'ai le temps, ce soir je refouillerai dans mes archives pour extirper ce bot de code.
Ça ne me semble pas étonnant... J'ai des doutes quant au fait qu'un pilote odbc puisse réécrire de manière optimale une requête.Citation:
Au boulot, Notre projet MFC qui utilise ODBC contient un switch() pour chaque requête un peu compliquée, avec une requête par SGBD supporté par le projet...
Par contre, dans msdn, je trouve
C'est le "peut" qui m'embête...Citation:
Si nécessaire, le pilote peut convertir la syntaxe SQL standard dans le langage SQL natif de la source de données de destination.
Edit : "this is often limited to replacing escape clauses defined by ODBC with DBMS-specific SQL" --> ça aussi ça m'embête...
C'est surtout le "escape clauses defined by ODBC" que j'aimerais bien connaître.
Car ce qui change le plus entre nos requêtes, c'est la syntaxe pour accéder à une table d'une base donnée (base.table sous Oracle, base..table sous SQL server, base:table sous informix...).
Bah les escape sequences sont décrites ici.
Dans ce cas c'est normal. Le domaine du "ODBC portable", si je ne me trompe pas (mais je ne suis pas tout à fait sûr), c'est lorsque tu te connectes à une source de données qui encapsule une base de données et non un serveur de base de données (mais même dans ce cas, on a toujours une poignée de fonctions totalement portables, mais c'est pas vraiment ça ...). Ce que peut représenter une source de données, c'est défini par le pilote. Mais même avec une connexion à un serveur, les fonctions ne changent pas quand on passe d'un SGBD à un autre mais les paramètres (requêtes, connexions strings, etc.) seulement. Je vais vérifier ce que j'ai dit plus haut sur les sources de données.Citation:
Envoyé par Médinoc
Voilà j'ai vérifié et je confirme donc ce que j'ai dit plus haut à savoir qu'une application ODBC qui veut être totalement portable doit se connecter directement "à une base de données" et non "au SGBD". En effet, les commandes de définition ou de manipulation de bases de données (CREATE DATABASE, etc. qui ne font d'ailleurs pas partie du standard SQL) ne font pas partie du SQL minimum que chaque pilote ODBC doit supporter (mais elles peuvent être supportées par le SGBD). Les seules commandes de définition ou de manipulation de données standard en ODBC sont les commandes de définition ou de manipulation des éléments d'une base de données (tables, fonctions/procédures stockées, etc.).
D'autre part, je confirme aussi, ODBC est tout d'abord, certes, une interface portable de SGBD mais bien plus que ça, elle offre aussi un mécanisme qui permet d'écrire du SQL portable c'est-à-dire qui ne dépend d'aucun SGBD.
Liens MSDN :
ODBC SQL Grammar
The SQLNativeSql Function
Je viens de refouiller dans mes archives pour retrrouver la requête que je fait et qui à un formalisme différent suivant la base de données utilisée.
J'utilise au choix 2 bases de données MySQL ou SQL Server.
Pour une requête dans laquelle on veut limiter le nombre de ligne retournées à 10 (par exemple),
le format pour SQL Server est :
le format pour MySQL est :Code:SELECT TOP 10 * FROM TABLE
Après cela, je fait un SqlExec (pas un SqlExecDirect)Code:SELECT * FROM TABLE LIMIT 10
Je ne suis pas un kador des bases de données, donc il est possible que ce que j'utilise ne soit pas portable (et cela semble être le cas) ou bien qu'il y ait une subtilité qui m'échappe mais je n'ai jamais trouvé comment faire cette requête en portable.
Tu peux rajouter
en oracle :D (normalement c'est la syntaxe mysql qui est standard).Code:SELECT * FROM TABLE where row_number<=10
ram-0000 : la limitation des résultats et autres fonctionnalités similaires n'ont été introduites que dans SQL:2003 alors que le dialecte SQL de ODBC s'appuie sur le SQL-92. Pour utiliser ces fonctionnalités, tu dois donc en effet prévoir une requête par famille de SGBD.
zais_ethael : oui c'est LIMIT qui est standard, mais peu de SGBD encore supportent actuellement SQL3.