Conception de données - plusieurs voyages courts vs un grand voyage

Question

Réservé: Est-il préférable d'avoir le champ calculé retourné avec le reste des résultats ou est-il préférable de le calculer plus tard quand vous en avez besoin?

Exemple: j'ai un GridView qui affiche les résultats de recherche qui a de nombreux domaines tels que:

• ID d'application
• Nom
• Type de compte
• Numéro de compte

etc.

Le champ de numéro de compte n'est pas toujours toujours la même chose. Pour les comptes de type A, ils ont huit chiffres et pour les comptes de type B ils sont douze. Après la recherche, si elles sélectionnent un enregistrement et choisissent de continuer l'application, je dois vérifier le numéro de compte numérique eigit pour toutes les restrictions d'accès. Tous les comptes de type A et B ont un numéro de compte eigit associé, c'est juste que le type B sont les seuls à avoir le numéro à douze chiffres. Alors devrais-je ajouter un champ caché redondant comme "Common Account Number" aux résultats de la recherche et juste le cacher, rendant ainsi la recherche fortement utilisée prendre un peu plus de temps et faire que la grille des résultats occupe plus d'espace dans l'état d'affichage?

Ou

doit appeler la base de données I quand ils essaient de poursuivre l'application et de traduire l'ID d'application dans le numéro de chiffres eigit pour que je puisse l'utiliser pour faire mon accès chèque de restriction? Cela nécessitera un appel supplémentaire à la base de données, mais la traduction devrait être rapide car les deux champs sont dans la même table et l'ID de l'application est une clé primaire. Le bouton continuer l'application sera moins utilisé car il existe de nombreuses autres options de commande. Les gens acceptent aussi plus d'attendre que quelque chose soit traité plutôt que d'attendre les résultats de la recherche.

Answer 1

Vous devez toujours prendre votre décision en fonction de mesures réelles. J'aime votre principe de rendre la fonction la plus souvent utilisée aussi vite que possible.

Mais peut-être y a-t-il un moyen de retourner immédiatement le bon jeu de résultats - par exemple, avez besoin de les nombres à 8 chiffres dans cet affichage, ou pourriez-vous retourner immédiatement les numéros à 12 chiffres pour le type B comptes? Si oui, vous pourriez peut-être définir une vue ou ajouter une colonne calculée immédiatement dans votre modèle de données. Existe-t-il un autre moyen de sauvegarder l'état, afin d'éviter les champs cachés? Au-delà, c'est vous qui pouvez mesurer cela et qui a des chiffres. Si l'action "continuer" est beaucoup plus rare que la recherche, et si cela ne prend pas longtemps, eh bien, bien sûr, ajoutez un autre roundtrip de base de données.Si toutefois vous êtes en mesure d'obtenir la bonne recherche en une étape sans ajouter de latence mesurable, allez-y.

Answer 2

L'ajout d'une colonne cachée supplémentaire ne pose aucun problème, surtout si vous avez une application interne de l'entreprise.

Cependant, ne pourriez-vous pas également effectuer la vérification de restriction d'accès dans une procédure stockée? En d'autres termes, la procédure stockée gère l'identifiant de l'application pour une conversion à huit chiffres sans un aller-retour supplémentaire. Ensuite, à partir de la procédure stockée, vous pouvez renvoyer l'erreur appropriée ou l'ensemble de résultats approprié.