Bonjour à tous,

Je vous expose mon interrogation.

Vaut il mieux dans un projet de gestion utiliser plusieurs bases de données (1 base Offre, 1 base Réception, 1 base Production....) et plusieurs interfaces ou 1 seule base qui contient toutes les tables ?

A l'heure actuelle, je travaille pour une société qui s'est créée une ERP en Access97 (:/) sans aucune notion élémentaire de Gestion relationnelle.

D'où la situation actuelle: un 30° de base de données ACCESS97 (et parfois 2.0) avec des tables en pagailles et pour tout interface .... toujours Access97 avec tables attachées.

Problèmatique: Nous sommes 80 à travailler sur de multiples bdd Access97 (Data+interface) et ca rame de plus en plus pour les ouvertures, affichage des données, modifications ....

Mon Directeur Informatique ne souhaitant pas passer sous MYSQL (oO), cherche un moyen de réduire les temps d'accès aux données par les interfaces et souhaite regrouper la 100° de tables existantes (aujourd'hui, dans plusieurs bases) dans 1 seule base de données....

Étant obligé de "composer" avec ses "idées géniales", quelle solution vous semble la plus "acceptable" en terme de performance (Hors Mysql ^^) ?

- 1 base d'une 100° de tables (parfois très grosses)
ou
- 50 bases d'une 10° de tables

Merci déjà pour votre lecture

Citation : Bim33

Vaut il mieux dans un projet de gestion utiliser plusieurs bases de données (1 base Offre, 1 base Réception, 1 base Production....) et plusieurs interfaces ou 1 seule base qui contient toutes les tables ?

Hé bien c'est simple, tu traces un joli modèle de tes données, tu suis les flèches (relations) entre les tables, et toutes les données qui sont en relation ne peuvent donc être que dans la même base de données ! Sinon pas de relations.

Après, entre des applications distinctes qui ont des données distinctes qui ne sont pas en relation, tu peux les mettre dans des bases séparées (plus propre, plus étanche, plus facile à sauvegarder)...

Mais bon vu qu'il y a probablement une table "clients" qui est plus ou moins liée à tout, une seule BDD sera probablement la solution.

> A l'heure actuelle, je travaille pour une société qui s'est créée une ERP en Access97 (:/)
> sans aucune notion élémentaire de Gestion relationnelle.

UUEEEEAAAAAAAAAAARGL

> Problèmatique: Nous sommes 80 à travailler sur de multiples bdd Access97 (Data+interface)
> et ca rame de plus en plus pour les ouvertures, affichage des données, modifications ....

Normal, Access rame si tu lui demandes de faire le boulot d'une vraie BDD... pas fait pour...

> Mon Directeur Informatique ne souhaitant pas passer sous MYSQL (oO)

Il a raison bien sûr, les solutions ne manquent pas : postgres, sql server, etc, pourquoi quitter un enfer pour un autre ?

> quelle solution vous semble la plus "acceptable" en terme de performance (Hors Mysql ^^) ?

tout ce gentil merdier doit communiquer en ODBC, donc tu mets postgres, sql server ou autre, hop

> - 1 base d'une 100° de tables (parfois très grosses)
> - 50 bases d'une 10° de tables

Si tu es cdiscount et que tes BDDs est suffisamment grosses pour arriver à faire transpirer légèrement un serveur (pas sous access s'entend) et que tu as un découpage propre en bases de données séparées (voir plus haut) tu peux effectivement répartir des BDD sur des serveurs différents, ou répliquer, etc.

Sinon aucune différence (pour une vraie BDD, pour access je sais pas). Dans ton cas AMHA (sauf si tu es cdiscount) le problème est 1) ACCESS 2) la conception de la BDD qui est ptobablement dégueulasse.

Crosoft a des outils pour migrer de access à sql server, jette un oeil. Ça ne réglera pas ton problème de conception...

PPS : en argot de BDD, "très grosse" pour une table c'est plus de 100 Go au moins, donc c'est quoi la taille de la BDD ?

Merci de ton intervention

Par préférence personnelle, je regroupe toujours les Tables qui sont en relation dans une même bdd
(quand je peux le faire dans la mesure ou mon cher Dir. Info. fièrement autodidacte, s'attribue les analyses des projets informatiques .... la plus part du temps je dois faire avec des tables aux données inutiles ou répétées, avec des noms non conformes et aucune optimisation => c est une contrainte sur laquelle je ne peux intervenir :/)

[quote="Lord casque Noir"]
> Mon Directeur Informatique ne souhaitant pas passer sous MYSQL (oO)

Il a raison bien sûr, les solutions ne manquent pas : postgres, sql server, etc, pourquoi quitter un enfer pour un autre ?
[/quote]

je ne saisie pas trop le sens (ironique ?^^) de ta phrase ;).
MySql a t'il aussi mauvaise réputation que Access ???? impossible

Sql server est payant il me semble ?
dans la mesure ou mon dir. n'est pas chaud pour passer sur autre chose qu'Access (il ne connait qu'Access97 il ne pourra plus faire joujou à l'informaticien sinon) si en plus je lui soumet une solution payante je vais droit au casse pipe.

Dans tous les cas je me rends compte que ma question porte surtout sur les (dis)fonctionnements d'ACCESS97 en mode multi utilisateurs pas sur qu'il y ait une solution appropriée (et encore moins "propre") pour faire que de multiples bases Access97 mal construites et très nombreuses (re)deviennent rapides et fluides .... que ce soit en regroupant toutes les bases dans 1 seule ou rester dans l'architecture actuelle.

Je recentre ma question donc, est ce que passer sous MySql (ou autres SGBD gratuit) sans toucher à la structure bancale (vous avez pas idée :'() des tables, suffira à obtenir des gains en rapidité de traitements ?

Il est bien sur hors de question pour mon Dir. de me faire re développer son "Oeuvre".... et ainsi partir sur une structure propre (enfin d'une point de vue d'informaticien ^^)

> Par préférence personnelle,
> je regroupe toujours les Tables qui sont en relation dans une même bdd

En fait c'est plus que ça : si tu les mets pas dans la même base, tu peux difficilement poser des FOREIGN KEYS, donc t'as pas de relations du tout.

> je ne saisie pas trop le sens (ironique ?^^) de ta phrase ;).

Quitte à refaire le truc sur une base de données, autant utiliser une vraie base de données puissante qui te permettra de faire les choses proprement sans te prendre la tête. MySQL ne fait pas partie de cette liste XD

Ton boss est apparemment un neuneu qui est parti guillerettement pisser du code sans vision globale de la chose et sans les connaissances nécessaires (sans parler bien sûr de concepts hautement improbables comme cahier des charges, charte qualité, etc) a chié conçu un monstre composé de couches multiples et inextricables de machins qui se sont accumulés au cours du temps. J'ai pitié pour toi.

Sinon, là où je suis ironique, c'est que oui, ton boss a raison de ne pas vouloir utiliser MySQL, mais pas pour les bonnes raisons (en fait je suppute qu'il n'en a aucune idée).

> Sql server est payant il me semble ?

Pas pour les petites bases, et puis bon, t'es dans une entreprise, chiffre le coût en heures de main d'oeuvre à chaque fois qu'Access éternue, tu verras. Postgres est gratuit, lui.

> il ne connait qu'Access97

Le pronostic s'aggrave.

> les (dis)fonctionnements d'ACCESS97 en mode multi utilisateurs

Il y a un mode multi-utilisateurs dans Access ?

En fait j'y connais pas grand chose en Access, mis à part que j'ai vu des applis Access tourner, et ça m'a suffi. 10 minutes pour charger une page web de backoffice... Dans mon ancienne boîte on avait tout redéveloppé sous Oracle.

> Je recentre ma question donc, est ce que passer sous MySql (ou autres SGBD gratuit)
> sans toucher à la structure bancale (vous avez pas idée :'() des tables,
> suffira à obtenir des gains en rapidité de traitements ?

Ça dépend de la dite structure, faut voir, peut-être.

Note que si tu fais des jointures sur des tables pourries sans index mais pas trop grosses (quelques dizaines de milliers de lignes), MySQL est à la ramasse, postgres a le Hash Join et autres astuces donc ça peut mieux passer.

Ok merci bcp

Je vais clôturer le post (sinon je vais continuer a cracher mon désarroi de bosser dans ces conditions^^ et tu as bien vu pour le "Monstre" que j'essaie de faire rentrer dans le droit chemin) et voir du cote de PostGres que je ne connaissais pas ou de SqlServer quitte a monter un dossier solide.

Merci de tes éclaircissement et ta pitié à ma cause

Bonne chance XD

Si tu veux de l'aide pour postgres, pas de problème.