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

Java Discussion :

HSQL ResultSet stockage VM


Sujet :

Java

  1. #1
    Membre à l'essai
    Inscrit en
    Novembre 2010
    Messages
    24
    Détails du profil
    Informations forums :
    Inscription : Novembre 2010
    Messages : 24
    Points : 10
    Points
    10
    Par défaut HSQL ResultSet stockage VM
    bonjour ,

    si parmi vous messieurs et dame y'on a qui a déja utilisé HSQL ...


    quand on lance l'application HSQL stock les enregistrements de la base comme des objets Raw , et mets tous dans une Result Set , est ce que quelqu'un parmi vous saurai me dire comment accéder directement a ce ResultSet sans avoir a en créer un nouveau et faire un select ?

    merci

  2. #2
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2007
    Messages : 25 481
    Points : 48 806
    Points
    48 806
    Par défaut
    d'ou vous tenez qu'il stocke ca dans des implémentations de ResultSet? HSQL stocke ca dans un fichier au format qui lui est propre et fait lui même les recherche dans le fichier, pourquoi vouloir éviter le select?

  3. #3
    Membre à l'essai
    Inscrit en
    Novembre 2010
    Messages
    24
    Détails du profil
    Informations forums :
    Inscription : Novembre 2010
    Messages : 24
    Points : 10
    Points
    10
    Par défaut
    déja merci pour votre réponse ,

    je voulais éviter le select car , sa me coute chèr en mémoire , il retourne 2 millions d resultats et pour chaque enregistrement je cree un objet (pour sa je pensais a faire un pattern flywheight , mais chaque objet et unique pas caractéristiques commun ),c'est bizare mais il me semblait que HSQL au démarrage chargeait la base en mémoire et crée un Result Set ,,, ,,,
    je vais revoir la doc .
    en tous cas la j'atteins vite le OutOfMemory , vous aurez pas une suggestion ?

  4. #4
    Membre averti
    Homme Profil pro
    Développeur Java
    Inscrit en
    Mai 2007
    Messages
    132
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 42
    Localisation : France, Paris (Île de France)

    Informations professionnelles :
    Activité : Développeur Java
    Secteur : High Tech - Multimédia et Internet

    Informations forums :
    Inscription : Mai 2007
    Messages : 132
    Points : 419
    Points
    419
    Par défaut
    il retourne 2 millions d resultats et pour chaque enregistrement je cree un objet
    Déjà avez-vous réellement besoin de faire un SELECT sur 2 millions de lignes ? D'un point de vue conception ça me parait douteux comme approche sans plus de précisions de votre part

  5. #5
    Membre à l'essai
    Inscrit en
    Novembre 2010
    Messages
    24
    Détails du profil
    Informations forums :
    Inscription : Novembre 2010
    Messages : 24
    Points : 10
    Points
    10
    Par défaut
    Citation Envoyé par nu_tango Voir le message
    Déjà avez-vous réellement besoin de faire un SELECT sur 2 millions de lignes ? D'un point de vue conception ça me parait douteux comme approche sans plus de précisions de votre part
    oui , car il faut que je récupère l'ensemble des enregistrement et j'en des objets que j'utilise fréquemment après , sinon je vais faire 2 millions de selects

  6. #6
    Expert éminent sénior
    Avatar de tchize_
    Homme Profil pro
    Ingénieur développement logiciels
    Inscrit en
    Avril 2007
    Messages
    25 481
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 44
    Localisation : Belgique

    Informations professionnelles :
    Activité : Ingénieur développement logiciels
    Secteur : High Tech - Éditeur de logiciels

    Informations forums :
    Inscription : Avril 2007
    Messages : 25 481
    Points : 48 806
    Points
    48 806
    Par défaut
    peux importe comment vous lisez votre base de donnée, ca n'a pas de sens de mettre deux millions de rows en mémoir. Faite un calcul simple et vous verrez que quoi que vous fassiez, ça ne peux pas tenir.

    En supposant très peux de données par row, disons 1 identifiant (4 octets) + un nom (10 caractère unicodes + tableau char[] + instance String =+-40 octets) + une date (8 octets), ca vous donne 100M de données pour un truc très basique.

    Si vous avez une opértion à faire su l'ensemble de vos entrées, traitez les une par une, vous n'avez pas pour autant besoin de deux millions de select pour ça.


    Et n'oubliez pas que beaucoup de calculs et d'opérations de masse peuvent déjà être effectués directement en SQL, ce qui permettra de profiter des indexes et autres optimisations de la base de donnée.

Discussions similaires

  1. Stockage et réutilisation d'un ResultSet
    Par Cedrati dans le forum JDBC
    Réponses: 7
    Dernier message: 24/06/2014, 15h59
  2. Stockage de paramètres unitaires
    Par ovh dans le forum Décisions SGBD
    Réponses: 5
    Dernier message: 07/10/2003, 09h07
  3. [Kylix] stockage d'un tableau d'octets dans interbase
    Par georges1001 dans le forum EDI
    Réponses: 1
    Dernier message: 16/09/2003, 14h14
  4. gain stockage olap
    Par colomban dans le forum Décisions SGBD
    Réponses: 5
    Dernier message: 15/05/2003, 15h24
  5. [Stockage] Image dans un fichier XML
    Par ovh dans le forum XML/XSL et SOAP
    Réponses: 4
    Dernier message: 30/04/2003, 16h21

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