Découplage de la base de données

Question

Je travaille sur un projet Web .NET avec un back-end SQL Server. Une partie centrale de la base de données contient des données de stock. Ces données sont chargées quotidiennement par une application de chargement.

Ces données doivent rester en lecture seule sur le site Web. Je veux dire par là que je ne veux pas qu'un développeur Web modifie les tables qui sont spécifiques aux données boursières et que je ne veux pas qu'elles écrivent des données sur ces tables, car elles seront remplacées par la mise à jour quotidienne.

De toute évidence, il y aura beaucoup de tables qui seront exigées par le site Web telles que l'authentification, l'admin, etc. et dans certains cas ils devront permettre à l'utilisateur de manipuler les données boursières pour faire des choses comme le GOOG doit afficher le nom de stock de 'UsersGoogleStock Inc.' au lieu du nom chargé quotidien enregistré de «Google Inc.».

Ma question est, devrais-je avoir deux bases de données distinctes? Un pour mes données de stock en lecture seule et le second pour les spécificités du site?

Answer 1

Dois-je avoir deux bases de données distinctes?

Jamais. Dites simplement aux développeurs Web ce qu'ils doivent mettre à jour et ce qu'ils ne peuvent pas mettre à jour. Ne compliquez pas un simple problème social avec une complexité technique inutile. Parlez-leur. Explique les règles. C'est plus facile que toutes les autres alternatives et plus efficace à long terme.

Answer 2

Non, vous devriez avoir une base de données. L'authentification (nom d'utilisateur/mot de passe généralement) utilisée par le site Web devrait simplement avoir une sécurité appropriée pour contrôler ce qu'il peut lire et écrire.

Answer 3

Vous pouvez accorder ou refuser les privilèges nécessaires à INSERT, UPDATE ou DELETE sur une base table par table, de sorte que vous n'avez pas besoin d'une base de données distincte. Vous pouvez créer plusieurs schémas dans la même base de données pour indiquer à tous les programmeurs ce qu'ils peuvent mettre à jour et ce qu'ils ne peuvent pas faire.

Voir la documentation GRANT ou REVOKE pour la base de données de votre choix.

Answer 4

Les trois réponses données jusqu'ici ont toutes été contre.

Pour ajouter un point à la discussion, il existe un modest performance benefit pour définir une base de données en lecture seule en raison du temps de verrouillage réduit.

Answer 5

Je le mettrais dans une base de données séparée car vous ne souhaiterez probablement que récupérer simplement des tables qui ne sont peuplées que d'une source externe et n'auraient pas besoin d'être récupérées à partir des journaux de transactions. Il est souvent judicieux de séparer les tables qui n'ont besoin que d'une restauration simple de celles qui nécessitent des détails sur le journal des transactions pour la récupération des données. Cela accélérera l'importation et rendra la base de données qui a besoin d'une restauration complète plus rapide, car elle ne sera pas ralentie par l'importation.

Si les deux nécessitent le même mode de récupération, ils peuvent être dans une base de données unique et vous pouvez définir les tables en question afin que les développeurs n'aient pas de droits sur ces bases de données. Bien sûr, vos développeurs ne devraient pas avoir le droit de modifier quoi que ce soit dans la production de toute façon. Seul un dba ou un responsable de la configuration ou un manager devrait promouvoir les changements de production.