J'ai trouv=E9 sur le net plusieurs biblioth=E8ques permettant
d'incorporer du SQL dans du code C++, je me suis principalement
int=E9ress=E9 =E0 Oracle et j'ai trouv=E9 des biblioth=E8ques comme SOCI ou
OTL qui semblent masquer les appels OCI et se rapprocher plus de la
phylosophie actuelle de la STL. Boost ne poss=E8de rien concernant les
bases de donn=E9es.
Je voudrais savoir si vous utilisez des biblioth=E8ques comme SOCI, OTL
ou d'autres et qu'elle est votre avis sur leurs int=E9r=EAts et
p=E9rennit=E9s ?
Il me semble que beaucoup d'applications ont besoins de se connecter
aux bases de donn=E9es, ni la SL ni boost ne proposent de solutions,
apr=E8s des recherches sur ce groupe il se trouve que ce sujet n'est
jamais (ou presque) invoqu=E9 et l=E0 je suis surpris. Est ce un sujet
sans int=E9r=EAt pour la 'communaut=E9 C++', ou bien est ce plus des
probl=E8mes techniques ?
Je ne connais qu'une base de donn=E9e, je ne me rends pas compte des
difficult=E9s que pourrait comporter la standardisation des acc=E8s aux
bases.
Je ne l'ai pas essay=E9, mais OTL semble apporter une solution pour
certaines bases. Qu'est ce qui fait que le 'C++' ne s'int=E9resse pas
aux bases ?
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Fabien LE LEZ
On 3 Oct 2005 03:37:24 -0700, :
après des recherches sur ce groupe il se trouve que ce sujet n'est jamais (ou presque) invoqué et là je suis surpris.
Vraisemblablement parce qu'il n'existe pas de système unifié d'accès aux bases de données.
Une discussion sur un système d'accès qui concerne seulement un OS (par exemple, Microsoft ODBC) aura plus sa place sur un forum spécifique à cet OS (dans cet exemple, fr.comp.os.ms-windows.programmation).
Une discussion sur un système d'accès qui concerne seulement un moteur de base de données (par exemple, l'API MySQL) devra être abordée sur un forum ou une mailing-list concernant ce moteur (pour l'exemple de MySQL, cf <http://lists.mysql.com/>).
Par contre, en PHP par exemple, il existe un système d'accès aux bases de données intégré dans le langage. Du coup, en discuter sur fr.comp.lang.php est parfaitement en charte.
On 3 Oct 2005 03:37:24 -0700, herve_r01@yahoo.fr:
après des recherches sur ce groupe il se trouve que ce sujet n'est
jamais (ou presque) invoqué et là je suis surpris.
Vraisemblablement parce qu'il n'existe pas de système unifié d'accès
aux bases de données.
Une discussion sur un système d'accès qui concerne seulement un OS
(par exemple, Microsoft ODBC) aura plus sa place sur un forum
spécifique à cet OS (dans cet exemple,
fr.comp.os.ms-windows.programmation).
Une discussion sur un système d'accès qui concerne seulement un moteur
de base de données (par exemple, l'API MySQL) devra être abordée sur
un forum ou une mailing-list concernant ce moteur (pour l'exemple de
MySQL, cf <http://lists.mysql.com/>).
Par contre, en PHP par exemple, il existe un système d'accès aux bases
de données intégré dans le langage. Du coup, en discuter sur
fr.comp.lang.php est parfaitement en charte.
après des recherches sur ce groupe il se trouve que ce sujet n'est jamais (ou presque) invoqué et là je suis surpris.
Vraisemblablement parce qu'il n'existe pas de système unifié d'accès aux bases de données.
Une discussion sur un système d'accès qui concerne seulement un OS (par exemple, Microsoft ODBC) aura plus sa place sur un forum spécifique à cet OS (dans cet exemple, fr.comp.os.ms-windows.programmation).
Une discussion sur un système d'accès qui concerne seulement un moteur de base de données (par exemple, l'API MySQL) devra être abordée sur un forum ou une mailing-list concernant ce moteur (pour l'exemple de MySQL, cf <http://lists.mysql.com/>).
Par contre, en PHP par exemple, il existe un système d'accès aux bases de données intégré dans le langage. Du coup, en discuter sur fr.comp.lang.php est parfaitement en charte.
kanze
Fabien LE LEZ wrote:
On 3 Oct 2005 03:37:24 -0700, :
après des recherches sur ce groupe il se trouve que ce sujet n'est jamais (ou presque) invoqué et là je suis surpris.
Vraisemblablement parce qu'il n'existe pas de système unifié d'accès aux bases de données.
Ce qui est un raisonement circulaire. On ne parle pas du sujet parce qu'il n'y a pas de réponse générale, et il n'y a pas de réponse générale parce qu'on n'en parle jamais.
En fait, je me suis servi de OTL dans la dernière boîte où j'ai travaillé. C'est portable entre de différents fournisseurs de base de données (Oracle, DB-2, etc.) et entre de différents systèmes (Solaris, Windows, etc.). Je dirais donc qu'on pourrait bien en parler ici, de la même façon qu'on parlerait de ACE, par exemple.
[..]
Par contre, en PHP par exemple, il existe un système d'accès aux bases de données intégré dans le langage. Du coup, en discuter sur fr.comp.lang.php est parfaitement en charte.
Sa question était précisement : pourquoi il n'y a pas l'équivalent en C++ ? C'est effectivement quelque chose qui manque.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Fabien LE LEZ wrote:
On 3 Oct 2005 03:37:24 -0700, herve_r01@yahoo.fr:
après des recherches sur ce groupe il se trouve que ce sujet
n'est jamais (ou presque) invoqué et là je suis surpris.
Vraisemblablement parce qu'il n'existe pas de système unifié
d'accès aux bases de données.
Ce qui est un raisonement circulaire. On ne parle pas du sujet
parce qu'il n'y a pas de réponse générale, et il n'y a pas de
réponse générale parce qu'on n'en parle jamais.
En fait, je me suis servi de OTL dans la dernière boîte où j'ai
travaillé. C'est portable entre de différents fournisseurs de
base de données (Oracle, DB-2, etc.) et entre de différents
systèmes (Solaris, Windows, etc.). Je dirais donc qu'on pourrait
bien en parler ici, de la même façon qu'on parlerait de ACE, par
exemple.
[..]
Par contre, en PHP par exemple, il existe un système d'accès
aux bases de données intégré dans le langage. Du coup, en
discuter sur fr.comp.lang.php est parfaitement en charte.
Sa question était précisement : pourquoi il n'y a pas
l'équivalent en C++ ? C'est effectivement quelque chose qui
manque.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
après des recherches sur ce groupe il se trouve que ce sujet n'est jamais (ou presque) invoqué et là je suis surpris.
Vraisemblablement parce qu'il n'existe pas de système unifié d'accès aux bases de données.
Ce qui est un raisonement circulaire. On ne parle pas du sujet parce qu'il n'y a pas de réponse générale, et il n'y a pas de réponse générale parce qu'on n'en parle jamais.
En fait, je me suis servi de OTL dans la dernière boîte où j'ai travaillé. C'est portable entre de différents fournisseurs de base de données (Oracle, DB-2, etc.) et entre de différents systèmes (Solaris, Windows, etc.). Je dirais donc qu'on pourrait bien en parler ici, de la même façon qu'on parlerait de ACE, par exemple.
[..]
Par contre, en PHP par exemple, il existe un système d'accès aux bases de données intégré dans le langage. Du coup, en discuter sur fr.comp.lang.php est parfaitement en charte.
Sa question était précisement : pourquoi il n'y a pas l'équivalent en C++ ? C'est effectivement quelque chose qui manque.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
herve_r01
[]
Ce qui est un raisonement circulaire. On ne parle pas du sujet parce qu'il n'y a pas de réponse générale, et il n'y a pas de réponse générale parce qu'on n'en parle jamais.
En fait, je me suis servi de OTL dans la dernière boîte où j'ai travaillé. C'est portable entre de différents fournisseurs de base de données (Oracle, DB-2, etc.) et entre de différents systèmes (Solaris, Windows, etc.). Je dirais donc qu'on pourrait bien en parler ici, de la même façon qu'on parlerait de ACE, par exemple. Par curiosité, vu que tu t'en ais servi, et elle bien intégrée à la
STL, et elle (relativement) complète, est ce que son concept te semble bon ? Sais tu si elle est utilisée/connue ou est elle sur un marché de niche ? (en gros est ce que OTL peut avoir de l'avenir)
[]
Sa question était précisement : pourquoi il n'y a pas l'équivalent en C++ ? C'est effectivement quelque chose qui manque. Oui, ca manque mais comme tu le dis plus haut personne n'en parle et
c'est sans doute que très peu de monde est concerné. Si le C++ n'est jamais ou presque utilisé dans les applications se connectant à des bases on est pas près d'avoir une réponse généralle.
[]
Ce qui est un raisonement circulaire. On ne parle pas du sujet
parce qu'il n'y a pas de réponse générale, et il n'y a pas de
réponse générale parce qu'on n'en parle jamais.
En fait, je me suis servi de OTL dans la dernière boîte où j'ai
travaillé. C'est portable entre de différents fournisseurs de
base de données (Oracle, DB-2, etc.) et entre de différents
systèmes (Solaris, Windows, etc.). Je dirais donc qu'on pourrait
bien en parler ici, de la même façon qu'on parlerait de ACE, par
exemple.
Par curiosité, vu que tu t'en ais servi, et elle bien intégrée à la
STL, et elle (relativement) complète, est ce que son concept te semble
bon ?
Sais tu si elle est utilisée/connue ou est elle sur un marché de
niche ? (en gros est ce que OTL peut avoir de l'avenir)
[]
Sa question était précisement : pourquoi il n'y a pas
l'équivalent en C++ ? C'est effectivement quelque chose qui
manque.
Oui, ca manque mais comme tu le dis plus haut personne n'en parle et
c'est sans doute que très peu de monde est concerné. Si le C++ n'est
jamais ou presque utilisé dans les applications se connectant à des
bases on est pas près d'avoir une réponse généralle.
Ce qui est un raisonement circulaire. On ne parle pas du sujet parce qu'il n'y a pas de réponse générale, et il n'y a pas de réponse générale parce qu'on n'en parle jamais.
En fait, je me suis servi de OTL dans la dernière boîte où j'ai travaillé. C'est portable entre de différents fournisseurs de base de données (Oracle, DB-2, etc.) et entre de différents systèmes (Solaris, Windows, etc.). Je dirais donc qu'on pourrait bien en parler ici, de la même façon qu'on parlerait de ACE, par exemple. Par curiosité, vu que tu t'en ais servi, et elle bien intégrée à la
STL, et elle (relativement) complète, est ce que son concept te semble bon ? Sais tu si elle est utilisée/connue ou est elle sur un marché de niche ? (en gros est ce que OTL peut avoir de l'avenir)
[]
Sa question était précisement : pourquoi il n'y a pas l'équivalent en C++ ? C'est effectivement quelque chose qui manque. Oui, ca manque mais comme tu le dis plus haut personne n'en parle et
c'est sans doute que très peu de monde est concerné. Si le C++ n'est jamais ou presque utilisé dans les applications se connectant à des bases on est pas près d'avoir une réponse généralle.
kanze
wrote:
[]
Ce qui est un raisonement circulaire. On ne parle pas du sujet parce qu'il n'y a pas de réponse générale, et il n'y a pas de réponse générale parce qu'on n'en parle jamais.
En fait, je me suis servi de OTL dans la dernière boîte où j'ai travaillé. C'est portable entre de différents fournisseurs de base de données (Oracle, DB-2, etc.) et entre de différents systèmes (Solaris, Windows, etc.). Je dirais donc qu'on pourrait bien en parler ici, de la même façon qu'on parlerait de ACE, par exemple.
Par curiosité, vu que tu t'en ais servi, et elle bien intégrée à la STL,
Elle se base plutôt sur la notion des flux.
et elle (relativement) complète,
Elle a bien suffit pour tout ce qu'on voulait faire. Mais il faut dire qu'on faisait des choses assez simple : des updates et des inserts dans une seule table, avec des critères assez simples. D'après sa conception, je ne vois pas où il se poserait des problèmes avec des requêtes plus compliquées, mais je n'ai pas d'expérience concrète pour dire qu'elle ne le fait pas.
est ce que son concept te semble bon ?
Partiellement. Dans l'ensemble, c'est sûrement une amélioration par rapport à l'accès direct à la base de données. Néaumoins, il y avait deux points où j'avais des doutes :
-- Je n'aimais pas particulièrement que l'initialisation des critères de récherche (les variables dans un "where") se fasse comme si elle était l'écriture dans un flux. Si j'ai une commande de select, c'est une flux en entrée, et l'idée d'y écrire (avec une sémantique bien différente de l'écriture dans les insert et les updates, c-à-d les flux de sortie) me semblait ne pas vraiment convenir.
-- La vérification des types était dynamique, et non statique. À vrai dire, je ne sais pas si c'est possible autrement, étant donné que le type des champs n'est connu que de la base de donnée (et qu'on peut supprimer, puis réconstruire des tables avec une autre structure après la compilation); je ne vois pas comment on pouvait faire que le compilateur les sache, pour vérifier qu'on s'est servi du bon type. On se retrouve alors avec les vieux problèmes de printf. (Mais pas tout à fait -- puisque la fonction appelée dépend du type cible, et que le système sait le type réel à l'exécution, certaines conversions peuvent se faire pour que ça marche.)
Sais tu si elle est utilisée/connue ou est elle sur un marché de niche ? (en gros est ce que OTL peut avoir de l'avenir)
Là, je n'ai aucune indice. Seulement que je m'en suis servi il y a plus de trois ans maintenant, et qu'elle est toujours là et maintenu.
[]
Sa question était précisement : pourquoi il n'y a pas l'équivalent en C++ ? C'est effectivement quelque chose qui manque.
Oui, ca manque mais comme tu le dis plus haut personne n'en parle et c'est sans doute que très peu de monde est concerné.
Ça, je ne sais pas. Il y a pas mal du monde qui utilise les bases de données.
Si le C++ n'est jamais ou presque utilisé dans les applications se connectant à des bases on est pas près d'avoir une réponse généralle.
Autant que je vois, le C++ reste le langage le plus utilisé pour des grands serveurs, qui eux utilisent prèsque toujours une base de données.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
herve_r01@yahoo.fr wrote:
[]
Ce qui est un raisonement circulaire. On ne parle pas du
sujet parce qu'il n'y a pas de réponse générale, et il n'y a
pas de réponse générale parce qu'on n'en parle jamais.
En fait, je me suis servi de OTL dans la dernière boîte où
j'ai travaillé. C'est portable entre de différents
fournisseurs de base de données (Oracle, DB-2, etc.) et
entre de différents systèmes (Solaris, Windows, etc.). Je
dirais donc qu'on pourrait bien en parler ici, de la même
façon qu'on parlerait de ACE, par exemple.
Par curiosité, vu que tu t'en ais servi, et elle bien intégrée
à la STL,
Elle se base plutôt sur la notion des flux.
et elle (relativement) complète,
Elle a bien suffit pour tout ce qu'on voulait faire. Mais il
faut dire qu'on faisait des choses assez simple : des updates et
des inserts dans une seule table, avec des critères assez
simples. D'après sa conception, je ne vois pas où il se poserait
des problèmes avec des requêtes plus compliquées, mais je n'ai
pas d'expérience concrète pour dire qu'elle ne le fait pas.
est ce que son concept te semble bon ?
Partiellement. Dans l'ensemble, c'est sûrement une amélioration
par rapport à l'accès direct à la base de données. Néaumoins, il
y avait deux points où j'avais des doutes :
-- Je n'aimais pas particulièrement que l'initialisation des
critères de récherche (les variables dans un "where") se
fasse comme si elle était l'écriture dans un flux. Si j'ai
une commande de select, c'est une flux en entrée, et l'idée
d'y écrire (avec une sémantique bien différente de
l'écriture dans les insert et les updates, c-à-d les flux de
sortie) me semblait ne pas vraiment convenir.
-- La vérification des types était dynamique, et non statique.
À vrai dire, je ne sais pas si c'est possible autrement,
étant donné que le type des champs n'est connu que de la
base de donnée (et qu'on peut supprimer, puis réconstruire
des tables avec une autre structure après la compilation);
je ne vois pas comment on pouvait faire que le compilateur
les sache, pour vérifier qu'on s'est servi du bon type. On
se retrouve alors avec les vieux problèmes de printf. (Mais
pas tout à fait -- puisque la fonction appelée dépend du
type cible, et que le système sait le type réel à
l'exécution, certaines conversions peuvent se faire pour que
ça marche.)
Sais tu si elle est utilisée/connue ou est elle sur un marché
de niche ? (en gros est ce que OTL peut avoir de l'avenir)
Là, je n'ai aucune indice. Seulement que je m'en suis servi il y
a plus de trois ans maintenant, et qu'elle est toujours là et
maintenu.
[]
Sa question était précisement : pourquoi il n'y a pas
l'équivalent en C++ ? C'est effectivement quelque chose qui
manque.
Oui, ca manque mais comme tu le dis plus haut personne n'en
parle et c'est sans doute que très peu de monde est concerné.
Ça, je ne sais pas. Il y a pas mal du monde qui utilise les
bases de données.
Si le C++ n'est jamais ou presque utilisé dans les
applications se connectant à des bases on est pas près d'avoir
une réponse généralle.
Autant que je vois, le C++ reste le langage le plus utilisé pour
des grands serveurs, qui eux utilisent prèsque toujours une base
de données.
--
James Kanze GABI Software
Conseils en informatique orientée objet/
Beratung in objektorientierter Datenverarbeitung
9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
Ce qui est un raisonement circulaire. On ne parle pas du sujet parce qu'il n'y a pas de réponse générale, et il n'y a pas de réponse générale parce qu'on n'en parle jamais.
En fait, je me suis servi de OTL dans la dernière boîte où j'ai travaillé. C'est portable entre de différents fournisseurs de base de données (Oracle, DB-2, etc.) et entre de différents systèmes (Solaris, Windows, etc.). Je dirais donc qu'on pourrait bien en parler ici, de la même façon qu'on parlerait de ACE, par exemple.
Par curiosité, vu que tu t'en ais servi, et elle bien intégrée à la STL,
Elle se base plutôt sur la notion des flux.
et elle (relativement) complète,
Elle a bien suffit pour tout ce qu'on voulait faire. Mais il faut dire qu'on faisait des choses assez simple : des updates et des inserts dans une seule table, avec des critères assez simples. D'après sa conception, je ne vois pas où il se poserait des problèmes avec des requêtes plus compliquées, mais je n'ai pas d'expérience concrète pour dire qu'elle ne le fait pas.
est ce que son concept te semble bon ?
Partiellement. Dans l'ensemble, c'est sûrement une amélioration par rapport à l'accès direct à la base de données. Néaumoins, il y avait deux points où j'avais des doutes :
-- Je n'aimais pas particulièrement que l'initialisation des critères de récherche (les variables dans un "where") se fasse comme si elle était l'écriture dans un flux. Si j'ai une commande de select, c'est une flux en entrée, et l'idée d'y écrire (avec une sémantique bien différente de l'écriture dans les insert et les updates, c-à-d les flux de sortie) me semblait ne pas vraiment convenir.
-- La vérification des types était dynamique, et non statique. À vrai dire, je ne sais pas si c'est possible autrement, étant donné que le type des champs n'est connu que de la base de donnée (et qu'on peut supprimer, puis réconstruire des tables avec une autre structure après la compilation); je ne vois pas comment on pouvait faire que le compilateur les sache, pour vérifier qu'on s'est servi du bon type. On se retrouve alors avec les vieux problèmes de printf. (Mais pas tout à fait -- puisque la fonction appelée dépend du type cible, et que le système sait le type réel à l'exécution, certaines conversions peuvent se faire pour que ça marche.)
Sais tu si elle est utilisée/connue ou est elle sur un marché de niche ? (en gros est ce que OTL peut avoir de l'avenir)
Là, je n'ai aucune indice. Seulement que je m'en suis servi il y a plus de trois ans maintenant, et qu'elle est toujours là et maintenu.
[]
Sa question était précisement : pourquoi il n'y a pas l'équivalent en C++ ? C'est effectivement quelque chose qui manque.
Oui, ca manque mais comme tu le dis plus haut personne n'en parle et c'est sans doute que très peu de monde est concerné.
Ça, je ne sais pas. Il y a pas mal du monde qui utilise les bases de données.
Si le C++ n'est jamais ou presque utilisé dans les applications se connectant à des bases on est pas près d'avoir une réponse généralle.
Autant que je vois, le C++ reste le langage le plus utilisé pour des grands serveurs, qui eux utilisent prèsque toujours une base de données.
-- James Kanze GABI Software Conseils en informatique orientée objet/ Beratung in objektorientierter Datenverarbeitung 9 place Sémard, 78210 St.-Cyr-l'École, France, +33 (0)1 30 23 00 34
herve_r01
wrote: []
Par curiosité, vu que tu t'en ais servi, et elle bien intégrée à la STL,
Elle se base plutôt sur la notion des flux.
et elle (relativement) complète,
Elle a bien suffit pour tout ce qu'on voulait faire. Mais il faut dire qu'on faisait des choses assez simple : des updates et des inserts dans une seule table, avec des critères assez simples. D'après sa conception, je ne vois pas où il se poserait des problèmes avec des requêtes plus compliquées, mais je n'ai pas d'expérience concrète pour dire qu'elle ne le fait pas.
est ce que son concept te semble bon ?
Partiellement. Dans l'ensemble, c'est sûrement une amélioration par rapport à l'accès direct à la base de données. Néaumoins, il y avait deux points où j'avais des doutes :
-- Je n'aimais pas particulièrement que l'initialisation des critères de récherche (les variables dans un "where") se fasse comme si elle était l'écriture dans un flux. Si j'ai une commande de select, c'est une flux en entrée, et l'idée d'y écrire (avec une sémantique bien différente de l'écriture dans les insert et les updates, c-à-d les flux de sortie) me semblait ne pas vraiment convenir.
-- La vérification des types était dynamique, et non statique. À vrai dire, je ne sais pas si c'est possible autrement, étant donné que le type des champs n'est connu que de la base de donnée (et qu'on peut supprimer, puis réconstruire des tables avec une autre structure après la compilation); je ne vois pas comment on pouvait faire que le compilateur les sache, pour vérifier qu'on s'est servi du bon type. On se retrouve alors avec les vieux problèmes de printf. (Mais pas tout à fait -- puisque la fonction appelée dépend du type cible, et que le système sait le type réel à l'exécution, certaines conversions peuvent se faire pour que ça marche.)
Ok, merci pour les éclaircissements.
Sais tu si elle est utilisée/connue ou est elle sur un marché de niche ? (en gros est ce que OTL peut avoir de l'avenir)
Là, je n'ai aucune indice. Seulement que je m'en suis servi il y a plus de trois ans maintenant, et qu'elle est toujours là et maintenu. Ca semble être un bon signe.
[]
Oui, ca manque mais comme tu le dis plus haut personne n'en parle et c'est sans doute que très peu de monde est concerné.
Ça, je ne sais pas. Il y a pas mal du monde qui utilise les bases de données.
Si le C++ n'est jamais ou presque utilisé dans les applications se connectant à des bases on est pas près d'avoir une réponse généralle.
Autant que je vois, le C++ reste le langage le plus utilisé pour des grands serveurs, qui eux utilisent prèsque toujours une base de données.
Oui, je suis d'accord, je voulais dire qu'unifier les appels/accées aux bases de données n'est visiblement pas une préocupation majeur aujourd'hui pour les développeurs.
Merci pour ton point de vue.
herve_r01@yahoo.fr wrote:
[]
Par curiosité, vu que tu t'en ais servi, et elle bien intégrée
à la STL,
Elle se base plutôt sur la notion des flux.
et elle (relativement) complète,
Elle a bien suffit pour tout ce qu'on voulait faire. Mais il
faut dire qu'on faisait des choses assez simple : des updates et
des inserts dans une seule table, avec des critères assez
simples. D'après sa conception, je ne vois pas où il se poserait
des problèmes avec des requêtes plus compliquées, mais je n'ai
pas d'expérience concrète pour dire qu'elle ne le fait pas.
est ce que son concept te semble bon ?
Partiellement. Dans l'ensemble, c'est sûrement une amélioration
par rapport à l'accès direct à la base de données. Néaumoins, il
y avait deux points où j'avais des doutes :
-- Je n'aimais pas particulièrement que l'initialisation des
critères de récherche (les variables dans un "where") se
fasse comme si elle était l'écriture dans un flux. Si j'ai
une commande de select, c'est une flux en entrée, et l'idée
d'y écrire (avec une sémantique bien différente de
l'écriture dans les insert et les updates, c-à-d les flux de
sortie) me semblait ne pas vraiment convenir.
-- La vérification des types était dynamique, et non statique.
À vrai dire, je ne sais pas si c'est possible autrement,
étant donné que le type des champs n'est connu que de la
base de donnée (et qu'on peut supprimer, puis réconstruire
des tables avec une autre structure après la compilation);
je ne vois pas comment on pouvait faire que le compilateur
les sache, pour vérifier qu'on s'est servi du bon type. On
se retrouve alors avec les vieux problèmes de printf. (Mais
pas tout à fait -- puisque la fonction appelée dépend du
type cible, et que le système sait le type réel à
l'exécution, certaines conversions peuvent se faire pour que
ça marche.)
Ok, merci pour les éclaircissements.
Sais tu si elle est utilisée/connue ou est elle sur un marché
de niche ? (en gros est ce que OTL peut avoir de l'avenir)
Là, je n'ai aucune indice. Seulement que je m'en suis servi il y
a plus de trois ans maintenant, et qu'elle est toujours là et
maintenu.
Ca semble être un bon signe.
[]
Oui, ca manque mais comme tu le dis plus haut personne n'en
parle et c'est sans doute que très peu de monde est concerné.
Ça, je ne sais pas. Il y a pas mal du monde qui utilise les
bases de données.
Si le C++ n'est jamais ou presque utilisé dans les
applications se connectant à des bases on est pas près d'avoir
une réponse généralle.
Autant que je vois, le C++ reste le langage le plus utilisé pour
des grands serveurs, qui eux utilisent prèsque toujours une base
de données.
Oui, je suis d'accord, je voulais dire qu'unifier les appels/accées
aux bases de données n'est visiblement pas une préocupation majeur
aujourd'hui pour les développeurs.
Par curiosité, vu que tu t'en ais servi, et elle bien intégrée à la STL,
Elle se base plutôt sur la notion des flux.
et elle (relativement) complète,
Elle a bien suffit pour tout ce qu'on voulait faire. Mais il faut dire qu'on faisait des choses assez simple : des updates et des inserts dans une seule table, avec des critères assez simples. D'après sa conception, je ne vois pas où il se poserait des problèmes avec des requêtes plus compliquées, mais je n'ai pas d'expérience concrète pour dire qu'elle ne le fait pas.
est ce que son concept te semble bon ?
Partiellement. Dans l'ensemble, c'est sûrement une amélioration par rapport à l'accès direct à la base de données. Néaumoins, il y avait deux points où j'avais des doutes :
-- Je n'aimais pas particulièrement que l'initialisation des critères de récherche (les variables dans un "where") se fasse comme si elle était l'écriture dans un flux. Si j'ai une commande de select, c'est une flux en entrée, et l'idée d'y écrire (avec une sémantique bien différente de l'écriture dans les insert et les updates, c-à-d les flux de sortie) me semblait ne pas vraiment convenir.
-- La vérification des types était dynamique, et non statique. À vrai dire, je ne sais pas si c'est possible autrement, étant donné que le type des champs n'est connu que de la base de donnée (et qu'on peut supprimer, puis réconstruire des tables avec une autre structure après la compilation); je ne vois pas comment on pouvait faire que le compilateur les sache, pour vérifier qu'on s'est servi du bon type. On se retrouve alors avec les vieux problèmes de printf. (Mais pas tout à fait -- puisque la fonction appelée dépend du type cible, et que le système sait le type réel à l'exécution, certaines conversions peuvent se faire pour que ça marche.)
Ok, merci pour les éclaircissements.
Sais tu si elle est utilisée/connue ou est elle sur un marché de niche ? (en gros est ce que OTL peut avoir de l'avenir)
Là, je n'ai aucune indice. Seulement que je m'en suis servi il y a plus de trois ans maintenant, et qu'elle est toujours là et maintenu. Ca semble être un bon signe.
[]
Oui, ca manque mais comme tu le dis plus haut personne n'en parle et c'est sans doute que très peu de monde est concerné.
Ça, je ne sais pas. Il y a pas mal du monde qui utilise les bases de données.
Si le C++ n'est jamais ou presque utilisé dans les applications se connectant à des bases on est pas près d'avoir une réponse généralle.
Autant que je vois, le C++ reste le langage le plus utilisé pour des grands serveurs, qui eux utilisent prèsque toujours une base de données.
Oui, je suis d'accord, je voulais dire qu'unifier les appels/accées aux bases de données n'est visiblement pas une préocupation majeur aujourd'hui pour les développeurs.
