Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 5 years ago.
Improve this question
I wonder if a good habit is to have some logic in MySQL database (triggers etc.) instead of logic in Django backend. I'm aware of fact that some functionalities may be done both in backend and in database but I would like to do it in accordance with good practices. I'm not sure I should do some things manually or maybe whole database should be generated by Django (is it possible)? What are the best rules to do it as well as possible? I would like to know the opinion of experienced people.
It is true that if you used a database for your business logic you could get maximum possible performance and security optimizations. However, you would also risk many things such as
No separation of concerns
Being bound to the database vendor
etc.
Also, whatever logic you write in your database won't be version controlled with your app. Thus, whenever you change your database, you will have to create all those things once again.
Instead, use Django ORM. It will create and manage your database based on your models by itself. As a result, whenever you recreate your database, you will just have to run migrations with one single command and you are done.
This will cover most of the situations. And whenever you will need those speeds of stored procedures, Django ORM has you covered as well.
In short, I believe that business logic should be kept out of the database as much as possible.
Related
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 10 months ago.
Improve this question
I have just learned python, and am beginning to make a web application using Django / DRF in the back end.
The back end would be similar to a CRUD, or just a CRUD actually, I'm not planning on doing too much processing on requests, but would be queuing jobs for another python script on the server to pick up when needed.
The API I'm building would need to manage a few different entities like Users, Packages, Transactions, Jobs etc, and I plan to manage all of these entities... no ... models... via a rest API.
Do I create an app for each model ? e.g. user_app, package_app, and transaction_app ? or should I create a single app to manage them all?
I'm torn between thinking of Django Apps as actual applications, or Bundles like in PHP/Symfony
There is no obligation to create a new app for every feature that depends on another part of the project logic.
But overall the more you divide into, the easier it will be in the future.
when the project updated and new features added it will be easy to manage it.
Also take a look at some open source projects.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 2 years ago.
Improve this question
I'm currently writing a chat-application for my Website and storing all the Messages in one database, by referring to sender and receiver with a Foreign-key.
Is this really the smartest Idea? I think the site could become slow when everybody is trying to access the same database or when the number of sent messages gets big. Would it be smarter/faster, to use one database per user, storing his/her messages there? If yes, am i right that this is not really possible to achieve this with Django?
Thanks for your Answer!
Would it be smarter/faster, to use one database per user
Probably not, because you will still have the same quantity of data and just have the overhead of have multiple database instances
this is not really possible to achieve this with Django?
Django is not a database manager, so the question does not really make sense. For example, Oracle or SQLite allow a single query to access multiple databases. So if you used Oracle with Django, you could have a different database per user. Anyway, even if by default Django only uses one single database connection, it can be configured to use multiple databases (thanks to #brunodesthuilliers for the info).
Database design is a rather complex operation: you have to design the tables to structure the data, the indexes, to speed up some accesses and/or enforce uniqueness, and optionaly views to easy request writing. Once this is done (and the database is used), you will have to define recurrent tasks to cleanup the database (index maintenance, archivage and purge of archived data).
If you intend to use a large farm of servers to be able to handle thousands of simultaneous accesses, a SQL database can indeed become a bottleneck, and you should considere NoSQL databases to dispatch the load on independant servers. But in this use case, Django would just be a casting error. Anyway, I know no example of real world use case where multiple databases are used just for performance reasons.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 7 years ago.
Improve this question
I'm diving into Django to create a webapp.
The thing is, I'm not sure if my app is too simple for what Django offers.
My app will download the latest CPI figures and convert your (monetary) dataset into inflation-adjusted figures, going way back in decades. The user pastes their data in via a textbox. It certainly won't need SQL.
I may want to expand the project with more features in future.
Is it advisable to go with a more lightweight framework for something as simple as I've described?
Every framework has its pros and cons. There are many different frameworks. Personally I prefer Flask but it is all personal preference. Here are some articles that help describe the differences:
https://www.airpair.com/python/posts/django-flask-pyramid
https://www.reddit.com/r/Python/comments/1yr8v5/django_vs_flask/
https://www.hakkalabs.co/articles/django-and-flask
A webapp like the one you describe sounds like most of the work can happen on the client side, without sending the data back to server. From what it sounds like, you simply need to make a few calculations and present the data in a new way.
For this I don't recommend Django, which is ideal for serving pages and managing relational DB content, but not really useful for client side work.
I'd recommend AngularJS
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 9 years ago.
Improve this question
Since syncdb doesn't alter existing tables [1] I'm wondering what the downsides would be of logging in to a database and altering the structure.
More specifically I'd want to know what potential problems could be triggered if I change the length or type of a field (e.g. INT to BIGINT).
Will there be any issues with Django trying to truncate or alter the value to fit within the scope defined in the model?
Downsides ? If you are talking about simple project, then there arent any. Do whatever pleases you :). If the project grows bigger, then read next paragraph :P
If it is larger project and has other contributors (and even if it does not), you need to version control it. And for this reason, manual changes are BAD. Cause you just cant go back to earlier version without changing the database.... BUT....
But since you are talking about doing this manually, i feel, that i need to point out the existance of http://south.aeracode.org/
Which is created exactly for the reason that you, perhaps, should not be doing this manually.
BTW. im trolling here and talking tongue in cheek... don't take this post 100% seriously :P
Django South is the solution to this problem. It is a "must have" app to include (and here I'm going to disagree with #OdifYitsaeb's answer) in ANY project, not just large ones. It is so simple and powerful that you are essentially creating more work for yourself if you don't use it even in a tiny personal project.
It's soon to be included into Django core in (I beleive) 1.7 as well, so it's a good idea to get familiar with it now.
Closed. This question is opinion-based. It is not currently accepting answers.
Want to improve this question? Update the question so it can be answered with facts and citations by editing this post.
Closed 8 years ago.
Improve this question
I just start a django-fairy project for django 1.3.1 here: https://github.com/goFrendiAsgard/django-fairy
It is just a simple (but I think useful) python script that can help django newbie to develop everything faster. The basic idea is:
When you make a view, usually you will make respective url and template
When you make a model, usually you will register it on admin
So that it would be more fun, if there is a way to do such a things in a simple way.
I want to make sure if what I do is right.
So these is my questions:
Do you think that such a project is useful for community?
Is it violate django (and python) philosophy?
Do you think that such a project is useful for community?
Yes, just keep developing it plus, you will know that from the users as feedback and even if the feedback wasn't good enough, let your project be, enhance it more and more and your project will get a good rating and acceptance in no time. Just consider your users' notes and comments and you will be fine.
Is it violate django (and python) philosophy?
No, it is not.
The only way to tell if it is useful is for you to complete it and publish it and people start using it.
No, there are tons of other quick bootstrapping scripts available for django. There is no such policy that prevents this.
However, you shouldn't make a lot of assumptions as to what the end user will want to do with their models/views. Django is a toolset and as such there are lots of ways to use it.
For example, there are models that are never entered in the admin, and similarly there are django sites that don't have a "front end" (ie, a view) and only use the ORM and the admin, with applications like databrowse