I have used Django long back, so it might not be the best solution.
Surely creating one big models.py and views.py will make your code not
scalable for future, and making small interlinked apps will also not the
Your intermediate solution is better than both above solutions. One
optimisation you can do it try to make a dependency graph, and create apps
with most interlinked cluster. May be every cluster will have a "Sets"
model, or a separate app depending upon the graph you will create.
So I will suggest to create a graph, and see what can be the best solution
you can have.
On Saturday, April 14, 2018 at 7:40:27 PM UTC+5:30, Mikkel Kromann wrote:
> I'm new to Django, and I'm working my way into Django by going through the
> nice Djangoproject.com turorial.
> I'm trying to find out whether Django is the right tool for my task, which
> is maybe a bit unusual for Django.
> My task is to build a web interface to a database for an calculation tool
> made in Python.
> The database will contain maybe up to 100.000 pieces of data (mostly
> decimal fields), and the tool will import this data, do some calculations
> and write some results back to the database.
> My Django web interface should allow the user to view, add, delete and
> edit the data in the database, and view the results with tables and charts.
> The data is organised in various chunks:
> - "Sets" which lend themselves very nicely to Django models, i.e.
> HouseholdType, Item, City, Month, Year
> - "Maps", which are user defined ManyToOne or ManyToMany relations between
> the various sets (can probably be worked into the "sets" models)
> - "Data Tables", which contains the main load of data, having the "sets"
> as foreign keys (e.g. "Demand" for each HouseholdType, Item, City, Month
> and year)
> - "Results tables", calculated by the tool but in structure quite similar
> to the "Data tables"
> I will have roughly 10 sets, 10 maps. 20-30 data tables and 10-20 result
> I understand that putting all these into a one app will create biiig
> models.py and views.py files, which is probably a bad idea.
> On the other hand, splitting the sets, maps and tables into several apps
> does not seem to be an ideal solution either.
> All the tables and the maps will be models that have foreign keys to the
> "sets" models.
> My understanding so far is, that it is also bad to have a lot of
> interlinkage between the various apps.
> An intermediate solution might be, that if I make a "Sets" app containing
> all the models that are going to be primary key in the other apps, then the
> interlinkages between the apps is somewhat simplified.
> Any thoughts or advice?
> cheers, Mikkel
You received this message because you are subscribed to the Google Groups
"Django users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
To post to this group, send email to firstname.lastname@example.org.
Visit this group at https://groups.google.com/group/django-users.
To view this discussion on the web visit
For more options, visit https://groups.google.com/d/optout.