Search code examples
djangopython-3.xrdbms

Django project-apps: What's your approach about implementing a real database scheme?

I've read articles and posts about what a project and an app is for Django, and basically end up using the typical example of Pool and Users, however a real program generally use a complex relational database, therefore its design gravitates around this RDB; and the eternal conflict raises once again about: which ones to consider an application and which one to consider components of that application?

Let's take as an example this RDB (courtesy of Visual Paradigm): enter image description here

I could consider the whole set as an application or to consider every entity as an application, the outlook looks gray. The only thing I'm sure is about this:

$ django-admin startproject movie_rental

So I wish to learn from the expertise of all of you: What approach (not necessarily those mentioned before) would you use to create applications based on this RDB for a Django project?

Thanks in advance.

PS1: MORE DETAILS RELATED ABOUT MY REQUEST

When programming something I follow this steps:

  1. Understand the context what you are going to program about,
  2. Identify the main actors and objects in this context,
  3. If needed, make an UML diagram,
  4. Design a solid-relational-database diagram, (solid=constraints, triggers, procedures, etc.)
  5. Create the relational database,
  6. Start coding... suffer and enjoy

When I learn something new I hope they follow these same steps to understand where they want to go with their actions.

When reading articles and posts (and viewing videos), almost all of them omit the steps 1 to 5 (because they choose simple demo apps), and when programming they take the easy route, and don't show other situations or the many supposed features that Django offers (reusability, pluggability, etc).

When doing this request, I wish to know what criteria is used for experienced programmers in Django to determine what applications to create based on this sample RDB diagram.

With the (2) answers obtained so far, "application" for...

  1. brandonris1 is about features/services
  2. Jeff Hui is about implementing entities of a DB
  3. James Bennett is about every action on a object, he likes doing a lot of apps

Conclusion so far: Django application is a personal creed.

My initial request was about creating applications, but as models are mentioned, I have this another question: is with a legacy relational database (as showed in the picture) possible to create a Django project with multiple apps? this is because in every Django demo project showed, every app created has a model with their own tables, giving the impression that tables do not interact with those of other applications.

I hope my request is more clear. Thanks again for your help.

Solution

  • It seems you are trying to decide between building a single monolithic application vs microservices. Both approaches have their pros and cons.

    For example, a single monolithic application is a good solution if you have a small amount of support resources and do not need to be able to develop new features in fast sprints across the different areas of the application (i.e. Film Management Features vs Staff Management Features)

    One major downside to large monolithic applications is that eventually their feature sets grow too large and with each new feature, you have a significant amount of regression testing which will need to be done to ensure there aren't any negative repercussions in other areas of the application.

    Your other option is to go with a microservice strategy. In this case, you would divide these entities amongst a series of smaller services and provide them each methods to integrate/communicate with each other (APIs).

    Example: - Film Service - Customer Service - Staff Service

    The benefits of this approach is it allows you to separate capabilities and features by specific service areas thus reducing risk and regression testing across the application when new features are deployed or there is a catastrophic issue (i.e. DB goes down).

    The downside to this approach is that under true microservice architecture, all resources are separated therefore you need to have unique resources (ie Databases, servers) for each service thus increasing your operating cost.

    Either of these options is a good option but is totally dependent on your support model and expected volumes. Hope this helps.

    ADDITIONAL DETAIL: After reading through your additional details, since this DB already exists and my assumption is that you cannot migrate it, you still have the same choice as to whether or not you follow a monolithic application or a microservices architecture.

    For both approaches, you would need to connect your django webapp the the specific DB you are already using. I can't speak for every connector out there but I know that the MySQL connector allows django to read from the pre-existing db to systematically generate the models.py file for the application. As a part of that connector, there is a model variable which allows you to define whether or not Django is responsible for actually managing the DB tables themselves.

    The only thing this changes from an architecture perspective is how many times do you want to code this connection?

    If you only want to do it once and completely comply with the DRY method, you can build a monolithic application knowing that as new features become required, application wide regression testing will be an absolute requirement.

    If you want ultimate flexibility for future changes with this collection of features and don't mind recoding the migration across multiple apps while reducing the need for application wide regression testing as new features become required, a microservice architecture strategy is more appropriate.