Je développe actuellement une appli WD12 multi-sociétés. Toutes les données
sont dans la même base (MySQL 4.1).
Je suis donc obligé de gérer dans chaque table un pointeur sur la société à
qui appartient la donnée.
Ce n'est surement pas optimal au niveau du volume des données, et rend très
complexe les requetes puisque chacun d'elle doit faire le test sur ce
pointeur.
Les sociétés n'ayant à priori aucune données commune, je pensais créer une
base par société.
Mais, en environnement multi-utilisateurs, comment gérer le login des
utilisateurs afin qu'ils puissent choisir la société sur laquelle ils vont
travailler ?
Par exemple, comment remplir une combo-box avec le nom des sociétés et le
nom de la base concernée ?
Au niveau du serveur MySQL, comment reconnaître les bases qui m'
"appartiennent" et les autres ?
Pour résumer, quel principe appliqueriez vous pour gérer ce cas ?
Merci à tous
> le principal avantage d'un eclatement de base sont les perfs
oui c'est bien ce que je pensais (requetes plus simples)
le principal probleme est la consolidation si tu en as a faire (ou les mouvements inter-societes)
Gilles me parle aussi de "consolidation". Je dois avouer que je ne connais pas ce terme. Je cherche !!
un truc qui marche du tonnerre sur oracle : le partitionnement des tables : un seul fichier logique coupé en morceau sur plusieurs disques physiques
un truc sympa mais tres chaud à mettre en place : du RLS (sécurité ligne) meme si un utilisateur fait un "select * ...." il ne verra que les données auxquelles il a access. ca reduit considerablement le volume de données visible par un utilisateur (par contre, sans precaution ca peut aussi exploser les perfs des requetes)
oui mais je suis sous MySQL 4.1, donc pas de RLS. Peut-être les vues, mais je ne connais pas encore cette technique
>
le principal avantage d'un eclatement de base sont les perfs
oui c'est bien ce que je pensais (requetes plus simples)
le principal probleme est la consolidation si tu en as a faire (ou les
mouvements inter-societes)
Gilles me parle aussi de "consolidation". Je dois avouer que je ne connais
pas ce terme. Je cherche !!
un truc qui marche du tonnerre sur oracle : le partitionnement des tables
: un seul fichier logique coupé en morceau sur plusieurs disques physiques
un truc sympa mais tres chaud à mettre en place : du RLS (sécurité ligne)
meme si un utilisateur fait un "select * ...." il ne verra que les données
auxquelles il a access. ca reduit considerablement le volume de données
visible par un utilisateur (par contre, sans precaution ca peut aussi
exploser les perfs des requetes)
oui mais je suis sous MySQL 4.1, donc pas de RLS. Peut-être les vues, mais
je ne connais pas encore cette technique
> le principal avantage d'un eclatement de base sont les perfs
oui c'est bien ce que je pensais (requetes plus simples)
le principal probleme est la consolidation si tu en as a faire (ou les mouvements inter-societes)
Gilles me parle aussi de "consolidation". Je dois avouer que je ne connais pas ce terme. Je cherche !!
un truc qui marche du tonnerre sur oracle : le partitionnement des tables : un seul fichier logique coupé en morceau sur plusieurs disques physiques
un truc sympa mais tres chaud à mettre en place : du RLS (sécurité ligne) meme si un utilisateur fait un "select * ...." il ne verra que les données auxquelles il a access. ca reduit considerablement le volume de données visible par un utilisateur (par contre, sans precaution ca peut aussi exploser les perfs des requetes)
oui mais je suis sous MySQL 4.1, donc pas de RLS. Peut-être les vues, mais je ne connais pas encore cette technique
Goof
I.G.LOG a écrit :
"Goof" a écrit dans le message de news:
Merci pour cette réponse qui montre les avantages d'un système multi-base, et auxquels je n'avait pas pensé. Je voyais surtout la difficulté de programmation et de structure des tables, dans lesquelles doivent invariablement exister un pointeur société: très (trop) lourd et donc synonyme de bugs ; je vais probablement m'orienter sur cette voie, mais... quelles peuvent être les "interactions" entre deux sociétés distinctes ? Encore merci
Pour l'interaction entre les bases .... c'est ton programme qui décide. Il ne faut pas croire que la base de donnée doit tout faire toute seule. En MySql un sql du type "SELECT `base1`.`table1`.`Champ1`, `base2`.`table3`.`Champ1`, ... " doit clairement fonctionner, pour peut que l'utilisateur ait les droits sur les deux bases. Si l'idée est d'utiliser les sources de données Windev, des hdeclareexterne avec un hdecritconnexion devraient faire l'affaire pour peut qu'on les utilise correctement. Halias marche pas mal aussi ,pour des fichiers de structures identiques, mais il faut s'en méfier quand même (tester les retour d'erreurs sur les changement de connexion sinon on bosse sur le même fichier)
Bref, tout ce que la base de donnée ne fait pas toute seul, il faudra faire du code pour réaliser ces procédure.
A++ Goof
I.G.LOG a écrit :
"Goof" <goof@altern.org> a écrit dans le message de news:
Merci pour cette réponse qui montre les avantages d'un système multi-base,
et auxquels je n'avait pas pensé. Je voyais surtout la difficulté de
programmation et de structure des tables, dans lesquelles doivent
invariablement exister un pointeur société: très (trop) lourd et donc
synonyme de bugs ; je vais probablement m'orienter sur cette voie, mais...
quelles peuvent être les "interactions" entre deux sociétés distinctes ?
Encore merci
Pour l'interaction entre les bases .... c'est ton programme qui décide.
Il ne faut pas croire que la base de donnée doit tout faire toute seule.
En MySql un sql du type "SELECT `base1`.`table1`.`Champ1`,
`base2`.`table3`.`Champ1`, ... " doit clairement fonctionner, pour peut
que l'utilisateur ait les droits sur les deux bases.
Si l'idée est d'utiliser les sources de données Windev,
des hdeclareexterne avec un hdecritconnexion devraient faire l'affaire
pour peut qu'on les utilise correctement.
Halias marche pas mal aussi ,pour des fichiers de structures identiques,
mais il faut s'en méfier quand même (tester les retour d'erreurs sur les
changement de connexion sinon on bosse sur le même fichier)
Bref, tout ce que la base de donnée ne fait pas toute seul, il faudra
faire du code pour réaliser ces procédure.
Merci pour cette réponse qui montre les avantages d'un système multi-base, et auxquels je n'avait pas pensé. Je voyais surtout la difficulté de programmation et de structure des tables, dans lesquelles doivent invariablement exister un pointeur société: très (trop) lourd et donc synonyme de bugs ; je vais probablement m'orienter sur cette voie, mais... quelles peuvent être les "interactions" entre deux sociétés distinctes ? Encore merci
Pour l'interaction entre les bases .... c'est ton programme qui décide. Il ne faut pas croire que la base de donnée doit tout faire toute seule. En MySql un sql du type "SELECT `base1`.`table1`.`Champ1`, `base2`.`table3`.`Champ1`, ... " doit clairement fonctionner, pour peut que l'utilisateur ait les droits sur les deux bases. Si l'idée est d'utiliser les sources de données Windev, des hdeclareexterne avec un hdecritconnexion devraient faire l'affaire pour peut qu'on les utilise correctement. Halias marche pas mal aussi ,pour des fichiers de structures identiques, mais il faut s'en méfier quand même (tester les retour d'erreurs sur les changement de connexion sinon on bosse sur le même fichier)
Bref, tout ce que la base de donnée ne fait pas toute seul, il faudra faire du code pour réaliser ces procédure.
A++ Goof
Goof
I.G.LOG a écrit :
le principal probleme est la consolidation si tu en as a faire (ou les mouvements inter-societes)
Gilles me parle aussi de "consolidation". Je dois avouer que je ne connais pas ce terme. Je cherche !!
En gros des regroupements de données en vue de calculs de résultats statistiques.
A++ Goof
I.G.LOG
> Pour l'interaction entre les bases .... c'est ton programme qui décide. Il ne faut pas croire que la base de donnée doit tout faire toute seule. En MySql un sql du type "SELECT `base1`.`table1`.`Champ1`, `base2`.`table3`.`Champ1`, ... " doit clairement fonctionner, pour peut que l'utilisateur ait les droits sur les deux bases. Si l'idée est d'utiliser les sources de données Windev, des hdeclareexterne avec un hdecritconnexion devraient faire l'affaire pour peut qu'on les utilise correctement. Halias marche pas mal aussi ,pour des fichiers de structures identiques, mais il faut s'en méfier quand même (tester les retour d'erreurs sur les changement de connexion sinon on bosse sur le même fichier)
Bref, tout ce que la base de donnée ne fait pas toute seul, il faudra faire du code pour réaliser ces procédure.
A++ Goof
merci beaucoup pour tous ces renseignements Phil
>
Pour l'interaction entre les bases .... c'est ton programme qui décide.
Il ne faut pas croire que la base de donnée doit tout faire toute seule.
En MySql un sql du type "SELECT `base1`.`table1`.`Champ1`,
`base2`.`table3`.`Champ1`, ... " doit clairement fonctionner, pour peut
que l'utilisateur ait les droits sur les deux bases.
Si l'idée est d'utiliser les sources de données Windev,
des hdeclareexterne avec un hdecritconnexion devraient faire l'affaire
pour peut qu'on les utilise correctement.
Halias marche pas mal aussi ,pour des fichiers de structures identiques,
mais il faut s'en méfier quand même (tester les retour d'erreurs sur les
changement de connexion sinon on bosse sur le même fichier)
Bref, tout ce que la base de donnée ne fait pas toute seul, il faudra
faire du code pour réaliser ces procédure.
> Pour l'interaction entre les bases .... c'est ton programme qui décide. Il ne faut pas croire que la base de donnée doit tout faire toute seule. En MySql un sql du type "SELECT `base1`.`table1`.`Champ1`, `base2`.`table3`.`Champ1`, ... " doit clairement fonctionner, pour peut que l'utilisateur ait les droits sur les deux bases. Si l'idée est d'utiliser les sources de données Windev, des hdeclareexterne avec un hdecritconnexion devraient faire l'affaire pour peut qu'on les utilise correctement. Halias marche pas mal aussi ,pour des fichiers de structures identiques, mais il faut s'en méfier quand même (tester les retour d'erreurs sur les changement de connexion sinon on bosse sur le même fichier)
Bref, tout ce que la base de donnée ne fait pas toute seul, il faudra faire du code pour réaliser ces procédure.
A++ Goof
merci beaucoup pour tous ces renseignements Phil
Gilles
Il se trouve que I.G.LOG a formulé :
Peux tu donner un cas concret de génération de bugs, de complexité?? C'est simplissime de faire ce genre de choses, j'avoue ne pas comprendre ce qui te fait butter.
J'ai actuellement 60 tables. Pour que les données soient complètement séparées, ca implique de retrouver le pointeur société sur chacune des tables (les 60)
C'est là que je ne comprend pas. En général dans un modèle relationnel, il n'y a quand même 60 tables de niveau 1... Ou alors je ne comprend pas.
Toutes tes tables sont au même niveau??
Comme je le disais, Chaque requete doit prendre en compte le pointeur, c'est ce qui est générateur de bug !!
Je ne vois toujours pas pourquoi ;)
Dans mon cas (rare j'en suis conscient), je dois transformer une société en établissement d'une autre société: ca implique que je modifie tous les pointeurs de chaque table !!
A mon avis il y a un souci de conception mais bon c'est probablement un peu tard ;) Si tu as le courage, décris nous ton modèle (une capture d'écran) (et si ce n'est pas confidentiel bien entendu)
En tout cas, en matière de consolidation de données et d'analyse, il n'y a pas pire que d'avoir N bases.
Que veut dire "consolidation" ?
Si tu veux par exemple regrouper les données à des fin comptables ou statistiques.
Il se trouve que I.G.LOG a formulé :
Peux tu donner un cas concret de génération de bugs, de complexité??
C'est simplissime de faire ce genre de choses, j'avoue ne pas comprendre ce
qui te fait butter.
J'ai actuellement 60 tables. Pour que les données soient complètement
séparées, ca implique de retrouver le pointeur société sur chacune des tables
(les 60)
C'est là que je ne comprend pas.
En général dans un modèle relationnel, il n'y a quand même 60 tables de
niveau 1...
Ou alors je ne comprend pas.
Toutes tes tables sont au même niveau??
Comme je le disais,
Chaque requete doit prendre en compte le pointeur, c'est ce qui est
générateur de bug !!
Je ne vois toujours pas pourquoi ;)
Dans mon cas (rare j'en suis conscient), je dois transformer une société en
établissement d'une autre société: ca implique que je modifie tous les
pointeurs de chaque table !!
A mon avis il y a un souci de conception mais bon c'est probablement un
peu tard ;)
Si tu as le courage, décris nous ton modèle (une capture d'écran) (et
si ce n'est pas confidentiel bien entendu)
En tout cas, en matière de consolidation de données et d'analyse, il n'y a
pas pire que d'avoir N bases.
Que veut dire "consolidation" ?
Si tu veux par exemple regrouper les données à des fin comptables ou
statistiques.
Peux tu donner un cas concret de génération de bugs, de complexité?? C'est simplissime de faire ce genre de choses, j'avoue ne pas comprendre ce qui te fait butter.
J'ai actuellement 60 tables. Pour que les données soient complètement séparées, ca implique de retrouver le pointeur société sur chacune des tables (les 60)
C'est là que je ne comprend pas. En général dans un modèle relationnel, il n'y a quand même 60 tables de niveau 1... Ou alors je ne comprend pas.
Toutes tes tables sont au même niveau??
Comme je le disais, Chaque requete doit prendre en compte le pointeur, c'est ce qui est générateur de bug !!
Je ne vois toujours pas pourquoi ;)
Dans mon cas (rare j'en suis conscient), je dois transformer une société en établissement d'une autre société: ca implique que je modifie tous les pointeurs de chaque table !!
A mon avis il y a un souci de conception mais bon c'est probablement un peu tard ;) Si tu as le courage, décris nous ton modèle (une capture d'écran) (et si ce n'est pas confidentiel bien entendu)
En tout cas, en matière de consolidation de données et d'analyse, il n'y a pas pire que d'avoir N bases.
Que veut dire "consolidation" ?
Si tu veux par exemple regrouper les données à des fin comptables ou statistiques.
I.G.LOG
> C'est là que je ne comprend pas. En général dans un modèle relationnel, il n'y a quand même 60 tables de niveau 1... Ou alors je ne comprend pas.
Toutes tes tables sont au même niveau??
Bonjour, Pour résumer, j'ai les tables documents, articles, tiers, lignes comptables, salariés, stocks, paramètres, mouvements, chronos, ... (liste non exhaustive) qui contiennent des données spécifiques à la société. En fait, on peut considérer que seules quelques tables seraient éventuellement "communes", comme la TVA ou celle contenant des données globales (j'ai une table de variables pour gérer le type de document - Devis, Facture etc.).
Comme je le disais, Chaque requete doit prendre en compte le pointeur, c'est ce qui est générateur de bug !!
Je ne vois toujours pas pourquoi ;)
Par exemple, pour pouvoir savoir a qui appartient un document, je dois stocker le pointeur société dans la table documents:
Table documents:
docum.IDTYPE docum.CHRONO docum.REFDOC docum.DATEDOC docum.IDTIERS docum.IDSOC <- pointeur "société", cad la société qui a émis le document etc...
Dans tous les états, fenêtres... je dois tester le pointeur
Dans mon cas (rare j'en suis conscient), je dois transformer une société en établissement d'une autre société: ca implique que je modifie tous les pointeurs de chaque table !!
A mon avis il y a un souci de conception mais bon c'est probablement un peu tard ;) Si tu as le courage, décris nous ton modèle (une capture d'écran) (et si ce n'est pas confidentiel bien entendu)
Le cas dont je parle - basculer une société en établissement - vient du fait qu'initialement il y avait bien deux sociétés différentes (en tous cas du point de vue juridique), mais la 2eme a été rachetée par la 1ere ! les données doivent donc aujourd'hui être partagées: même fichier clients, documents etc...
En tout cas, en matière de consolidation de données et d'analyse, il n'y a pas pire que d'avoir N bases.
Que veut dire "consolidation" ?
Si tu veux par exemple regrouper les données à des fin comptables ou statistiques.
Je comprend. mais à l'heure actuelle, je ne vois pas de besoins particuliers dans le cas de deux sociétés vraiment distinctes.
>
C'est là que je ne comprend pas.
En général dans un modèle relationnel, il n'y a quand même 60 tables de
niveau 1...
Ou alors je ne comprend pas.
Toutes tes tables sont au même niveau??
Bonjour,
Pour résumer, j'ai les tables documents, articles, tiers, lignes comptables,
salariés, stocks, paramètres, mouvements, chronos, ... (liste non
exhaustive) qui contiennent des données spécifiques à la société.
En fait, on peut considérer que seules quelques tables seraient
éventuellement "communes", comme la TVA ou celle contenant des données
globales (j'ai une table de variables pour gérer le type de document -
Devis, Facture etc.).
Comme je le disais,
Chaque requete doit prendre en compte le pointeur, c'est ce qui est
générateur de bug !!
Je ne vois toujours pas pourquoi ;)
Par exemple, pour pouvoir savoir a qui appartient un document, je dois
stocker le pointeur société dans la table documents:
Table documents:
docum.IDTYPE
docum.CHRONO
docum.REFDOC
docum.DATEDOC
docum.IDTIERS
docum.IDSOC <- pointeur "société", cad la société qui a émis le
document
etc...
Dans tous les états, fenêtres... je dois tester le pointeur
Dans mon cas (rare j'en suis conscient), je dois transformer une société
en établissement d'une autre société: ca implique que je modifie tous les
pointeurs de chaque table !!
A mon avis il y a un souci de conception mais bon c'est probablement un
peu tard ;)
Si tu as le courage, décris nous ton modèle (une capture d'écran) (et si
ce n'est pas confidentiel bien entendu)
Le cas dont je parle - basculer une société en établissement - vient du fait
qu'initialement il y avait bien deux sociétés différentes (en tous cas du
point de vue juridique), mais la 2eme a été rachetée par la 1ere ! les
données doivent donc aujourd'hui être partagées: même fichier clients,
documents etc...
En tout cas, en matière de consolidation de données et d'analyse, il n'y
a pas pire que d'avoir N bases.
Que veut dire "consolidation" ?
Si tu veux par exemple regrouper les données à des fin comptables ou
statistiques.
Je comprend. mais à l'heure actuelle, je ne vois pas de besoins particuliers
dans le cas de deux sociétés vraiment distinctes.
> C'est là que je ne comprend pas. En général dans un modèle relationnel, il n'y a quand même 60 tables de niveau 1... Ou alors je ne comprend pas.
Toutes tes tables sont au même niveau??
Bonjour, Pour résumer, j'ai les tables documents, articles, tiers, lignes comptables, salariés, stocks, paramètres, mouvements, chronos, ... (liste non exhaustive) qui contiennent des données spécifiques à la société. En fait, on peut considérer que seules quelques tables seraient éventuellement "communes", comme la TVA ou celle contenant des données globales (j'ai une table de variables pour gérer le type de document - Devis, Facture etc.).
Comme je le disais, Chaque requete doit prendre en compte le pointeur, c'est ce qui est générateur de bug !!
Je ne vois toujours pas pourquoi ;)
Par exemple, pour pouvoir savoir a qui appartient un document, je dois stocker le pointeur société dans la table documents:
Table documents:
docum.IDTYPE docum.CHRONO docum.REFDOC docum.DATEDOC docum.IDTIERS docum.IDSOC <- pointeur "société", cad la société qui a émis le document etc...
Dans tous les états, fenêtres... je dois tester le pointeur
Dans mon cas (rare j'en suis conscient), je dois transformer une société en établissement d'une autre société: ca implique que je modifie tous les pointeurs de chaque table !!
A mon avis il y a un souci de conception mais bon c'est probablement un peu tard ;) Si tu as le courage, décris nous ton modèle (une capture d'écran) (et si ce n'est pas confidentiel bien entendu)
Le cas dont je parle - basculer une société en établissement - vient du fait qu'initialement il y avait bien deux sociétés différentes (en tous cas du point de vue juridique), mais la 2eme a été rachetée par la 1ere ! les données doivent donc aujourd'hui être partagées: même fichier clients, documents etc...
En tout cas, en matière de consolidation de données et d'analyse, il n'y a pas pire que d'avoir N bases.
Que veut dire "consolidation" ?
Si tu veux par exemple regrouper les données à des fin comptables ou statistiques.
Je comprend. mais à l'heure actuelle, je ne vois pas de besoins particuliers dans le cas de deux sociétés vraiment distinctes.
Gilles
I.G.LOG avait énoncé :
C'est là que je ne comprend pas.
Bonjour, Pour résumer, j'ai les tables documents, articles, tiers, lignes comptables, Par exemple, pour pouvoir savoir a qui appartient un document, je dois Dans tous les états, fenêtres... je dois tester le pointeur
Ca ne me choque pas ;) Je ne vois pas en quoi ce sera générateur de bugs. Donc les 60 tables sont de niveau 1?
Comment est fait l'accès aux données? (Requete paramétrées, requêtes manuelles à l'ancienne, fonctions H?)
Dans mon cas (rare j'en suis conscient), je dois transformer une société en établissement d'une autre société: ca implique que je modifie tous les pointeurs de chaque table !!
A mon avis il y a un souci de conception mais bon c'est probablement un peu tard ;) Si tu as le courage, décris nous ton modèle (une capture d'écran) (et si ce n'est pas confidentiel bien entendu)
Le cas dont je parle - basculer une société en établissement - vient du fait qu'initialement il y avait bien deux sociétés différentes (en tous cas du point de vue juridique), mais la 2eme a été rachetée par la 1ere ! les données doivent donc aujourd'hui être partagées: même fichier clients, documents etc...
Oui, il y a une ptite moulinette à faire, rien de méchant. Ca peut même se programmer de manière dynamique en listant les fichiers de l'analyse)
I.G.LOG avait énoncé :
C'est là que je ne comprend pas.
Bonjour,
Pour résumer, j'ai les tables documents, articles, tiers, lignes comptables,
Par exemple, pour pouvoir savoir a qui appartient un document, je dois
Dans tous les états, fenêtres... je dois tester le pointeur
Ca ne me choque pas ;)
Je ne vois pas en quoi ce sera générateur de bugs.
Donc les 60 tables sont de niveau 1?
Comment est fait l'accès aux données? (Requete paramétrées, requêtes
manuelles à l'ancienne, fonctions H?)
Dans mon cas (rare j'en suis conscient), je dois transformer une société
en établissement d'une autre société: ca implique que je modifie tous les
pointeurs de chaque table !!
A mon avis il y a un souci de conception mais bon c'est probablement un peu
tard ;)
Si tu as le courage, décris nous ton modèle (une capture d'écran) (et si ce
n'est pas confidentiel bien entendu)
Le cas dont je parle - basculer une société en établissement - vient du fait
qu'initialement il y avait bien deux sociétés différentes (en tous cas du
point de vue juridique), mais la 2eme a été rachetée par la 1ere ! les
données doivent donc aujourd'hui être partagées: même fichier clients,
documents etc...
Oui, il y a une ptite moulinette à faire, rien de méchant.
Ca peut même se programmer de manière dynamique en listant les fichiers
de l'analyse)
Bonjour, Pour résumer, j'ai les tables documents, articles, tiers, lignes comptables, Par exemple, pour pouvoir savoir a qui appartient un document, je dois Dans tous les états, fenêtres... je dois tester le pointeur
Ca ne me choque pas ;) Je ne vois pas en quoi ce sera générateur de bugs. Donc les 60 tables sont de niveau 1?
Comment est fait l'accès aux données? (Requete paramétrées, requêtes manuelles à l'ancienne, fonctions H?)
Dans mon cas (rare j'en suis conscient), je dois transformer une société en établissement d'une autre société: ca implique que je modifie tous les pointeurs de chaque table !!
A mon avis il y a un souci de conception mais bon c'est probablement un peu tard ;) Si tu as le courage, décris nous ton modèle (une capture d'écran) (et si ce n'est pas confidentiel bien entendu)
Le cas dont je parle - basculer une société en établissement - vient du fait qu'initialement il y avait bien deux sociétés différentes (en tous cas du point de vue juridique), mais la 2eme a été rachetée par la 1ere ! les données doivent donc aujourd'hui être partagées: même fichier clients, documents etc...
Oui, il y a une ptite moulinette à faire, rien de méchant. Ca peut même se programmer de manière dynamique en listant les fichiers de l'analyse)
I.G.LOG
> Ca ne me choque pas ;) Je ne vois pas en quoi ce sera générateur de bugs. Donc les 60 tables sont de niveau 1?
je ne comprends pas "de niveau 1", mais oui ces tables (et d'autres) doivent contenir le pointeur
Comment est fait l'accès aux données? (Requete paramétrées, requêtes manuelles à l'ancienne, fonctions H?)
Requètes manuelles (par sqlexec)
Oui, il y a une ptite moulinette à faire, rien de méchant. Ca peut même se programmer de manière dynamique en listant les fichiers de l'analyse)
Oui bien sur, mais je dois étudier ça pour être sur de mon coup
Entout cas merci pour tes réponses
>
Ca ne me choque pas ;)
Je ne vois pas en quoi ce sera générateur de bugs.
Donc les 60 tables sont de niveau 1?
je ne comprends pas "de niveau 1", mais oui ces tables (et d'autres) doivent
contenir le pointeur
Comment est fait l'accès aux données? (Requete paramétrées, requêtes
manuelles à l'ancienne, fonctions H?)
Requètes manuelles (par sqlexec)
Oui, il y a une ptite moulinette à faire, rien de méchant.
Ca peut même se programmer de manière dynamique en listant les fichiers de
l'analyse)
Oui bien sur, mais je dois étudier ça pour être sur de mon coup
> Ca ne me choque pas ;) Je ne vois pas en quoi ce sera générateur de bugs. Donc les 60 tables sont de niveau 1?
je ne comprends pas "de niveau 1", mais oui ces tables (et d'autres) doivent contenir le pointeur
Comment est fait l'accès aux données? (Requete paramétrées, requêtes manuelles à l'ancienne, fonctions H?)
Requètes manuelles (par sqlexec)
Oui, il y a une ptite moulinette à faire, rien de méchant. Ca peut même se programmer de manière dynamique en listant les fichiers de l'analyse)
Oui bien sur, mais je dois étudier ça pour être sur de mon coup
Entout cas merci pour tes réponses
Gilles
I.G.LOG a pensé très fort :
Ca ne me choque pas ;) Je ne vois pas en quoi ce sera générateur de bugs. Donc les 60 tables sont de niveau 1?
je ne comprends pas "de niveau 1", mais oui ces tables (et d'autres) doivent contenir le pointeur
Cad si tu as des factures... Tu as des entêtes de factures, et des lignes de facture. tu ne pose ta clé étrangère que sur la table des entête rassure moi?
Comment est fait l'accès aux données? (Requete paramétrées, requêtes manuelles à l'ancienne, fonctions H?)
Requètes manuelles (par sqlexec)
Ha forcément, ca va pas aider à faire un truc générique... quoi que... Synchronise ton analyse avec ta base
ainsi tu pourras connaitre toute les tables qui contiennent ta clé étrangère.
Code toi un générateur de requête (genre "addcolumn", "addtable", "add clause" etc... et dans le code du générateur tu vérifies pour toutes les tables si la clé étrangère est présente, et tu ajoutes les clauses where de la société automatiqyement. Comme ça tu n'auras jamais à gérer la clé de la société dans le code.
Oui, il y a une ptite moulinette à faire, rien de méchant. Ca peut même se programmer de manière dynamique en listant les fichiers de l'analyse)
Oui bien sur, mais je dois étudier ça pour être sur de mon coup Entout cas merci pour tes réponses
I.G.LOG a pensé très fort :
Ca ne me choque pas ;)
Je ne vois pas en quoi ce sera générateur de bugs.
Donc les 60 tables sont de niveau 1?
je ne comprends pas "de niveau 1", mais oui ces tables (et d'autres) doivent
contenir le pointeur
Cad si tu as des factures...
Tu as des entêtes de factures, et des lignes de facture.
tu ne pose ta clé étrangère que sur la table des entête rassure moi?
Comment est fait l'accès aux données? (Requete paramétrées, requêtes
manuelles à l'ancienne, fonctions H?)
Requètes manuelles (par sqlexec)
Ha forcément, ca va pas aider à faire un truc générique...
quoi que...
Synchronise ton analyse avec ta base
ainsi tu pourras connaitre toute les tables qui contiennent ta clé
étrangère.
Code toi un générateur de requête (genre "addcolumn", "addtable", "add
clause" etc... et dans le code du générateur tu vérifies pour toutes
les tables si la clé étrangère est présente, et tu ajoutes les clauses
where de la société automatiqyement.
Comme ça tu n'auras jamais à gérer la clé de la société dans le code.
Oui, il y a une ptite moulinette à faire, rien de méchant.
Ca peut même se programmer de manière dynamique en listant les fichiers de
l'analyse)
Oui bien sur, mais je dois étudier ça pour être sur de mon coup
Entout cas merci pour tes réponses
Ca ne me choque pas ;) Je ne vois pas en quoi ce sera générateur de bugs. Donc les 60 tables sont de niveau 1?
je ne comprends pas "de niveau 1", mais oui ces tables (et d'autres) doivent contenir le pointeur
Cad si tu as des factures... Tu as des entêtes de factures, et des lignes de facture. tu ne pose ta clé étrangère que sur la table des entête rassure moi?
Comment est fait l'accès aux données? (Requete paramétrées, requêtes manuelles à l'ancienne, fonctions H?)
Requètes manuelles (par sqlexec)
Ha forcément, ca va pas aider à faire un truc générique... quoi que... Synchronise ton analyse avec ta base
ainsi tu pourras connaitre toute les tables qui contiennent ta clé étrangère.
Code toi un générateur de requête (genre "addcolumn", "addtable", "add clause" etc... et dans le code du générateur tu vérifies pour toutes les tables si la clé étrangère est présente, et tu ajoutes les clauses where de la société automatiqyement. Comme ça tu n'auras jamais à gérer la clé de la société dans le code.
Oui, il y a une ptite moulinette à faire, rien de méchant. Ca peut même se programmer de manière dynamique en listant les fichiers de l'analyse)
Oui bien sur, mais je dois étudier ça pour être sur de mon coup Entout cas merci pour tes réponses
