Est-il possible de maintenir une requête de 43 pages? [fermé]

StackOverflow https://stackoverflow.com/questions/800620

  •  03-07-2019
  •  | 
  •  

Question

J'ai toujours pensé qu'un compilateur SQL casserait, mais apparemment, le nesing peut être presque infini. Ce code doit-il être immédiatement supprimé ou existe-t-il une lueur d’espoir que quelque chose comme cela puisse fonctionner?

Cette requête ne m'appartient pas vraiment, je ne peux donc pas la poster ... Cependant, supposons qu'elle soit celui-ci : 

[SELECT /*+ NOPARALLEL bypass_recursive_check */ 
SP_ALIAS_190, 
((CASE SP_ALIAS_191
WHEN 1
THEN 'PROVIDER::ALL_PROV::'
WHEN 0]
Était-ce utile?

La solution

Si la requête est générée par un outil (ou par un code), sa maintenance peut être relativement simple (dans le sens où le code de génération de la requête peut en fait être bien écrit et maintenable)

Autres conseils

Il est clair que vous n'avez jamais vu le code SQL sortant du DAL Sharepoint.

J'ai rencontré récemment un problème similaire à celui-ci et j'ai pris une décision en tenant compte de quelques points:

  • Combien de temps cela va-t-il prendre pour maintenir ou réécrire
  • À quel point est-ce critique? Il peut y avoir beaucoup de logique qui peut être difficile à démêler et la valeur du fait que & "Cela fonctionne &"; dépasse la valeur d'une réécriture immédiate.

Et bien sûr, il y avait la décision politique que la direction devait prendre concernant le risque d'expliquer pourquoi quelque chose qui venait d'être créé devrait être réécrit.

À la fin (pour moi), trouver + remplacer était mon ami.

Refacturez-le à l'aide du WITH . Ajoutez des tas, des tas de commentaires.

Si vous le divisez en morceaux qui peuvent être gérés, vous avez une bien meilleure chance.

Si elle contient beaucoup d’imbrication, je dirais non.

Comme tout code, quelle que soit sa langue, vous ne devriez envisager que de le réécrire car vous pouvez le rendre plus efficace ou plus facile à comprendre.

Sur la base de mon expérience, j’ai été en mesure de réduire le code SQL mal écrit de 4 à 5 fois sa taille et de nombreuses fois ses performances, car l’auteur d’origine n’avait vraiment aucune idée.

Si vous pensez que c'est mauvais, vous devriez voir un exemple de vidéo d'Industrial Logic sur les odeurs de code: Dette technique . Absolument pas généré automatiquement.

Est-il possible de conserver une fonction de 43 pages, par exemple en C #? La réponse est évidente;). Je ne peux tout simplement pas imaginer cela. Si j'étais vous, je le diviserais en parties plus petites.

Deux choses:

  • Est-ce que seules les machines auront besoin de lire ce code SQL?
  • Êtes-vous coincé avec le schéma sous-jacent?

Si vous avez une requête de 43 pages et que vous avez répondu oui aux deux premières questions, bienvenue dans le développement de SharePoint

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top