IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Décisions SGBD Discussion :

Quelle base de données pourrais-je utiliser pour une forte volumétrie ?


Sujet :

Décisions SGBD

  1. #1
    Membre du Club
    Inscrit en
    Septembre 2006
    Messages
    65
    Détails du profil
    Informations forums :
    Inscription : Septembre 2006
    Messages : 65
    Points : 55
    Points
    55
    Par défaut Quelle base de données pourrais-je utiliser pour une forte volumétrie ?
    Bonjour à tous,

    Je suis en train de cherche un SGBD pour gérer des tables qui avec une volumétrie de 3 million lignes de données (par contre, il y a pas trop de colonnes).

    Il me semble que, pour quelques genres de base, c'est limité pour la volumétrie d'une table (le nombre de ligne).

    J'ai donc besoin de vos conseils. Merci de me donner quelques idées.
    Je vous remercie par avance!


  2. #2
    Membre à l'essai
    Inscrit en
    Octobre 2008
    Messages
    7
    Détails du profil
    Informations forums :
    Inscription : Octobre 2008
    Messages : 7
    Points : 10
    Points
    10
    Par défaut
    quel serveur utiliser vous ?

    de preference j'aimerais que tu utlises le WINDEV ou ORACLE
    ou SQL SERVEUR

  3. #3
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 768
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 768
    Points : 52 577
    Points
    52 577
    Billets dans le blog
    5
    Par défaut
    Le nombre de lignes n'est pas un critère de volumétrie. 100 millions de lignes d'une table composée d'une seule colonne d'un seul entier représentent moins d'un giga octet de données...

    En revanche sur tu entends par forte volumétrie des bases dont le volume est supérieur au Téra octet, alors il faut les outils qui vont avec : réindexation en ligne, partitionnement, gestion des espaces de stockage, sauvegardes partielles...
    Bref, peu de monde dans ce giron, à l'exception de IBM DB2, Oracle ou SQL Server...

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

  4. #4
    Modérateur
    Avatar de al1_24
    Homme Profil pro
    Retraité
    Inscrit en
    Mai 2002
    Messages
    9 080
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 63
    Localisation : France, Val de Marne (Île de France)

    Informations professionnelles :
    Activité : Retraité
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Mai 2002
    Messages : 9 080
    Points : 30 801
    Points
    30 801
    Par défaut
    Citation Envoyé par SQLpro Voir le message
    Bref, peu de monde dans ce giron, à l'exception de IBM DB2, Oracle ou SQL Server...
    Tu oublies Teradata, pour lequel une base d'un tera est une petite base.
    Modérateur Langage SQL
    Règles du forum Langage SQL à lire par tous, N'hésitez pas à consulter les cours SQL
    N'oubliez pas le bouton et pensez aux balises
    [code]
    Si une réponse vous a aidé à résoudre votre problème, n'oubliez pas de voter pour elle en cliquant sur
    Aide-toi et le forum t'aidera : Un problème exposé sans mentionner les tentatives de résolution infructueuses peut laisser supposer que le posteur attend qu'on fasse son travail à sa place... et ne donne pas envie d'y répondre.

  5. #5
    Membre du Club
    Inscrit en
    Septembre 2006
    Messages
    65
    Détails du profil
    Informations forums :
    Inscription : Septembre 2006
    Messages : 65
    Points : 55
    Points
    55
    Par défaut
    Bonjour,

    Je suis sous l'environnement Windows, j'utilise au début une base Access pour cela, mais elle plante quelques fois. Je pense donc à SQL server.
    Néanmoins, je ne sais pas trop comment l'utiliser. Peut-être je dois étudier son tuto d'abord.
    Mais à votre avie, c'est possible de continuer utiliser Access ou pas?

    En tout cas, merci pour votre aide.


  6. #6
    Membre éclairé

    Profil pro
    Inscrit en
    Mai 2005
    Messages
    414
    Détails du profil
    Informations personnelles :
    Localisation : France

    Informations forums :
    Inscription : Mai 2005
    Messages : 414
    Points : 671
    Points
    671
    Par défaut
    si Access, alors ta base doit être quand meme très petite en terme de volume.

    Maintenant si tu as des soucis avec, n'hesite effectivement pas à passer vers SQL Server sachant qu'il y aura un coup de redeveloppement applicatif.

    Teradata, c'est quand meme plus pour du BI non?

  7. #7
    Rédacteur

    Avatar de SQLpro
    Homme Profil pro
    Expert bases de données / SQL / MS SQL Server / Postgresql
    Inscrit en
    Mai 2002
    Messages
    21 768
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Localisation : France, Var (Provence Alpes Côte d'Azur)

    Informations professionnelles :
    Activité : Expert bases de données / SQL / MS SQL Server / Postgresql
    Secteur : Conseil

    Informations forums :
    Inscription : Mai 2002
    Messages : 21 768
    Points : 52 577
    Points
    52 577
    Billets dans le blog
    5
    Par défaut
    Access est considéré comme obsolète par Microsoft depuis de nombreuses années et aucun développement nouveau n'est plus entrepris pour assurer la pérénité du moteur. Microsoft conseille de migrer vers SQL Servrer en remplacement d'Access depuis très longtemps ! En particulier il n'est pas prévu de porter Access vers le 64 bits.

    Lisez ce que dit wikipedia au sujet du moteur Jet d'access :
    http://en.wikipedia.org/wiki/Microso...atabase_Engine
    notamment rubique "future".

    Tu oublies Teradata, pour lequel une base d'un tera est une petite base.
    C'est vrai, et pour deux raisons :
    1) je ne l'ais jamais pratiqué, alors que les autres oui
    2) Teradata est loin d'être aussi populaire que ces trois là et même Sybase est plus connu et couru que Teradata !

    A +
    Frédéric Brouard - SQLpro - ARCHITECTE DE DONNÉES - expert SGBDR et langage SQL
    Le site sur les SGBD relationnels et le langage SQL: http://sqlpro.developpez.com/
    Blog SQL, SQL Server, SGBDR : http://blog.developpez.com/sqlpro
    Expert Microsoft SQL Server - M.V.P. (Most valuable Professional) MS Corp.
    Entreprise SQL SPOT : modélisation, conseils, audit, optimisation, formation...
    * * * * * Expertise SQL Server : http://mssqlserver.fr/ * * * * *

Discussions similaires

  1. Réponses: 5
    Dernier message: 13/06/2014, 14h14
  2. Réponses: 42
    Dernier message: 07/08/2009, 21h11
  3. Quelle base de données je pourrais utiliser pour divers reporting ?
    Par xianxian620 dans le forum Décisions SGBD
    Réponses: 3
    Dernier message: 10/04/2008, 21h00
  4. Quelle base de données choisir pour sa facilité d'utilisation ?
    Par gibea00 dans le forum Décisions SGBD
    Réponses: 7
    Dernier message: 13/03/2008, 11h29
  5. Quelle base de donnée utiliser?
    Par VTwin dans le forum Décisions SGBD
    Réponses: 5
    Dernier message: 01/07/2005, 12h34

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo