-1
votes

Charger la table de base de données entière puis filtrer en mémoire ou charger uniquement des entrées filtrées?

Je dois programmer une recherche client à partir de la base de données.

Je sais que les bases de données sont de gérer d'énormes quantités de données. Mais mon "mentor" m'a dit d'interagir avec la DB le moins possible.

est-il préférable de lire toute la table de base de données dans une table interne, puis de filtrer sur la base des paramètres entrés par l'utilisateur: xxx

ou juste faire un Accès direct à la table de base de données? xxx


2 commentaires

La question n'est pas liée à ABAP, c'est une question de ce qui est plus rapide, de la base de données ou de l'application? Peut-être que les réponses à cette question vous aidera.


Franchement, cela dépend de votre base de données (esp. Hana) ci-dessous. Il existe de nombreuses solutions en fonction de votre base de données et de votre quantité de données que vous souhaitez sélectionner.


4 Réponses :


1
votes

Il est vrai que l'accès à la DB est considéré comme une action coûteuse. S'habituer à l'accès à la DB de la bonne manière donnera à votre système une performance un boost de performance.

Généralement, la réduction du nombre d'accès à la DB est un bon point de départ. Cependant, ce n'est pas le seul à considérer dans le " de droite" / forte> "équation"

regardons particulièrement dans votre cas: xxx

pièges:

  1. Le flux de données de DB au serveur d'applications est coûteux comme indiqué. Non seulement la quantité d'accès est un facteur, mais également la quantité de données étant transférée. Si tous les clients sont nécessaires (disons pour un écran d'informations personnelles du client), il y aurait une surcharge majeure pour transférer tous les autres clients inutiles vers le serveur d'applications.
  2. La sélection de la table entière peut être correcte si elle n'est faite qu'une seule fois, disons au début de votre processus. Toutefois, dans de nombreux processus, la DB est modifiée au milieu du processus (par exemple si c'est un écran d'ensemble de tous les clients). Dans ce cas, vous devrez actualiser les données et le faire avec un autre SELECT * pourrait être faux.
  3. DB Access est vraiment coûteux, mais la manipulation interne n'est également pas gratuite. Faire select * donnera un démarreur de n lignes dans lt_customer , lorsque n est le nombre d'enregistrements du client Tableau DB. Il est parfois inévitable de faire des calculs dans n ^ 2 commander ou encore plus. Alors que le n augmente, il en va de même pour le traiter pour le traiter.

    Je suis hors de temps maintenant. Je vais essayer d'étendre plus quand j'ai plus de temps. Bonne chance.

    P.s. Sélectionnez ... endselect. est considéré comme une mauvaise pratique. Vous pouvez en lire à ce sujet, dans l'exemple ici .


0 commentaires

0
votes

Utilisez Sélectionner ... dans Tableau

Lorsque vous obtenez un meilleur mentor 1 Il sera beaucoup plus facile de refroidir votre code à quelque chose de raisonnable.

seulement si it_customer provoque des décharges de mémoire si vous utilisez Sélectionner ... endselect.


1) ou DBA ou CTO, quiconque est responsable de l'actuel, très mauvaise politique


0 commentaires


1
votes
SELECT the, fields, you, really, need
  FROM customer
  INTO TABLE @DATA(customers)
  WHERE some_attribute = @some_value
    OR some_id IN @some_range
  PACKAGE SIZE 1024.

  " some processing

ENDSELECT

0 commentaires