2

Can the single responsibility principle be applied to databases? relational databases I mean.

I'm asking this because a typical database will have several tables and we may find something like that between them:

  • Tables handle ACL and permissions.
  • Tables handle user authentication.
  • Tables relating to cron jobs and scheduled tasks.
  • Tables relating to the domain itself.
  • Tables relating to emails and invitations and so on.
  • Look ups.

Moreover the tables relating to the domain might be divided according to the application module they back up.

In code we usually divide our code base to modules/packages/namespaces, but that concept is absent from relational databases as far as I know.

so what I'm asking should the database be divided somehow to smaller databases? or maybe database (modules?!) Or should we just lump everything together and hope for a good naming convention if any?!

1
  • 1
    I would say, there is nothing inherently wrong with both approaches; it depends on the architecture and other constraints. Sometimes it makes sense to use multiple databases (or schemas) to store more or less unrelated information separately for practical reasons. For example, it might be easier to back-up and restore smaller independent pieces of data than the whole thing. But, again, "it depends".
    – proskor
    Commented Jul 8, 2014 at 11:41

2 Answers 2

Reset to default
2

I think that the SRP translates directly to the principles of orthogonal design and full normalization in relational databases.

If you recollect that SRP states that there there should never be more than one reason for a class to change then the analogy becomes immediately apparent.

However, whether the database should be split into multiple smaller databases is an orthogonal issue, which is more of interest for pracical reasons then logical.

1

The SRP applies to the classes and methods you define. A database is not a user-defined entity, it is a piece of infrastructure that transcends individual requirements and responsibilities (in fact, it is better having to deal with only one database for a system than having to juggle multiple ones).

Therefore, there is no point worrying about the fact that completely different pieces of functionality map to relations (tables) in the same data base. If you want to enforce the SRP, focus on getting each relation to serve a clearly-defined purpose, not the entire DB.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.