Est-ce une bonne pratique de réduire les espaces (avant et arrière) lors de la sélection/insertion/mise à jour des données de champ de la table?

En supposant que les espaces ne sont pas importants dans les données d'un champ, est-ce une bonne habitude de rogner les espaces lors de l'insertion, de la mise à jour ou de la sélection des données de la table? J'imagine que différentes bases de données implémente la gestion des espaces différemment, donc pour éviter ce mal de tête, je pense que je devrais interdire les espaces de début et de fin dans les données de terrain.Est-ce une bonne pratique de réduire les espaces (avant et arrière) lors de la sélection/insertion/mise à jour des données de champ de la table?

Qu'en pensez-vous?

Source

2009-07-18 Liao

Puisque vous avez mentionné la conception d'un cadre de sécurité; bon appel pour éviter les espaces à la fin des noms d'utilisateur. C'est une technique que les gens pourraient utiliser pour faire semblant d'être quelqu'un d'autre. Par exemple, créez un nom "Liao". L'authentification voit cela comme différent de "Liao", mais lorsque les noms sont affichés dans un forum de discussion, les autres utilisateurs seraient incapables de les différencier. C'est peut-être la plus simple des techniques de spoofing; Vous voudrez peut-être rechercher une bibliothèque pour vous aider avec certaines des plus délicates (par exemple, remplacer L minuscule par 1, ou dans certaines polices où RN minuscule ressemble à m). –

Merci pour les conseils sur le remplacement de personnage. – Liao

Je pense que c'est une bonne pratique. Il y a peu de choses qui écrasent l'âme que de passer une heure, une journée ou n'importe quelle quantité de temps, à courir après un bug qui a finalement été causé par un utilisateur qui tapait un espace supplémentaire. Cet espace supplémentaire peut entraîner des erreurs subtiles ou générer une exception quelque part dans votre programme, et à moins que vous ayez placé des crochets autour de chaque instruction d'impression dans vos journaux et messages d'erreur, vous ne réalisez peut-être pas que c'est là. Même si vous divisez religieusement les espaces avant d'utiliser les données que vous avez extraites de la base de données, favorisez les utilisateurs futurs de vos données et réglez-les avant de les mettre en place.

Source

2009-07-18 00:38:18

Existe-t-il un moyen "garanti" de rogner les espaces de la base de données - de sorte que même si quelqu'un exécute une insertion depuis l'extérieur de mon "code", Par exemple, en exécutant une insertion SQL directe dans l'IDE de la base de données, la base de données peut couper les espaces. Un déclencheur est peut-être possible? – Liao

Eh, parfois les espaces sont importants. – binki

Pour les données typiques, cela ne vaut pas la surcharge. Y a-t-il une raison pour laquelle vous pensez que vous allez avoir beaucoup de lignes blanches supplémentaires? Si vous êtes alors, il pourrait être une bonne idée de réduire pour réduire la taille de DB, mais sinon, non.

Source

2009-07-18 00:32:26

Une raison que je veux couper: Lors de la création d'un compte d'utilisateur (et d'autres "objets"), je ne veux pas qu'un utilisateur saisisse indaverdently dans un espace de fin, et puis ne pas pouvoir se connecter. En plus d'être un "ennui" (si vous pouvez l'appeler ainsi), cela génèrerait des appels inutiles au support client. Je veux appliquer cette "théorie" à tous les "objets" qui ont un "nom" (virtuall tous les objets ont un nom) dans un logiciel que je développe. – Liao

Correction à commenter: l'utilisateur taperait "john" mais en créant le compte d'utilisateur, il avait accidentellement tapé "john". Bien sûr, je pourrais avertir au moment de la création du compte d'utilisateur, mais c'est quelque chose de facile à oublier pour John puisque l'espace n'est pas un caractère "visible". – Liao

Vous avez indiqué dans votre première phrase "En supposant que les espaces ne sont pas importants dans les données d'un champ ...". Si le champ est quelque chose qui va être utilisé pour l'authentification de l'utilisateur, alors clairement les espaces sont importants dans les champs de données. Votre commentaire suggère un scénario entièrement différent de celui de votre question. En général, les champs de nom d'utilisateur suivent généralement des règles de validation qui vont bien au-delà du simple découpage. –

Si les espaces de début et de fin ne sont pas importants, je les couperais avant de les insérer ou de les mettre à jour. Il ne devrait alors y avoir aucun espace inutile sur un select.

Ceci apporte quelques avantages. Moins d'espace requis dans une ligne signifie que potentiellement plus de lignes peuvent exister dans une page de données, ce qui conduit à une récupération plus rapide des données (moins à récupérer). De plus, vous ne coupez pas constamment les données sur les SELECT. (Utilise le principe DRY [ne vous répétez pas] ici)

Source

2009-07-18 00:34:31

Je dirais que c'est une bonne pratique dans la plupart des scénarios. Si vous pouvez affirmer avec certitude que les données ne valent rien et que le coût de leur suppression est minime, supprimez-le.

Source

2009-07-18 00:35:56

Je les couperais (sauf si vous utilisez réellement les données d'espaces) , simplement parce que c'est facile à faire, et les espaces sont particulièrement difficiles à repérer s'ils causent des problèmes dans votre code.

Source

2009-07-18 00:39:24

Les espaces de fin sont particulièrement problématiques, notamment en ce qui concerne le comportement ANSI_NULLS.

Par exemple, colname = « 1 » peut retourner true où colname comme « 1 » renvoie false

Ainsi, étant donné les espaces de fin dans les colonnes varchar sont ambiguës, troncature est très probablement préférable, en particulier parce qu'il n'y a pas de véritable informations dans ces données et il crée une ambiguïté dans le comportement de SQL Server.

Par exemple, regardez la discussion à cette question:

Why would SqlServer select statement select rows which match and rows which match and have trailing spaces

Source

2009-07-18 00:43:12

Est-ce une bonne pratique de réduire les espaces (avant et arrière) lors de la sélection/insertion/mise à jour des données de champ de la table?

Répondre

Questions connexes