Des avantages sensibles à la casse de la base de données?
nous venons de "migrer" une base de données SQL Server 2005 de DEVEL en TEST. D'une manière ou d'une autre, pendant le processus de migration, la base de données a été changée de cas insensible à sensible - donc la plupart des requêtes SQL se sont cassées de manière spectaculaire.
Ce que je voudrais savoir, est - il des avantages évidents pour avoir un casse schéma?
NOTE: par ceci j'entends les noms de table, les noms de colonne, les noms de proc stockés etc. Je ne fais pas référence aux données réelles étant stockées dans les tables.
lors de la première inspection, Je ne trouve pas de raison valable qui offre des avantages par rapport à l'insensibilité à la casse.
8 réponses
je viens de découvrir pourquoi on le rend sensible à la casse. Il s'agit de s'assurer que lorsque nous le déployons sur le site client, notre base de données fonctionne indépendamment du fait que le serveur SQL du client soit configuré en fonction de la casse ou non.
C'est une réponse à laquelle je ne m'attendais pas.
Je ne vois vraiment pas pourquoi les identificateurs SQL devraient être sensibles à la casse. Je peux penser à un mauvais un, C'est celui MySQL donne pour pourquoi leurs noms de table sont sensibles à la casse. Chaque table est un fichier sur disque, votre système de fichiers est sensible à la casse et les devs MySQL ont oublié table_file = lc(table_name) . C'est très amusant quand vous déplacez un schéma MySQL vers un système de fichiers insensible à la casse.
je peux penser à une grande raison pour laquelle ils ne devraient pas être Cas sensible.
un auteur de schéma va être intelligent et décider que this_table signifie évidemment quelque chose de différent de This_Table et faire ces deux tableaux (ou colonnes). Vous pourriez aussi bien écrire " insérer des bogues ici " à ce point dans le schéma.
aussi, l'insensibilité cas-insensibilité vous permet d'être plus expressif dans votre SQL pour mettre l'accent sur les tables et les colonnes vs les commandes sans être tenu à ce que l'auteur du schéma a décidé de faire.
SELECT this, that FROM Table;
toutes les sections D'Unicode n'ont pas une correspondance bijective entre les caractères majuscules et minuscules-ou même deux séries de cases.
dans ces régions," l'insensibilité au cas " est un peu dénuée de sens, et probablement trompeuse.
c'est à peu près tout ce que je peux penser pour le moment; dans le set ASCII, à moins que vous ne vouliez que Foo et foo soient différents, Je ne vois pas l'intérêt.
la plupart des langues sont sensibles à la casse, tout comme la plupart des algorithmes de comparaison, la plupart des systèmes de fichiers, etc. L'insensibilité de cas est pour les utilisateurs paresseux. Bien qu'il ait tendance à rendre les choses plus faciles à taper, et conduit à de nombreuses variantes des mêmes noms ne différant que par cas.
personnellement, entre (MyTable, mytable, myTable, MYTABLE, MYTable, MYTable), je voudrais s'il vous plaît j'aimerais voir un version universelle.
j'aime la sensibilité à la casse, surtout parce que c'est ce à quoi je suis habitué de la programmation en Perl (et la plupart des autres langues aussi). J'aime utiliser StudlyCaps pour les noms de table et tous les minuscules avec des underscores pour les colonnes.
bien sûr, de nombreuses bases de données vous permettent de citer des noms pour faire respecter le boîtier, comme le fait Postgres. Cela semble être une approche raisonnable.
L'insensibilité de cas est une aubaine lorsque vous avez des développeurs qui ne respectent pas toutes sortes de conventions lors de L'écriture SQL ou proviennent de langages de développement où l'insensibilité de cas est la norme telle que VB.
de façon générale, je trouve qu'il est plus facile de traiter avec des bases de données où il n'y a aucune possibilité que L'ID, l'id et L'Id soient des champs distincts.
mis à part une préférence personnelle pour la torture, je vous recommande fortement de rester avec le cas insensibilité.
la seule base de données sur laquelle j'ai travaillé et qui a été créée pour la sensibilité aux cas était Great Plains. J'ai trouvé douloureux de devoir me souvenir de chaque image de leurs schémas. Je n'ai pas eu le privilège de travailler avec des versions plus récentes.
sauf s'il a changé et si ma mémoire est bonne, la nature de la sensibilité de cas dont vous parlez est déterminée au moment de l'installation et est appliquée à toutes les bases de données. C'était le cas avec le serveur SQL installion qui dirigeait la base de données Great Plains j'ai mentionné que toutes les bases de données sur cette installation étaient sensibles à la casse.
Je ne supporte pour Sybase avantage serveur de base de données et il utilise un format de fichier plat permettant DBF ainsi que notre propre format propriétaire ADT. Le cas où je vois que la sensibilité au cas est un problème est lors de l'utilisation de notre version Linux du serveur. Linux est un OS sensible à la casse donc nous avons une option dans notre db pour réduire tous les appels. Cela nécessite que les fichiers de table soient en minuscules.