在 DJANGO 中围绕我的用户模型创建我的所有项目是一个很好的做法吗？
我找不到真正适合我需要的东西。 我有一个复杂的项目需要构建，并决定在学习 django 的过程中第一次承担这项艰巨的任务（是的，我知道这不是最明智的事情，但我认为从长远来看运行它会证明它自己...希望如此...LOL）
无论如何，在过去的项目中，使用.NET，在设计我的数据库时，我只是遵循 UML 并确保遵循所有规则。一切都很好，因为数据库和项目之间没有 OneToOne 相关性...构建我需要的数据库，然后创建项目来与我需要的内容进行交谈...只需与正确的 SP 交谈....
不，对于 DJANGO 来说，情况似乎正好相反，我不知道我迄今为止所遵循的编程模型（逻辑）是否仍然有效。
重点是：
我正在同时构建两个系统。该系统一般适用于自愿康复协会。有公众和用户的前台，以及首席执行官和其他人员的 CMS/后台（除了网站中的还有更多的东西，但是当然，网站从后台获取数据，例如用于登录的用户身份验证、用于登录的用户名）出版物等等...）。
所以，我想说的是，这是一种基于用户的项目，大多数表格（模型？）以一种或另一种方式连接到用户（我用问题标记编写模型，因为当表示数据库时就是一切）在用户表周围，但不确定何时将其更改为 MTV，它到底应该是什么样子 - 因为模型之间的连接、继承和反向连接）...
我已经阅读了我能找到的所有 DJANGOPROJECT 文档，但众所周知，那里的所有示例都非常简单，两个，三个模型，我找不到这种规模的项目的复杂示例....
我很乐意使用 django 来完成，学习曲线真的很陡，但希望我能睁开眼睛，看到更好的世界（我已经做到了，每天我都越来越爱上它......开源万岁（来自很长一段时间的微软迷） ...LOL）
只是为了显示部分数据库表（因为它们位于 ms-sql 数据库中，我很确定这对于 DJANGO 来说不是正确的事情，因为在我看来，保持它像这样不符合逻辑那个，但对于纯 SQL，这是要走的路）：箭头指向主键所在的表。
putTypes <-committeePubs->;委员会 <- 委员会成员 ->用户
ArticleGenres <- ArticleInGenres ->;文章->用户
ImageTypes <- 图像 ->画廊 ->用户
残疾<-用户
等等......每件事都以一种或另一种方式连接到用户，无论用户是主表还是数据提供者表......
现在，可以任何人都可以帮助我，我知道这是一个巨大的要求，当然，我不是在寻找任何人来握住我的手并一步步带我，只是寻找一个大/复杂的例子，以便我可以从中学习，具有一组复杂的表（模型）以及何时何地构建新应用程序以及何时在同一个应用程序中执行操作。另外，如果可能的话，如何将用户表连接到所有其他表（我知道我导入并只是使用它，但这比那要复杂得多）。
最后一件事，抱歉语法错误，不是我的母语......试图抓住它们，但我并不总是能......
PS另一件事，我的用户模型比 django 模型复杂得多，我有还有很多字段需要存在，该怎么办？ 10 倍用于阅读和帮助，任何人都可以......并且无论如何，如果没有，也 10 倍:-)
Erez
I couldn't find a real andwer for what i need.
I have a king of complex project to build and decided to take the huge task of doing it for the first time while learning django in the proccess (Yes, I know it is not the smartest thing to do, but I think that in the long run it will prove it self...Hope so...LOL)
Any way, In past projects, Using .NET, when designing my DB, I just used followd the UML and made sure that all the rulls are followd. and every thing was OK, as there is not OneToOne corelation between the DB and the project...building the DB i need and then creating the project to talk with with what i need from there....just talking with the right SP....
No, With DJANGO it seem kind of the other way around, and i don't know if the programming model (logic) I used to follow until now is still valid.
And to the point:
I'm building two systems in the same time. The system in general is for a Voluntary rehabilitaion association. There is the front for the public and users and The CMS/backoffice for the CEO and stuff (many more things then what in the site, but ofcourse, the website gettes the data from the backoffice, like user othentication for login, user name for publictaions and so on...).
So, what I am trying to say, this is kind of User based Project, most the tabels (models?) in one way or the other connect to the user (I wrote models with a questien mark becouse when representing a DB is every thing around the user table, but not sure when changing it to MTV, what really it should look like - becouse of the connection and inheritance and reverse connections between the models)...
I've read all the DJANGOPROJECT docs I could find about it, but as we all know, all the examples over there are very simple, two, three models and i couldn't find a complex example for a project this size....
I would love to do it with django, The learning curve is really really steep, but hopefully, I will open my eyes and world for better things (allready did, and every day i'm falling inlove with it more and more...LONG LIVE OPEN SOURCE (FROM A LONG TIME MICROSOFT JUNKY)...LOL)
Just to show part of the DB tables (as they are in a ms-sql DB, i'm preaty sure it is not the right thing for DJANGO as it doesn't seem logic to me to keep it like that, but for pure SQL this is the way to go): The arrows point to the table where the primary key is in.
putTypes <- committeePubs -> committees <- committeeMemebers -> Users
ArticleGenres <- ArticleInGenres -> Articles -> Users
ImageTypes <- Images -> Galleries ->Users
Disabilities <- users
And so on....Every thing is connected to the Users in one way or the othere, wether the User are the primary table or the data provider table....
Now, Can any one help me with this, I know it is a masive request, And ofcourse i am not looking for any one to hold my hand and take me step by step, just looking for a big/comples example so i could learn from there, with a complex set of tables(models) and where and when to build a new app and when to do things in the same app. And also if posible, how to connect the Users table to all the other tables (I know about i import and and just using it, but this is much more complicated then that).
Last thing, Sorry for the grammer mistakes, not my native language...trying to catch them, but I don't always can....
P.S. Another matter, my Users models is much more complicated then the django one, I have many more fields that need to be there, what to do with that?
10x for reading and for helping and any one can....And any way, if not, also 10x :-)
Erez
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
你想象的方式并没有什么特别的问题。不过有几点。
Django 模型通常使用单数名称 -
Committee而不是Committees。committeeMembers和ArticleInGenres似乎以多对多关系链接表。如果它们只是，并且除了两个外键之外不存储自己的任何信息，您可以完全忽略它们 - 只需在Committee，指向User，Django将为您创建和管理中间表。从
User到Disability的链接更加复杂。您不应该真正修改内置的 User 模型。除了关于User上额外字段的最后一点，似乎您最好的选择是定义一个单独的UserProfile模型，其中OneToOneField为 < code>User，您可以在其上存储额外信息。There's nothing particularl wrong with the way you've pictured it there. A couple of points though.
Django models are usually given singular names -
Committeerather thanCommittees.The
committeeMembersandArticleInGenresappear to be linking tables in many-to-many relationships. If they're just that, and don't store any information of their own other than the two foreign keys, you can leave them out completely - just define a ManyToManyField onCommittee, pointing atUser, and Django will create and manage the intermediate table for you.The link from
UsertoDisabilityis more complicated. You shouldn't really modify the built-in User model. Along with your final point about extra fields onUser, it seems that your best bet is to define a separateUserProfilemodel with aOneToOneFieldtoUser, on which you can store the extra information.