2011-09-08 3 views
1

Nous avons une seule instance MySQL fonctionnant dans notre petit bureau. Nous avons 3 applications différentes qui utilisent toutes la db comme leur backing store. Un schéma unique a toutes les tables pour les trois applications. Toutes les applications utilisent des tables communes (par exemple, tbl_users, tbl_facilities, etc.). J'utilise un préfixe d'application pour les objets de schéma pour les séparer visuellement des autres applications objet, par exemple:Meilleure pratique pour le partage de tables entre applications

  • foo_tbl_settings
  • foo_tbl_orders
  • foo_vw_recent_orders
  • doof_tbl_settings
  • doff_vw_parts

Je n'ai jamais été satisfait de ça, j'ai toujours pensé que je devais utiliser un sc séparé les hémas; un pour chaque application logique puis un schéma partagé pour les objets partagés (table utilisateur, etc.)

Partager des tables communes est très important et je ne veux pas l'abandonner.

J'ai fait quelques recherches sur ce sujet mais je n'ai rien trouvé qui m'ait vraiment expliqué si c'était une bonne pratique ou non. J'espérais que certains d'entre vous pourraient me conseiller sur les meilleures pratiques pour une situation comme la mienne.

+1

'foo_tbl_settings' se traduit si naturellement par' foo.tbl_settings' ... –

+0

Je suis d'accord, mais que suggérez-vous? Que j'utilise des schémas séparés? –

+0

L'utilisation de ces préfixes suggère qu'une séparation propre existe mais je n'ai pas posté de réponse parce que je ne voulais pas élaborer sur les détails :) –

Répondre

0

Pour être honnête, à moins qu'il y ait une raison impérieuse de partager un DB, ne pourriez-vous pas avoir un seul DB par application? Vous avez dit qu'ils «partagent» des tables, mais vous avez ensuite décrit des noms de tables avec des noms différents, suggérant que même s'ils partagent la même structure, ils ne partagent pas réellement les données. À moins que j'interprète mal les choses, je suggère d'avoir un DB par application. Cela vous permettrait également de déplacer la base de données et l'application vers un nouvel emplacement sans avoir à la découpler des autres applications sur le serveur.

+0

Je n'ai peut-être pas été clair: Les applications partagent les mêmes données que dans certaines tables partagées. Donc, nous avons des tables qui sont similaires, c'est que nous avons des tables qui ont des données partagées (par exemple les données de compte utilisateur) –

2

En fait, le partage de tables n'est pas un très bon comportement.

Mais si vous en avez vraiment besoin, vous pouvez créer un schéma différent pour chaque application et créer un schéma commun shared_schema par exemple.

Le schéma commun peut avoir les tables partagées. Puis, dans chaque schéma d'application, vous pouvez créer mysql views pour chaque table que vous souhaitez connecter à partir du schéma partagé. Vous pouvez nommer chaque vue par le nom dont vous avez besoin dans ce schéma. Vous pouvez maintenant décrire des tableaux avec des noms différents.

+1

Merci pour l'info - "partager des tables n'est pas un très bon comportement" - pouvez-vous élaborer un peu ? Je ne suis pas en désaccord, mais j'aimerais savoir quelles sont les principales raisons pour lesquelles c'est une mauvaise idée. –

+1

Cela peut conduire à un état incohérent par exemple: si vous êtes un développeur web ruby ​​sur rails par exemple, il peut y avoir des callbacks exécutés depuis votre serveur après avoir supprimé un enregistrement pour nettoyer certaines données ou faire une logique métier. Si un enregistrement est supprimé d'une autre application, les autres applications ne seront pas notifiées car elles sont gérées à partir de votre code ruby. \ –

+0

Je comprends votre exemple, mais il ne s'applique pas aux tables que nous allons partager. Nous voulons vraiment partager TRÈS quelques tables, en fait les seules que je peux penser à ce moment sont les tables _user, _user_roles et _roles. Les applications clientes ne suppriment pas les enregistrements dans ces tables et nous n'avons pas d'installation de déclencheurs ou quoi que ce soit qui provoquerait des modifications en cascade. Y a-t-il d'autres raisons (performance, facilité d'administration, etc.) qui rendent le partage de tables à travers les schémas une mauvaise idée? –

Questions connexes