MS SQL Server
  1. MS SQL Server
  3. Base de données et front-end pour la mise en forme de la sortie
Intereting Posts
SQL CASE dans la requête – comportement impair Comment tronquer une table via un server lié en utilisant un synonyme pour le nom de la table? Le package SSIS se bloque en cours d'exécution Personnaliser le générateur de script Sql-Server Y at-il une raison de vérifier null à l'intérieur de plusieurs en utilisant clausule dans c #? Générer 8 numbers varchar avec 4 alpha et 4 numérique dans SQL Server Comment se connecter à SQL Server via C ++ / CLI Obtenir Min et Max en fonction des valeurs calculées dans une table Comment interroger la database SQL Server 2008 pour le prénom et le nom et l'ordre par pertinence? Déclencheur SQL, vérifiez si une certaine valeur a été input Copier des données entre une table sans colonne d'identité Est-il possible de créer une fonction de table en ligne hors de cette fonction scalaire? SQL Server 2008 JOIN Question Puis-je utiliser T-SQL pour lancer le bloc-notes ou une autre application d'interface user? Le CTE générant "l'identifiant en plusieurs parties ne peut pas être lié"

Base de données et front-end pour la mise en forme de la sortie

J'ai lu que (toutes choses étant égales par ailleurs) PHP est généralement plus rapide que MySQL lors des opérations de manipulation arithmétique et string. Ceci étant le cas, où trace-t-on la ligne entre ce que l'on request à la database de faire et ce qui est fait par le (s) server (s) web? Nous utilisons exclusivement des procédures stockées comme couche d'access aux données. Ma règle non écrite a toujours été de laisser le formatting de sortie (y compris la manipulation de strings et l'arithmétique) au server Web. Donc, nos requêtes returnnent:

  • dates non formatées
  • valeurs nulles
  • pas de valeurs calculées (c.-à-d. renvoyer des valeurs pour les colonnes "foo" et "bar" et laisser le server web calculer foo * bar s'il doit afficher la valeur foobar)
  • pas de champs avec une sous-string réduite (sauf si le champ raccourci est tellement plus court que nous voulons le faire au niveau de la database pour réduire la taille de l'set de résultats)
  • deux colonnes séparées pour laisser le cas de la sortie au besoin

Ce qui m'intéresse, c'est de savoir si cette approche est généralement appropriée ou si d'autres personnes connaissent des considérations convaincantes de performance / maintenabilité qui justifient de pousser ces activités dans la database.

Note: Je suis intentionnellement tagging cette question pour être dbms-agnostique, car je crois que c'est une considération architecturale qui entre en jeu indépendamment de ses dbms spécifiques.

Je voudrais tracer la ligne sur la façon dont certaines couches pourraient tourner en place pour d'autres implémentations. Il est très probable que vous n'utiliserez jamais un SGBDR différent ou que vous ayez une version mobile de votre site, mais vous ne savez jamais.

Plus un sharepoint données est orthogonal, plus il devrait être libéré de la database sous cette forme. Si sur chaque version théorique de votre site vos valeurs A et B sont rendues A * B, cela devrait être returnné par votre database comme A * B et jamais coté client.

Disons que vous avez quelque chose de lourd comme une date. Parfois vous avez des dates courtes, des dates longues, des dates anglaises … Un formulaire pur devrait être returnné à partir de la database et ensuite cela devrait être formaté en PHP.

Donc, le point d'orthogonalité fonctionne également à l'envers. Plus un sharepoint données est dynamic dans sa représentation / affichage, plus il doit être traité côté client. Si une string A est toujours considérée comme une sous-string des six premiers caractères, elle doit être renvoyée de la database en tant que sous-string. Si la longueur de la sous-string dépend de certains facteurs, par exemple six pour mobile et dix pour votre application Web, renvoyez la plus grande string de la database et formatez-la au moment de l'exécution en utilisant PHP.

Habituellement, la mise en forme des données est mieux effectuée côté client, en particulier la mise en forme spécifique à la culture.

Le pivotement dynamic (c'est-à-dire les colonnes variables) est également un exemple de ce qui est mieux fait du côté client

Quand il s'agit de manipulation de strings et de arrays dynamics, PHP est beaucoup plus puissant que tout RDBMS je suis au courant.

Cependant, le formatting des données peut utiliser des données supplémentaires qui sont également conservées dans la database. Comme, les informations de coloration pour chaque ligne peuvent être stockées dans un tableau supplémentaire.

Vous devriez alors correspondre la couleur à chaque ligne du côté de la database, mais envelopper dans les balises du côté PHP .

La règle générale est la suivante: récupérez tout ce dont vous avez besoin pour le formatting en utilisant le less possible d'aller-return de database, puis effectuez le formatting lui-même du côté client.

Je crois que le fait de renvoyer datatables à peu près telles quelles de la database et de les laisser être formatées sur le front-end à la place. Je ne m'y attarde pas religieusement, mais en général je pense que c'est mieux car il offre une plus grande flexibilité – par exemple 1 sproc peut répondre à différentes exigences pour datatables, chacune pouvant formater datatables individuellement. Sinon, vous vous retrouvez avec plusieurs requêtes renvoyant les mêmes données avec un formatting légèrement différent de celui de la database (du sharepoint vue de SQL Server, réduisant ainsi les avantages de la caching du plan d'exécution).

Laisser le formatting de sortie au server Web