Préfixer le nom de la table était une méthode populaire auparavant. La tendance actuelle est d’abandonner l’ajout de préfixes car les avantages que cela apporte sont bien moindres que les problèmes qu’ils apportent. Dans de nombreux cas, la conception de bases de données croisées est plus flexible et pratique que la conception de préfixes de table, et la confusion et les problèmes causés par la conception de préfixes (en particulier dans des situations mixtes) constituent le plus gros problème pour de nombreux novices. Alors s'il vous plaît, soyez prudent.

Facile à gérer

Ce sera utile si vous mettez plusieurs projets dans la même base de données

Table utilisateur du projet 1 - p1_user
Table utilisateur du projet 2 - p2_user

Vous comprendrez une fois que vous aurez dit cela

C'est juste une habitude de conception. Il est généralement créé pour distinguer différentes tables système dans la même bibliothèque.

Comme le montre l'image, le tableau sans préfixe est le tableau du système de gestion d'arrière-plan. La table avec le préfixe wms est la table du système wms

Pour être honnête, il est plus approprié de diviser différents types de tables en fonction de la base de données. Le problème des préfixes est vraiment fastidieux

Le

préfixe est très utile, par exemple, si je veux tout savoir sur la user的表，直接show tables like '%user%'就可以了，用mysqlligne de commande

En particulier pour les projets comportant de nombreux plug-ins ou modules, l'ajout de ces préfixes est également utile pour le traitement par lots des tables de base de données et d'autres opérations

Utilisé pour distinguer tous les projets en utilisant des tables de données de différents projets dans la même base de données

Le préfixe du nom de la table n'est qu'une convention de dénomination et n'a aucun impact sur l'implémentation de la fonction.

Dans les systèmes plus complexes, vous pouvez comprendre grossièrement le module et la classification de la table grâce au préfixe du nom de la table. Cela semble plus pratique lors du développement, de l'exploitation et de la maintenance quotidiens, et les nouveaux arrivants ont également des règles à suivre pour comprendre la structure des données du système.

Personnellement, je suis d'accord avec cette approche. Le coût est très faible, mais c'est pratique pour une exploitation et une maintenance ultérieures. Pourquoi ne pas le faire ?

Lorsque les tables de données se trouvent dans une seule base de données et qu'il existe de nombreuses tables de données, la distinction est très simple

Lorsqu'il y a plus de 100 tables dans un projet, vous comprendrez pourquoi vous devez les utiliser.

Idéalement, user_tabel1 peut être écrit sous la forme user.table1 (pour créer plusieurs bibliothèques)
Le problème est que de nombreux développeurs ne connaissent les bases de données qu'en ajoutant, supprimant, modifiant et vérifiant simplement, y compris de nombreux frameworks (qui ne peuvent se connecter qu'à une seule bibliothèque)

Par exemple, l'instance Scott la plus classique d'Oracle.
scott a une liste de départements et de personnel du département, hr (une autre instance) a une liste de départements. Il existe également une instance de produit qui a une liste de listes de produits. une liste de scott. emp a l'autorisation de sélection mais aucune autorisation de mise à jour

Personnellement, je pense que cette conception améliore la sécurité des données (lorsqu'une instance est attaquée et crackée, toutes les données ne seront pas exposées) et la clarté logique est grandement améliorée, mais elle nécessite également que les développeurs aient plus de compréhension et de maîtrise de la base de données.
Mais ce que nous constatons souvent, c'est que toutes les tables des développeurs sont placées dans une seule bibliothèque. Le contrôle des autorisations n'est contrôlé qu'à partir de la logique métier
.