Y at-il une raison programmatique pour ne pas utiliser d'espaces dans les noms d'objet dans MS Access 2013?

Il me semble que la plupart des développeurs MS Access préconisent fortement les noms d'objets qui excluent strictement l'utilisation d'espaces. Je n'ai pas appris cela avant que la base de données que j'ai créée soit bien établie, et j'ai ensuite des espaces dans presque tous les noms d'objets (tables, formulaires, requêtes, listes déroulantes, boutons de commande, etc.). Cela dit, en plus d'avoir à entourer tout [In Brackets] lors de l'écriture du code, je n'ai pas rencontré de problèmes ou de revers liés à leur utilisation. Y at-il une raison programmatique de ne jamais utiliser les espaces qui me manquent?Y at-il une raison programmatique pour ne pas utiliser d'espaces dans les noms d'objet dans MS Access 2013?

Source

2016-06-15 Anonymous

Tant que vous êtes consciencieux quant à l'inclusion des crochets, le cas échéant, je ne peux pas penser à tout dommage causé par les espaces dans les identificateurs d'objet. Mais alors vous avez besoin de crochets. Yuck! :-) – HansUp

Je ne pense pas non plus à un inconvénient fonctionnel, mais je trouve que les crochets rendent le code plus difficile à lire puisque les espaces sautent beaucoup plus clairement, et recherchent une longue requête sql avec des requêtes multi-mots et des noms de champs peut devenir épuisant. Cela force juste une étape supplémentaire lors de l'écriture d'un nouveau code. Si j'ai besoin d'un espace, j'échange généralement avec un trait de soulignement, de sorte que les parenthèses ne sont pas nécessaires, et elles ne sont pas confondues avec les espaces. – MoondogsMaDawg

Merci à vous deux pour la perspective! Christopher, cela a du sens, et j'ai commencé à en faire l'expérience parfois lorsque j'écris des requêtes plus compliquées. –

Y at-il une raison programmatique de ne jamais utiliser les espaces qui me manquent?

Pas vraiment. De nombreux développeurs évitent ces noms (avec les noms reserved words dans Access SQL) principalement pour des raisons de commodité, et ce n'est pas une mauvaise idée de le faire lors de la création d'une nouvelle base de données. Cependant, si votre base de données est déjà créée et déployée, vous pouvez simplement continuer en utilisant [square brackets] pour délimiter les noms d'objets.

(Je pense que les adversaires les plus virulents de « noms avec des espaces » ont développé leur dégoût pour ces noms il y a quelques années quand ils pourraient causer des maux de tête importants si vous est arrivé de mettre fin à l'aide d'un outil qui les a mal géré. Toutefois, la plupart des bogues ont été élaborés depuis, même l'exemple de base de données "Northwind" de Microsoft pour Access utilise des noms de table qui contiennent des espaces.)

Source

2016-06-15 18:43:40

Gord, merci pour votre réponse perspicace! –

Programmatique. Mais les espaces peuvent définitivement causer des problèmes et augmenter le coût de la maintenance. Je l'ai vu comme une sorte de meilleure pratique de ne pas utiliser les espaces dans les noms d'objets de base de données pendant une longue période.

Source

2016-06-16 19:00:19

Pourriez-vous donner un exemple de l'utilisation des espaces qui augmenterait le coût de la maintenance? –

Lorsque vous utilisez simplement des artefacts préfabriqués dans MS Access, il y a quelques problèmes. Mais lorsque vous commencez à explorer le SQL dynamique, ou que d'autres systèmes accèdent à votre DB d'accès et font des choses. Les problèmes ont tendance à surgir autour des objets avec des espaces ou d'autres caractères impairs dans leurs noms. –

Je peux voir comment interagir avec d'autres systèmes moins équipés pour traiter les espaces pourrait entraîner des problèmes. C'est un bon point - merci! –

Y at-il une raison programmatique pour ne pas utiliser d'espaces dans les noms d'objet dans MS Access 2013?

Répondre

Questions connexes