Base de données de responsabilité

Question

Je commence par les bases de données. J'ai joué avec MySQL et Informix, mais je n'ai jamais eu de projet réel.

Quelle est la véritable responsabilité d'une base de données? Devrions-nous ajouter des procédures et des fonctions de stockage à la base de données ou juste le laisser être un référentiel de données sans logique?

Answer 1

Généralement, il est recommandé de ne pas placer de logique métier dans votre base de données. La raison principale est la maintenabilité. Il est toujours possible d'utiliser des procédures stockées, mais l'inclusion de la logique métier dans ces procédures stockées rend votre application plus difficile à déboguer et à mettre à jour. L'intégration de la logique métier dans votre base de données vous permettra également d'utiliser efficacement ce même SGBD et de ne pas laisser la couche de données rester indépendante de votre application. Par exemple, vous pouvez rencontrer des problèmes de performances et d'évolutivité avec une base de données une fois que votre application est active, mais en raison de la logique métier dispersée dans la base de données, la migration vers une base de données plus évolutive prendra du temps. Si la logique métier est conservée dans le code de l'application (par exemple java ou C#) et que la couche de données est extraite à l'aide d'une couche d'abstraction de données et un ORM si le langage le permet, l'échange de bases de données est beaucoup moins problématique.

Nous devrions nous battre pour separation of concerns, et garder la logique métier hors de la base de données permet d'atteindre cet objectif.

edit: Il existe également des problèmes de performances qui peuvent imposer que les procédures stockées soient un bon endroit pour conserver la logique métier. Contenir la logique dans le niveau de données (ie le sproc) réduit dans certains cas les nombreux allers-retours entre la couche d'abstraction de données et la base de données, ce qui peut donner un coup de pouce aux performances. J'ai travaillé sur des systèmes comme celui-ci dans le passé, pour cette raison, mais j'ai toujours trouvé difficile de les maintenir. Le problème étant que vous pouvez regarder à travers les classes et les procédures pour voir la logique métier et y penser et vous ne verrez pas comment un bogue ou un processus particulier peut se produire, alors vous trouverez la procédure stockée et vous verrez l'autre moitié de l'opération de l'entreprise (une vraie douleur quand le sproc est un 1000 lignes!)

Comme avec beaucoup de choses, où vous placez votre logique métier dépend du problème particulier que vous essayez de résoudre.

Answer 2

Nous avons beaucoup de données autour de nous qui peuvent nous être d'une grande utilité. La collecte ordonnée d'informations aide les entreprises à prendre des décisions plus appropriées. Les bases de données sont ordonnées stockage d'informations. Responsabilité: Dans un scénario commun, nous pouvons affirmer qu'il y a beaucoup d'informations autour, la collecte ordonnée d'informations est appelée données, cette information concerne une entité, et la collecte ordonnée de données est une base de données, des informations relatives à un groupe d'entités. La collecte de ces bases de données est un SGBD. La responsabilité de la base de données consiste à organiser l'information.

Les procédures stockées, les fonctions sont plus comme les processus métier dont vous avez besoin pour collecter les données que vous désirez.

premier point de départ,

Début: base de données Sélectionnez dans {postgreSQL, MySQL, SQL Server (édition Express)} et l'installer. En savoir plus sur Codd Rules, Normal forms, Good resource Commencer à apprendre le SQL, écrire des requêtes. Comprendre les bases de la création de schéma. Apprendre l'implémentation du langage procédural dans la base de données. Poser des doutes dans SO.

Answer 3

Quelle est la véritable responsabilité d'une base de données?

Une base de données à la base est un système pour stocker et récupérer des données. Un fichier CSV sur disque + outils appropriés (par exemple Excel) en est un exemple simple. En outre, une base de données peut fournir des fonctionnalités supplémentaires, telles que le contrôle des transactions, l'intégrité des données et la sécurité.

Devrions-nous ajouter des procédures et des fonctions de stockage à la base de données ou simplement le laisser comme référentiel de données sans logique?

Que voulez-vous de la base de données? Si tout ce que vous voulez est un "bit bucket", alors par tous les moyens, stockez-le dans un fichier simple sur le disque et appelez-le "la base de données". Si vous voulez un peu plus, utilisez un produit qui répond à vos besoins. Si vous voulez être en mesure de l'interroger en utilisant un SQL 4GL, utilisez MySQL. Si vous souhaitez contrôler les transactions, la sécurité, les fonctions de requête avancées, etc., utilisez un autre SGBD si nécessaire. Cependant, quel que soit le produit que vous choisissez, tire parti de ce produit. Sinon, vous perdez votre temps et votre argent. Bien sûr, vous n'utiliserez jamais toutes les fonctionnalités (seul un sous-ensemble vous sera utile), mais si vous en utilisez très peu, vous pouvez aussi rétrograder vers un produit plus simple.

Si vous utilisez Oracle, vous pouvez stocker des procédures et des fonctions (mieux encore, des packages complets) directement dans la base de données à côté des données. La vraie question est, qu'est-ce que vous avez besoin d'écrire dans ces procédures et fonctions - la logique métier ou la logique de présentation?

Personnellement, je préfère généralement garder la logique métier proche des données, alors que la logique de présentation est personnalisée pour chaque interface.

Il est possible de créer une couche API sur vos données de sorte que, quelle que soit la manière dont vos applications accèdent à votre base de données, elles auront une vue cohérente et elles le modifieront en utilisant un mécanisme cohérent. En d'autres termes, au lieu d'écrire la logique métier plusieurs fois (une fois pour chaque interface), vous l'écrivez une fois et une seule fois, puis vous la réutilisez partout.

Il y a deux raisons pour lesquelles je l'ai entendu pourquoi la logique métier ne doit pas être stocké dans la base de données:

1. maintenabilité: il est difficile de changer. Je n'ai jamais vraiment compris celui-ci. Est-ce difficile de taper CREATE OR REPLACE PACKAGE? Je suppose que c'est juste le fardeau de devoir apprendre «encore une autre langue».

2. Indépendance de la base de données: ce qui fonctionne dans Oracle ne fonctionnera pas ailleurs. Ceci est un biggie, et better minds than I ont written about celui-ci. Fondamentalement, si vous avez vraiment besoin d'être "agnostique de base de données", vous ne pourrez utiliser aucune des fonctionnalités avancées de la base de données que vous avez achetée, donc vous pouvez aussi utiliser le plus simple/le moins cher que vous pouvez trouver; Dans ce cas, vous n'avez pas besoin de travailler sur toutes les bases de données!