Bonjour,
Fidèle de ce forum (et de quelques autres), j'ai toujours été attiré par le
coté rationel et organisé d'access et en générale, par les sgdb
relationelles (access, sql, mysql..).
Je découvre ces derniers temps des solutions basées sur sql ou mysql qui
remettent un peu ma conception des bases de données relationelles et
j'aimerais comprendre.
Pour exemple, une application CRM Vtiger dévelopée sous php/mysql et Office
accounting 2007 (.net+ sqlserver2005).
Ces deux solutions ont comme point commun un nombre incroyable de tables
(plus d'une centaine).
à y regarder de plus près, on a l'impression que pas mal de table
représentent plutot des bout de tables representant des parties de fonctions
( mon impression)..
Je sais qu'il est parfois préférable pour des raisons de performance de
sortir un peu du cadre, mais la je ne comprend pas.
d'ou ma question:
quelle est la raison de la multiplication des tables?
mode? raisons techniques?
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
Raymond [mvp]
Bonjour.
une toute petite idée.
ce qu'on reproche à access c'est qu'il balance la globalité des informations sur le reséau alors qu'il n'a besoin que de quelques petites infos données par un champ. chaque fois qu'on va lire une table, on lit la globalité de l'enregistrement. alors que lorsqu'on a défini des morceaux de tables "intelligents" on se positionne par pointeur seulement et on ne lit que quelques éléments ce qui améliore formidablement les performances d'access. je ne sais pas si tu as connu le cobol mais ce langage a connu les mêmes problèmes. à l'origine, on coupait les tables pour pallier aux "non performances" du matériel et plus les performances matériels" ont augmenté, plus on a regroupé les tables et plus on a dégradé les performances du langage. on est arrivé à re-partager les tables pour retrouver les performances optimales. access c'est pareil, on a groupé au maximum les tables pour en faire des monstres et se faciliter la tâche et on s'aperçoit maintenant que cette base relationnelle n'est plus performante en terme de temps d'accès sur les réseaux et on redécouvre le saucissonnage du bon vieux temps pour retrouver les performances.
on pourrait en dire encore bien long mais j'arrête là.
-- @+ Raymond Access MVP http://OfficeSystem.Access.free.fr/ Pour débuter sur le forum: http://www.mpfa.info/ Le 26 Avril 2007 à 14h assistez à la web TV et faites avancer la recherche dans votre entreprise http://www.comscamp.com/Tracker/Redirect.ashx?linkidDb8ed66-f9f8-456a-bdc8-993dda7415fc
"FreThi" a écrit dans le message de news:
| Bonjour, | Fidèle de ce forum (et de quelques autres), j'ai toujours été attiré par le | coté rationel et organisé d'access et en générale, par les sgdb | relationelles (access, sql, mysql..). | Je découvre ces derniers temps des solutions basées sur sql ou mysql qui | remettent un peu ma conception des bases de données relationelles et | j'aimerais comprendre. | Pour exemple, une application CRM Vtiger dévelopée sous php/mysql et Office | accounting 2007 (.net+ sqlserver2005). | Ces deux solutions ont comme point commun un nombre incroyable de tables | (plus d'une centaine). | à y regarder de plus près, on a l'impression que pas mal de table | représentent plutot des bout de tables representant des parties de fonctions | ( mon impression).. | Je sais qu'il est parfois préférable pour des raisons de performance de | sortir un peu du cadre, mais la je ne comprend pas. | d'ou ma question: | quelle est la raison de la multiplication des tables? | mode? raisons techniques? | | en vous remerciant, | Frédéric |
Bonjour.
une toute petite idée.
ce qu'on reproche à access c'est qu'il balance la globalité des informations
sur le reséau alors qu'il n'a besoin que de quelques petites infos données
par un champ. chaque fois qu'on va lire une table, on lit la globalité de
l'enregistrement. alors que lorsqu'on a défini des morceaux de tables
"intelligents" on se positionne par pointeur seulement et on ne lit que
quelques éléments ce qui améliore formidablement les performances d'access.
je ne sais pas si tu as connu le cobol mais ce langage a connu les mêmes
problèmes. à l'origine, on coupait les tables pour pallier aux "non
performances" du matériel et plus les performances matériels" ont augmenté,
plus on a regroupé les tables et plus on a dégradé les performances du
langage. on est arrivé à re-partager les tables pour retrouver les
performances optimales.
access c'est pareil, on a groupé au maximum les tables pour en faire des
monstres et se faciliter la tâche et on s'aperçoit maintenant que cette base
relationnelle n'est plus performante en terme de temps d'accès sur les
réseaux et on redécouvre le saucissonnage du bon vieux temps pour retrouver
les performances.
on pourrait en dire encore bien long mais j'arrête là.
--
@+
Raymond Access MVP http://OfficeSystem.Access.free.fr/
Pour débuter sur le forum: http://www.mpfa.info/
Le 26 Avril 2007 à 14h assistez à la web TV et faites avancer la recherche
dans votre entreprise
http://www.comscamp.com/Tracker/Redirect.ashx?linkidDb8ed66-f9f8-456a-bdc8-993dda7415fc
"FreThi" <FreThi@matloc.be> a écrit dans le message de news:
F909036F-84C7-4BD0-B548-84D0F430B74B@microsoft.com...
| Bonjour,
| Fidèle de ce forum (et de quelques autres), j'ai toujours été attiré par
le
| coté rationel et organisé d'access et en générale, par les sgdb
| relationelles (access, sql, mysql..).
| Je découvre ces derniers temps des solutions basées sur sql ou mysql qui
| remettent un peu ma conception des bases de données relationelles et
| j'aimerais comprendre.
| Pour exemple, une application CRM Vtiger dévelopée sous php/mysql et
Office
| accounting 2007 (.net+ sqlserver2005).
| Ces deux solutions ont comme point commun un nombre incroyable de tables
| (plus d'une centaine).
| à y regarder de plus près, on a l'impression que pas mal de table
| représentent plutot des bout de tables representant des parties de
fonctions
| ( mon impression)..
| Je sais qu'il est parfois préférable pour des raisons de performance de
| sortir un peu du cadre, mais la je ne comprend pas.
| d'ou ma question:
| quelle est la raison de la multiplication des tables?
| mode? raisons techniques?
|
| en vous remerciant,
| Frédéric
|
ce qu'on reproche à access c'est qu'il balance la globalité des informations sur le reséau alors qu'il n'a besoin que de quelques petites infos données par un champ. chaque fois qu'on va lire une table, on lit la globalité de l'enregistrement. alors que lorsqu'on a défini des morceaux de tables "intelligents" on se positionne par pointeur seulement et on ne lit que quelques éléments ce qui améliore formidablement les performances d'access. je ne sais pas si tu as connu le cobol mais ce langage a connu les mêmes problèmes. à l'origine, on coupait les tables pour pallier aux "non performances" du matériel et plus les performances matériels" ont augmenté, plus on a regroupé les tables et plus on a dégradé les performances du langage. on est arrivé à re-partager les tables pour retrouver les performances optimales. access c'est pareil, on a groupé au maximum les tables pour en faire des monstres et se faciliter la tâche et on s'aperçoit maintenant que cette base relationnelle n'est plus performante en terme de temps d'accès sur les réseaux et on redécouvre le saucissonnage du bon vieux temps pour retrouver les performances.
on pourrait en dire encore bien long mais j'arrête là.
-- @+ Raymond Access MVP http://OfficeSystem.Access.free.fr/ Pour débuter sur le forum: http://www.mpfa.info/ Le 26 Avril 2007 à 14h assistez à la web TV et faites avancer la recherche dans votre entreprise http://www.comscamp.com/Tracker/Redirect.ashx?linkidDb8ed66-f9f8-456a-bdc8-993dda7415fc
"FreThi" a écrit dans le message de news:
| Bonjour, | Fidèle de ce forum (et de quelques autres), j'ai toujours été attiré par le | coté rationel et organisé d'access et en générale, par les sgdb | relationelles (access, sql, mysql..). | Je découvre ces derniers temps des solutions basées sur sql ou mysql qui | remettent un peu ma conception des bases de données relationelles et | j'aimerais comprendre. | Pour exemple, une application CRM Vtiger dévelopée sous php/mysql et Office | accounting 2007 (.net+ sqlserver2005). | Ces deux solutions ont comme point commun un nombre incroyable de tables | (plus d'une centaine). | à y regarder de plus près, on a l'impression que pas mal de table | représentent plutot des bout de tables representant des parties de fonctions | ( mon impression).. | Je sais qu'il est parfois préférable pour des raisons de performance de | sortir un peu du cadre, mais la je ne comprend pas. | d'ou ma question: | quelle est la raison de la multiplication des tables? | mode? raisons techniques? | | en vous remerciant, | Frédéric |
