J'implémente une base de données où plusieurs tables ont des données de chaîne en tant que clés candidates (ex: nom d'utilisateur) et seront indexées en conséquence. Pour ces domaines, je veux:Est-il fou de contourner les problèmes de sensibilité de la base de données en stockant le cas de la chaîne d'origine et en minuscules?
Insensibilité à la casse quand quelqu'un interroge la table sur les touches
Le cas initialement écrit à préserver une certaine façon afin que l'application puisse présenter les données à l'utilisateur avec l'original cas utilisé
Je veux aussi le schéma de base de données soit comme base de données indépendante que possible, car le code d'application est (ou ne devrait pas être) pas asservies à un SGBDR particulier.
Il convient également de noter que la grande majorité des requêtes effectuées sur la base de données sera effectuée par le code de l'application, et non via l'accès direct à la table par le client. En mettant en œuvre ceci, je rencontre beaucoup de problèmes ennuyeux. La première est que tous les SGBDR n'implémentent pas COLLATE (où la sensibilité des cas semble être ajustable au niveau du schéma) de la même manière. Un autre problème est que les options de classement et de sensibilité à la casse peuvent être définies à plusieurs niveaux (serveur, base de données, table (?), Colonne) et je ne peux pas garantir à l'application quel paramètre elle obtiendra. Encore un autre problème est que COLLATE lui-même peut devenir poilu parce qu'il y a beaucoup plus de choses que la simple sensibilité à la casse (par exemple: les options Unicode).
Pour éviter tous ces maux de tête, ce que je considère est d'esquiver le problème en stockant deux colonnes pour une donnée. Une colonne avec le cas d'origine, une autre est passée en minuscules par la couche d'application.
par exemple: Deux des champs de la table
user_name = "fredflintstone" (a unique index on this one) orig_name = "FredFlintstone" (just data... no constraints)
Les avantages et les inconvénients de ce que je vois sont:
Plus:
Aucune ambiguïté - le code de l'application gérera les conversions de cas et je n'aurai jamais à m'inquiéter de l'échec «mystérieux» des tests unitaires lorsque les SGBDR/paramètres sous-jacents changent.
recherches sur l'indice seront propres et ne jamais être ralenti par des caractéristiques de classement ou les appels à lower() ou quoi que ce soit (en supposant des choses ralentir l'indice, ce qui semble logique)
Moins :
espace de stockage supplémentaire requis pour les données-up doublé
Il semble un peu brutal
Je sais que cela fonctionnera, mais en même temps ça sent mauvais.
Est-ce que c'est fou/inutile de le faire?Y a-t-il quelque chose que je ne connais pas qui rend la question de la sensibilité à la casse moins compliquée qu'elle ne me semble en ce moment?
Vous souhaitez dupliquer les données? Bad ... –
Préférer 'UPPER' sur' LOWER', car certains caractères ne peuvent pas aller-retour dans certaines locales en faisant 'LOWER' http://msdn.microsoft.com/fr-fr/library/bb386042.aspx – bdukes
@bdukes - wow ... thx. Je ne le savais pas. – Russ