|
Publicité ' | |||||||||||||||||||||||
|
|
#1 |
|
Nouveau Membre du Club
![]() Inscription : avril 2005 Messages : 79 ![]() |
Bonjour,
je dois ré écrire une base de données Access (Table, Requête, Formulaire, Etat et module) dans un nouveau language. Le language adopté est Delphi. Il me reste à choisir la base de données. J'ai repris un tableau trouvé sur le net, j'ai ajouté d'autres bases et j'ai fais mes recherches (sans tester). 1 - MS SQL Server 2000 : OS : Windows Open source : Non Gestion des transactions : Oui Requête imbriquées : Oui Vues : Oui Intégrité Référentielle : Oui Trigger : Oui Procédures Stockées : Oui Sauvegarde : à chaud License : Payante Outils frontaux : oui Pourquoi la choisir : base de données complexes, requête complexes 2 - Oracle 10g SE: OS : Windows, Linux Open source : Non Gestion des transactions : Oui Requête imbriquées : Oui Vues : Oui Intégrité Référentielle : Oui Trigger : Oui Procédures Stockées : Oui Sauvegarde : à chaud License : Payante Outils frontaux : oui Pourquoi la choisir : base de données complexes, requête complexes 3 - MySQL v.4 : OS : Windows Open source : Oui Gestion des transactions : Oui Requête imbriquées : non Vues : non Intégrité Référentielle : Oui en mode InnoDB et BDB Trigger : Non Procédures Stockées : Non Sauvegarde : Utilitaire mysqldump License : Payante en cas de commercialisation Outils frontaux : MySQL Control center Pourquoi la choisir : base de données simples, pages web dynamiques, alternative gratuite à Access 4 - Postgre SQL : OS : Linux, Unix Open source : Oui Gestion des transactions : Oui Requête imbriquées : Oui Vues : Oui Intégrité Référentielle : Oui Trigger : Oui Procédures Stockées : Oui Sauvegarde : pg dump License : gratuite Outils frontaux : PostgreSQL admin tools Pourquoi la choisir : base de données complexes, requête complexes, alternative à Oracle 5 - Interbase : OS : Windows, Linux Open source : Oui version 6 Gestion des transactions : Oui Requête imbriquées : ??? Vues : Oui Intégrité Référentielle : Oui Trigger : ??? Procédures Stockées : Oui Sauvegarde : ??? License : Payante à partir de la v7 Outils frontaux : ??? Pourquoi la choisir : ??? Comment se passe le chargement des tables Access dans les autres bases de données que SQL Server ? Existe t'il des outils spécifiques ? Merci de m'aider à compléter ce tableau. Alexandre |
|
|
00
|
|
|
#2 | |
![]() ![]() Alain Ingénieur d'études décisionnel Inscription : mai 2002 Messages : 4 451 ![]() |
Citation:
Il n'est plus très difficile alors de créer les requêtes d'exportation des données depuis Access vers ce nouveau SGBD. |
|
|
|
00
|
|
|
#3 |
![]() ![]() |
Quelques correctifs:
1 - MS SQL Server 2000 : OS : Windows Open source : Non Gestion des transactions : Oui Requête imbriquées : Oui Vues : Oui Intégrité Référentielle : Oui Trigger : Oui Procédures Stockées : Oui Sauvegarde : à chaud License : Payante Outils frontaux : oui, mais pas en ce qui concerne le développement Pourquoi la choisir : indépendance des bases de données, autonomic computing, architecture relativement simple 2 - Oracle 10g SE: OS : Windows, Linux, Unix Open source : Non Gestion des transactions : Oui Requête imbriquées : Oui Vues : Oui Intégrité Référentielle : Oui Trigger : Oui Procédures Stockées : Oui Sauvegarde : à chaud et à froid License : Payante Outils frontaux : oui, mais pas simple d'utilisation Pourquoi la choisir : base de données complexes, requête complexes, gros budgets, leader du marché 3 - MySQL v.4 : OS : Windows, Linux Open source : Oui Gestion des transactions : Oui, mais seulement via innodb (payant) Requête imbriquées : non Vues : non Intégrité Référentielle : Oui en mode InnoDB et BDB Trigger : Non Procédures Stockées : Non Sauvegarde : Utilitaire mysqldump License : Payante en cas de commercialisation Outils frontaux : MySQL Control center Pourquoi la choisir : base de données simples, pages web dynamiques, alternative gratuite (selon option !) à Access 4 - Postgre SQL : OS : Linux, Unix, Windows Open source : Oui Gestion des transactions : Oui Requête imbriquées : Oui Vues : Oui Intégrité Référentielle : Oui Trigger : Oui Procédures Stockées : Oui Sauvegarde : pg dump License : gratuite Outils frontaux : PostgreSQL admin tools Pourquoi la choisir : base de données simple à administrer, requête complexes, ne convient pas pour de gros volumes 5 - Interbase : OS : Windows, Linux Open source : Oui version 6 Gestion des transactions : Oui Requête imbriquées : ??? Vues : Oui Intégrité Référentielle : Oui Trigger : ??? Procédures Stockées : Oui Sauvegarde : ??? License : Payante à partir de la v7 Outils frontaux : ??? Pourquoi la choisir : intégration aux autre produits Borland, administration aisée, ne convient pas pour de gros volumes
__________________
Sr DBA Oracle / Sybase / MS-SQL / DB2 / Informix / Postgresql Administrateur SAP Attention : pas de réponse technique par MP : pensez aux autres, passez par les forums ! |
|
|
00
|
|
|
#4 |
|
Nouveau Membre du Club
![]() Inscription : avril 2005 Messages : 79 ![]() |
Bonjour,
quant on parle de gros volume, on parle du nombre de connection ou de la taille de la base de données ? A partir de quand considère t'on que l'on a un gros volume ? Merci d'avance. |
|
|
00
|
|
|
#5 |
![]() ![]() |
Il y a des deux : le nombre de transactions couplé au nombre d'utilisateurs concurrents, et la taille des tables.
Pour les tables, c'est difficile à dire car ça ne dépend pas que du nombre d'enregistrements, mais aussi de la longueur des tuples et du nombre d'indexes...
__________________
Sr DBA Oracle / Sybase / MS-SQL / DB2 / Informix / Postgresql Administrateur SAP Attention : pas de réponse technique par MP : pensez aux autres, passez par les forums ! |
|
|
00
|
|
|
#6 |
|
Membre expérimenté
![]() ![]() Inscription : mai 2005 Messages : 414 ![]() |
pourquoi ne considères tu pas le cas de DB2?
Il y a quelques années on considérait qu'on arrivait sur des gros volumes à 100Go de données. Maintenant ce sont des volumétries relativement courantes donc on prend en considération également le nb de connexions, le type de base (OLTP, OLAP), etc..., etc... |
|
|
00
|
Copyright © 2000-2012 - www.developpez.com