Bonjour les gens.
Je recherche désespérément un exemple SIMPLE de connexion à MS SQL en
C++ (sous linux).
Quelqu'un dans l'assistance aurait-il ça sous la main ?
Un lien, une doc, je suis preneur...
SQL est un langage de programmation, assez complexe.
Non, c'est un langage informatique. Je ne l'eleverai pas a la qualite de `langage de programmation'. Il y a des extensions (procedures stockees et tutti-quanti) qui en font un vrai langage de programmation, mais je ne pense pas qu'il soit Turing-complet, par exemple...
A la base, sql, ce n'est jamais qu'un formalisme un peu bizarre pour representer la theorie des ensembles (ordonnes)...
In article <sqdp2413j9083g87fu8cut75sb2v217481@4ax.com>,
Fabien LE LEZ <usenet15@x.edulang.com> wrote:
SQL est un langage de programmation, assez complexe.
Non, c'est un langage informatique. Je ne l'eleverai pas a la qualite
de `langage de programmation'. Il y a des extensions (procedures stockees
et tutti-quanti) qui en font un vrai langage de programmation, mais je
ne pense pas qu'il soit Turing-complet, par exemple...
A la base, sql, ce n'est jamais qu'un formalisme un peu bizarre pour
representer la theorie des ensembles (ordonnes)...
SQL est un langage de programmation, assez complexe.
Non, c'est un langage informatique. Je ne l'eleverai pas a la qualite de `langage de programmation'. Il y a des extensions (procedures stockees et tutti-quanti) qui en font un vrai langage de programmation, mais je ne pense pas qu'il soit Turing-complet, par exemple...
A la base, sql, ce n'est jamais qu'un formalisme un peu bizarre pour representer la theorie des ensembles (ordonnes)...
James Kanze
On May 16, 2:15 am, Fabien LE LEZ wrote:
On Fri, 16 May 2008 01:05:52 +0200, "Sylvain SF" :
[...]
je ne pose pas qu'apprendre une API (et a fortiori une API métier) soit pénible ou difficile
Le but est de faire la même chose que ce que permet SQL, mais avec une API différente. Il n'y a aucune raison de penser que cette API sera plus simple que SQL lui-même, qui est déjà passablement complexe.
Si un programmeur découvre la notion de base de données avec cette API, et n'utilise qu'elle (i.e. n'a jamais besoin d'accéder à une base de données via le langage SQL, en PHP par exemple), alors, pourquoi pas.
Par contre, si un programmeur a déjà une certaine expérience avec SQ L, il va falloir de sacrés bons arguments pour le convaincre d'apprendre un nouveau "langage" (ton API) pour faire sensiblement la même chose.
Je comprends un peu le point de vue de Sylvain. La bibliothèque OTL dont parle znort traite le SQL comme un espèce d'entrées/sorties. Ce qui correspond effectivement à la réalité physique, mais d'un certain côté, on aimerait pouvoir définir une classe ou une struct qui correspond soit à une ligne dans un tableau, soit à une suite de colonnes, mais avec un comportement en plus (pourquoi pas ?) et puis avoir des accès qui ressemblent à l'utilisation d'un std::vector ou d'un std::map (avec éventuellement une cause de where comme argument au constructeur). L'idée, je crois, n'est pas d'exprimer le SQL avec un autre API, mais plutôt de le présenter selon un modèle objet plus habituel aux programmeurs C++.
-- James Kanze (GABI Software) email: 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
On May 16, 2:15 am, Fabien LE LEZ <grams...@gramster.com> wrote:
On Fri, 16 May 2008 01:05:52 +0200, "Sylvain SF"
<sylv...@boiteaspam.info>:
[...]
je ne pose pas qu'apprendre une API (et a fortiori une API métier)
soit pénible ou difficile
Le but est de faire la même chose que ce que permet SQL, mais avec une
API différente. Il n'y a aucune raison de penser que cette API sera
plus simple que SQL lui-même, qui est déjà passablement complexe.
Si un programmeur découvre la notion de base de données avec cette
API, et n'utilise qu'elle (i.e. n'a jamais besoin d'accéder à une base
de données via le langage SQL, en PHP par exemple), alors, pourquoi
pas.
Par contre, si un programmeur a déjà une certaine expérience avec SQ L,
il va falloir de sacrés bons arguments pour le convaincre d'apprendre
un nouveau "langage" (ton API) pour faire sensiblement la même chose.
Je comprends un peu le point de vue de Sylvain. La bibliothèque
OTL dont parle znort traite le SQL comme un espèce
d'entrées/sorties. Ce qui correspond effectivement à la réalité
physique, mais d'un certain côté, on aimerait pouvoir définir
une classe ou une struct qui correspond soit à une ligne dans un
tableau, soit à une suite de colonnes, mais avec un comportement
en plus (pourquoi pas ?) et puis avoir des accès qui
ressemblent à l'utilisation d'un std::vector ou d'un std::map
(avec éventuellement une cause de where comme argument au
constructeur). L'idée, je crois, n'est pas d'exprimer le SQL
avec un autre API, mais plutôt de le présenter selon un modèle
objet plus habituel aux programmeurs C++.
--
James Kanze (GABI Software) email:james.kanze@gmail.com
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
On Fri, 16 May 2008 01:05:52 +0200, "Sylvain SF" :
[...]
je ne pose pas qu'apprendre une API (et a fortiori une API métier) soit pénible ou difficile
Le but est de faire la même chose que ce que permet SQL, mais avec une API différente. Il n'y a aucune raison de penser que cette API sera plus simple que SQL lui-même, qui est déjà passablement complexe.
Si un programmeur découvre la notion de base de données avec cette API, et n'utilise qu'elle (i.e. n'a jamais besoin d'accéder à une base de données via le langage SQL, en PHP par exemple), alors, pourquoi pas.
Par contre, si un programmeur a déjà une certaine expérience avec SQ L, il va falloir de sacrés bons arguments pour le convaincre d'apprendre un nouveau "langage" (ton API) pour faire sensiblement la même chose.
Je comprends un peu le point de vue de Sylvain. La bibliothèque OTL dont parle znort traite le SQL comme un espèce d'entrées/sorties. Ce qui correspond effectivement à la réalité physique, mais d'un certain côté, on aimerait pouvoir définir une classe ou une struct qui correspond soit à une ligne dans un tableau, soit à une suite de colonnes, mais avec un comportement en plus (pourquoi pas ?) et puis avoir des accès qui ressemblent à l'utilisation d'un std::vector ou d'un std::map (avec éventuellement une cause de where comme argument au constructeur). L'idée, je crois, n'est pas d'exprimer le SQL avec un autre API, mais plutôt de le présenter selon un modèle objet plus habituel aux programmeurs C++.
-- James Kanze (GABI Software) email: 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
Sylvain SF
Michael DOUBEZ wrote on 16/05/2008 09:44:
Avec un système à la Boost.Spirit l'expression pourrait largement ressembler au SQL (ou même en partie au OQL). Cela amortirait la courbe d'apprentissage.
je ne connais pas assez Spirit pour savoir. dans le même temps, je ne suis pas certain qu'une ressemblance stricte entre les expressions C++ et la syntaxe SQL soit nécessaire. le pré-requis est bien sur de connaitre et comprendre la structure relationelle de ses infos, ensuite la manipulation de ces relations pourrait être C++ pur.
Est ce que les données transitent en binaires entre le client et la BDD ?
dans le cas d'une API directe oui, pour un layer ODBC (ou tout layer avec son propre marshalling) c'est undéfini.
Ce qui implique de repasser par des strings pour exprimer les requêtes en SQL, donc le gain en vitesse est loin d'être acquis.
une requête (la requête envoyée) est toujours une string; la réponse est mixte, chaque ligne-réponse peut contenir du texte ou du binaire selon la seule définition de la table.
l'objet "requete" n'est qu'un petit élément, les objets cursors (parseurs de réponses) sont les éléments les plus sensibles pour les gains ou pertes de perf.; des objets tables (connaissant implicitement leurs colonnes - pour vérifier avant transmission la validité d'une sélection - et leurs références externes - pour ne pas avoir à taper explicitement les jointures - seraient des aides à la création de requete.
@ Marc: SQL:2003 (ISO 9075:2003) est turing-complet.
Sylvain.
Michael DOUBEZ wrote on 16/05/2008 09:44:
Avec un système à la Boost.Spirit l'expression pourrait largement
ressembler au SQL (ou même en partie au OQL). Cela amortirait la courbe
d'apprentissage.
je ne connais pas assez Spirit pour savoir.
dans le même temps, je ne suis pas certain qu'une ressemblance
stricte entre les expressions C++ et la syntaxe SQL soit
nécessaire. le pré-requis est bien sur de connaitre et comprendre
la structure relationelle de ses infos, ensuite la manipulation
de ces relations pourrait être C++ pur.
Est ce que les données transitent en binaires entre le client et la BDD ?
dans le cas d'une API directe oui, pour un layer ODBC (ou tout layer
avec son propre marshalling) c'est undéfini.
Ce qui implique de repasser par des strings pour exprimer les requêtes
en SQL, donc le gain en vitesse est loin d'être acquis.
une requête (la requête envoyée) est toujours une string; la réponse
est mixte, chaque ligne-réponse peut contenir du texte ou du binaire
selon la seule définition de la table.
l'objet "requete" n'est qu'un petit élément, les objets cursors
(parseurs de réponses) sont les éléments les plus sensibles pour
les gains ou pertes de perf.; des objets tables (connaissant
implicitement leurs colonnes - pour vérifier avant transmission
la validité d'une sélection - et leurs références externes - pour
ne pas avoir à taper explicitement les jointures - seraient des
aides à la création de requete.
@ Marc: SQL:2003 (ISO 9075:2003) est turing-complet.
Avec un système à la Boost.Spirit l'expression pourrait largement ressembler au SQL (ou même en partie au OQL). Cela amortirait la courbe d'apprentissage.
je ne connais pas assez Spirit pour savoir. dans le même temps, je ne suis pas certain qu'une ressemblance stricte entre les expressions C++ et la syntaxe SQL soit nécessaire. le pré-requis est bien sur de connaitre et comprendre la structure relationelle de ses infos, ensuite la manipulation de ces relations pourrait être C++ pur.
Est ce que les données transitent en binaires entre le client et la BDD ?
dans le cas d'une API directe oui, pour un layer ODBC (ou tout layer avec son propre marshalling) c'est undéfini.
Ce qui implique de repasser par des strings pour exprimer les requêtes en SQL, donc le gain en vitesse est loin d'être acquis.
une requête (la requête envoyée) est toujours une string; la réponse est mixte, chaque ligne-réponse peut contenir du texte ou du binaire selon la seule définition de la table.
l'objet "requete" n'est qu'un petit élément, les objets cursors (parseurs de réponses) sont les éléments les plus sensibles pour les gains ou pertes de perf.; des objets tables (connaissant implicitement leurs colonnes - pour vérifier avant transmission la validité d'une sélection - et leurs références externes - pour ne pas avoir à taper explicitement les jointures - seraient des aides à la création de requete.
@ Marc: SQL:2003 (ISO 9075:2003) est turing-complet.
Sylvain.
Sylvain SF
On May 16, 2:15 am, Fabien LE LEZ wrote: Le but est de faire la même chose que ce que permet SQL, mais avec une API différente. [...]
non, ce n'est pas le but.
Si un programmeur découvre la notion de base de données avec cette API, et n'utilise qu'elle (i.e. n'a jamais besoin d'accéder à une base de données via le langage SQL, en PHP par exemple), alors, pourquoi pas.
un code PHP n'a *pas* d'autre choix aujourd'hui que d'utiliser une syntaxe SQL pour ces requêtes - l'exploitation des résultats de la requête (via 'mysql_result' ou 'mysql_fetch_array') n'est pas dans le scope de SQL qui ne définit pas la représentation - externe à la base - d'un cursor.
James Kanze wrote on 16/05/2008 11:55: [...] L'idée, je crois, n'est pas d'exprimer le SQL avec un autre API, mais plutôt de le présenter selon un modèle objet plus habituel aux programmeurs C++.
merci.
Sylvain.
On May 16, 2:15 am, Fabien LE LEZ wrote:
Le but est de faire la même chose que ce que permet SQL, mais avec une
API différente. [...]
non, ce n'est pas le but.
Si un programmeur découvre la notion de base de données avec cette
API, et n'utilise qu'elle (i.e. n'a jamais besoin d'accéder à une base
de données via le langage SQL, en PHP par exemple), alors, pourquoi
pas.
un code PHP n'a *pas* d'autre choix aujourd'hui que d'utiliser
une syntaxe SQL pour ces requêtes - l'exploitation des résultats
de la requête (via 'mysql_result' ou 'mysql_fetch_array') n'est
pas dans le scope de SQL qui ne définit pas la représentation -
externe à la base - d'un cursor.
James Kanze wrote on 16/05/2008 11:55:
[...] L'idée, je crois, n'est pas d'exprimer le SQL
avec un autre API, mais plutôt de le présenter selon un modèle
objet plus habituel aux programmeurs C++.
On May 16, 2:15 am, Fabien LE LEZ wrote: Le but est de faire la même chose que ce que permet SQL, mais avec une API différente. [...]
non, ce n'est pas le but.
Si un programmeur découvre la notion de base de données avec cette API, et n'utilise qu'elle (i.e. n'a jamais besoin d'accéder à une base de données via le langage SQL, en PHP par exemple), alors, pourquoi pas.
un code PHP n'a *pas* d'autre choix aujourd'hui que d'utiliser une syntaxe SQL pour ces requêtes - l'exploitation des résultats de la requête (via 'mysql_result' ou 'mysql_fetch_array') n'est pas dans le scope de SQL qui ne définit pas la représentation - externe à la base - d'un cursor.
James Kanze wrote on 16/05/2008 11:55: [...] L'idée, je crois, n'est pas d'exprimer le SQL avec un autre API, mais plutôt de le présenter selon un modèle objet plus habituel aux programmeurs C++.
merci.
Sylvain.
Fabien LE LEZ
On Fri, 16 May 2008 02:55:50 -0700 (PDT), James Kanze :
mais d'un certain côté, on aimerait pouvoir définir une classe ou une struct qui correspond soit à une ligne dans un tableau, soit à une suite de colonnes, mais avec un comportement en plus (pourquoi pas ?)
On Fri, 16 May 2008 02:55:50 -0700 (PDT), James Kanze
<james.kanze@gmail.com>:
mais d'un certain côté, on aimerait pouvoir définir
une classe ou une struct qui correspond soit à une ligne dans un
tableau, soit à une suite de colonnes, mais avec un comportement
en plus (pourquoi pas ?)
On Fri, 16 May 2008 02:55:50 -0700 (PDT), James Kanze :
mais d'un certain côté, on aimerait pouvoir définir une classe ou une struct qui correspond soit à une ligne dans un tableau, soit à une suite de colonnes, mais avec un comportement en plus (pourquoi pas ?)
Fabien LE LEZ
On Fri, 16 May 2008 02:55:50 -0700 (PDT), James Kanze :
on aimerait pouvoir définir une classe ou une struct qui correspond soit à une ligne dans un tableau, soit à une suite de colonnes,
Je suis en train de lire la doc de MySQL++, et j'ai l'impression que cette bibliothèque fait à peu près ça. http://tangentsoft.net/mysql++/doc/html/userman/tutorial.html#ssqlsintro
On Fri, 16 May 2008 02:55:50 -0700 (PDT), James Kanze
<james.kanze@gmail.com>:
on aimerait pouvoir définir
une classe ou une struct qui correspond soit à une ligne dans un
tableau, soit à une suite de colonnes,
Je suis en train de lire la doc de MySQL++, et j'ai l'impression que
cette bibliothèque fait à peu près ça.
http://tangentsoft.net/mysql++/doc/html/userman/tutorial.html#ssqlsintro
On Fri, 16 May 2008 02:55:50 -0700 (PDT), James Kanze :
on aimerait pouvoir définir une classe ou une struct qui correspond soit à une ligne dans un tableau, soit à une suite de colonnes,
Je suis en train de lire la doc de MySQL++, et j'ai l'impression que cette bibliothèque fait à peu près ça. http://tangentsoft.net/mysql++/doc/html/userman/tutorial.html#ssqlsintro
