网站上的多个组织处理 [英] Multiple organisation handle on website
问题描述
我想创建学校管理ERP类型的Web应用程序。
我没有太多经验，但我的团队可以处理所有设计和编程方面。
但我只想知道如何在一个网站上处理不同的学校。
我的意思是我有'School_A'或'School_b'。这些数据不应该显示给其他用户。
当用户注册到网站时，我观察到许多网络应用程序，如jira和一些项目管理费用他们创建了他们的子域名。
例如www.abc.com \ school&and www.abc.com\schoolb
我想知道这是我们应该创建url的方式！
当我使用我的凭证系统登录时，知道哪个实体（School_A或School_B）需要重定向。
其次是每个新的组织注册。系统是否创建不同的数据库并获得结果表单，数据库或数据库对于整个Web应用程序保持相同，并与唯一的学校ID区分开来。
i认为这个数据库可能会杀死永久性所有组织的数据都会增加。
我尝试过：
创建小型事务窗口应用程序，但现在我想要在线erp。
I want to create School management ERP kind of Web application.
I dont have much experience but my team can handle all designing and programming aspect.
But I just want know how to handle different school on one website.
I mean I have 'School_A' or 'School_b'. That data should not be shown to each other users.
I have observed many of the web applicaiton like jira and some project management tolls, when user register on to web site they create their sub domain.
Eg www.abc.com\schoolA and www.abc.com\schoolb
I wonder this is the way we should create url!
More over when i am login with my credential system knows on which entity (School_A or School_B) need to redirect.
Secondly on every new organisation register. does system create different database and getting result form that database or database remain same for whole web application and differentiate with unique school ID.
i think this one database might kill permanence when data gets increase for all organisation.
What I have tried:
Create small transactional window application but now i want to online erp.
推荐答案
你所要求的是一个很大的任务，没有经验的人无法开始建立。我意识到你更想要了解它是如何构建的，但是如果你让团队按照你的说法处理这个问题，我会说你最好问你的问题/与你的团队合作来理解你的项目试图建立。毕竟，他们是需要了解要求的人，并且是唯一能够告诉你他们是否能够建立你想要的东西的人。
但是在这里回答你的基本问题。您要问的是您是否应该构建单租户与多租户应用程序。
单租户意味着每个应用实例1个客户。
多租户意味着每个应用实例超过1个客户。
有很多不同的方法可以构建如此规模的应用程序，但根据您的其他问题，让我们假设您正在进行多租户路线。 br $> b $ b
What you are asking is quite the large task that someone with no experience can't begin to build. I realize you are more wanting to understand how it is built, but if you've got the team to handle this as you say, I would say you are best off asking your questions/working with your team to understand the project that you are attempting to build. After all, they are the ones who need to understand the requirements and are the only ones who will be able to tell you if they can build what you want.
But to answer your basic questions here. What you are asking is whether you should build a Single-tenant vs Multi-tenant application.
Single-tenant meaning 1 customer per instance of your application.
Multi-tenant meaning more than 1 customer per instance of your application.
There are many different ways to go about building an app of this magnitude but based on your additional questions, lets just assume you are going the multi-tenant route.
但我只想知道如何在一个网站上处理不同的学校。
我的意思是我有'School_A'或'School_b'。这些数据不应该显示给其他用户。
But I just want know how to handle different school on one website.
I mean I have 'School_A' or 'School_b'. That data should not be shown to each other users.
在此平台上设置新的客户时，您可以通过某种方式将用户与其数据联系起来，以便将School_A的用户分配/绑定到School_A的数据，而不是任何其他客户数据。或者，您可以将用户绑定到公司或可以将许多用户分组到一个Id的某种级别的记录。然后在您的客户表中，您可能会有一个将客户与公司联系起来的CompanyId。这样，任何绑定到公司的用户都只能看到公司客户的数据。 （例如：用户A，与公司B绑定。公司B与School_A绑定，因此任何与公司B绑定的用户只能看到School_A的数据。）
When setting up new "customers" on this platform, you would have some sort of way to tie users to its data so that users of School_A are assigned/tied to data of School_A but not any other customers data. Or you would tie users to a "company" or some level of record that can group many users to one Id. Then on your "customers" table you might have a CompanyId that ties customers to a company. That way, any users tied to a company can only see that companies customers data. (Ex: User A, tied to company B. Company B is tied to School_A so any user tied to company B can only see School_A's data).
我观察过许多网络应用程序，如jira和一些项目管理费用，当用户注册到网站时，他们创建了他们的子域名。
例如www.abc.com \ schoolChote和www.abc.com\schoolb
I have observed many of the web applicaiton like jira and some project management tolls, when user register on to web site they create their sub domain.
Eg www.abc.com\schoolA and www.abc.com\schoolb
有很多是实现这一目标。最好与您的团队交流，了解他们的能力。你可以为每个客户启动1个服务器但是想要自动执行此操作，或者只是让它像你的例子一样。
There are a number of was to accomplish this. It is best to talk with your team to understand what their capabilities are. You could spin up 1 server per customer but would want to automate this, or just simply have it like your example.
当我使用我的凭证系统登录时，知道哪个实体（School_A或School_B）需要重定向。
More over when i am login with my credential system knows on which entity (School_A or School_B) need to redirect.
请参阅上面关于将用户与公司关联的评论。公司可能是错误的术语，但是如果你有很多用户到学校。您可能希望将这些用户分组到公司以简化操作。这样，公司的管理员就可以注册更多用户并相应地关联它们。
那你或者你只需创建一个学校用户映射表，将用户ID映射到学校。这可能无法很好地扩展，具体取决于您使用应用程序的方向。
See my comments above about associating users to a company. Company might be the wrong term here but if you are going to have many users to a school. You might want to group those users to a Company to make things easier. That way an "admin" of the "company" could then register more users and associate them accordingly.
That or you'd just have to create a Schools to users mapping table that maps user id's to schools. This might not scale well depending on what direction you go with your app.
其次是每个新的组织注册。系统是否创建不同的数据库并获取结果表单，数据库或数据库对于整个Web应用程序保持相同并区分唯一的学校ID。
Secondly on every new organisation register. does system create different database and getting result form that database or database remain same for whole web application and differentiate with unique school ID.
我建议你看看更多单租户vrs多租户应用程序。如果您不理解这个概念，除非您只是为了自己的利益而提出这些问题，否则您的开发团队应该理解。
简而言之，如果这是一个启动但每个客户启动1个数据库可能不符合成本效益，但如果数据是超级敏感的（例如：社会安全号码）你可能需要是单个租户申请。我不知道你的应用程序的长期未来的希望，梦想和愿望，所以据我所知，我会去多租户。
I suggest you look more into single tenant vrs multi-tenant applications. If you don't understand this concept then, unless your just asking these questions for your own benefit, your team of developers should understand.
In short, starting 1 DB per customer may not be cost effective if this is a start up but if the data is super sensitive (ex: social security numbers) you may need to be a single tenant application. I don't know your hopes, dream and desires for the long term future of your app so from what I know, I would go multi-tenant.
我认为这个数据库可能会在所有组织的数据增加时终止持久性。
i think this one database might kill permanence when data gets increase for all organisation.
除非你使用的是一些没有名称的数据库，否则1个单独的DB / DB服务器可能会很好。同样，我对你的应用程序知之甚少，但我非常怀疑你是否会通过这个单独的数据库抽取足够的交易，因为这是一个问题。但同样，这取决于你的应用程序的需求。
即使它是，有镜像或托管选项，如RDS的选项，采取系统管理员你的数据库已经关闭了。
所以简而言之，这是一项雄心勃勃的项目，没有多少经验。在很多这些架构概念的广泛范围内，你应该做大量的研究。
Unless you are using some no name database, 1 single DB/DB server will more than likely be fine. Again, I don't know enough about your app but I highly doubt you'll be pumping enough transactions through this single DB for it to be a problem. But again, this is dependent upon the needs of your app.
Even if it is, there are options for mirroring or hosted options like RDS that take the sys admin of your DB off your hands.
So in short, this is quite the ambitious project to undertake with not much experience. With the broad scope of a lot of these architectural concepts, you should do a lot of research.
这篇关于网站上的多个组织处理的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！
