Placement des objets de base de données pour le logiciel complémentaire personnalisé

Question

Quelles sont les recommandations de chacun sur l'emplacement des objets de base de données (tables, procs, vues, etc.) pour un add-on personnalisé dans la base de données d'une autre application?

devraient-ils être maintenus séparés comme ceci:

ErpInventoryAccountingWare.dbo 
CustomIntegratedPortal.dbo 

Ou, pourrait les objets add-ons être placés dans la même base de données. Les objets seraient nommés de manière appropriée et assumeraient les mêmes autorisations. Garder les objets sur le même serveur mais dans différentes bases de données me semble une solution propre, tant que vous êtes prêt à modifier vos scripts pour prendre en charge le nom des autres bases de données.

J'utilise SQL 2000, SQL 2005.

Answer 1

Si vous les mettez dans une autre base de données, une sauvegarde de base de données simplement de l'application les manquer, il présente un Gotcha pour la maintenance opérationnelle de l'application. Sur SQL Server 2005, la création de votre propre schéma aidera à prévenir la pollution de l'espace de noms si le développeur de l'application décide d'ajouter une table dont le nom est en conflit avec l'un des vôtres.

Sur SQL Server 2000, la création de tables appartenant à un utilisateur d'application spécifique vous apportera certains des avantages d'un schéma, tout en leur permettant de coexister dans la même base de données.

Answer 2

Dépend du fournisseur; certains fournisseurs ne jouent pas bien avec des choses étrangères dans leur base de données; J'ai vu le code du fournisseur qui supprime tout ce qui n'est pas le leur. Les choses peuvent disparaître lors des mises à niveau aussi.

Mais si c'est une application assez stable et bien tenue, tout garder ensemble est un avantage dans mon esprit. Juste préfixer tout, par ex. ABC_MyProc, ABC_MyTable, afin qu'ils puissent être identifiés.