在 Asp.Net MVC 应用程序中以编程方式创建新数据库？
我在 MVC 2 中开发了一个时间表应用程序，供我们公司内部使用。现在其他小公司也对该应用表现出了兴趣。我没有考虑过该应用程序的这种用途，但它让我对它可能意味着什么感兴趣。
我相信我可以通过修改数据库（通过实体框架模型访问Sql Server）使其适用于多个客户端。但我读过一些人提倡使用多个数据库（每个客户一个）。
直观上，这感觉是一个好主意，因为我不会冒险将不同客户端的数据混合在同一个数据库中（这当然不应该发生，但如果发生了怎么办......）。但多数据库解决方案具体如何实施呢？
即，使用单个数据库，我可以只注册一个客户端，并且应用程序将添加所需的所有数据，就像现在只有一个客户端（我自己的公司）时一样。
但是，使用多数据库解决方案，当用户注册时，如何以编程方式创建新数据库？请注意，我已经使用 Linq to Sql 完成了所有数据库工作，并且我对常规 SQL 编程不太熟悉...
我真的很感谢对如何完成此操作的清晰详细解释（以及关于是否是这样的输入）一个好主意，或者是否由于某种原因单个数据库会更好）。
编辑：
我还看到了有关单一数据库替代方案的讨论，建议您将 ClientId 添加到每个表中...但这不会很难在代码中维护吗？我必须向我假设的许多 linq 查询添加“where”条件...并且我假设每个表上都有一个 ClientId 意味着每个表都需要与 Client 表具有多对一的关系？那不是一个非常复杂的数据库结构吗？
现在（没有客户表）我有以下表格（1 -> * 指定一对多关系）：
Customer 1 -> * * 项目1-> * 任务1-> * 时间段 1 -> * Employee
另外，Customer 与 TimeSegment 直接是一对多的关系，方便简化一些查询。
到目前为止，这种方法效果很好。是否可以简单地拥有一个与 Customer 表具有一对多关系的 Client 表（或 UserCompany 或任何可能称呼它的名称）？由于其余表是由关系处理的，数据完整性对于其他表来说是否足够？
I have worked on a timesheet application application in MVC 2 for internal use in our company. Now other small companies have showed interest in the application. I hadn't considered this use of the application, but it got me interested in what it might imply.
I believe I could make it work for several clients by modifying the database (Sql Server accessed by Entity Framework model). But I have read some people advocating multiple databases (one for each client).
Intuitively, this feels like a good idea, since I wouldn't risk having the data of various clients mixed up in the same database (which shouldn't happen of course, but what if it did...). But how would a multiple database solution be implemented specifically?
I.e. with a single database I could just have a client register and all the data needed would be added by the application the same way it is now when there's just one client (my own company).
But with a multiple database solution, how would I create a new database programmatically when a user registers? Please note that I have done all database stuff using Linq to Sql, and I am not very familiar with regular SQL programming...
I would really appreciate a clear detailed explanation of how this could be done (as well as input on whether it is a good idea or if a single database would be better for some reason).
EDIT:
I have also seen discussions about the single database alternative, suggesting that you would then add ClientId to each table... But wouldn't that be hard to maintain in the code? I would have to add "where" conditions to a lot of linq queries I assume... And I assume having a ClientId on each table would mean that each table would have need to have a many to one relationship to the Client table? Wouldn't that be a very complex database structure?
As it is right now (without the Client table) I have the following tables (1 -> * designates one to many relationship):
Customer 1 -> * Project 1 -> * Task 1 -> * TimeSegment 1 -> * Employee
Also, Customer has a one to many relationship directly with TimeSegment, for convenience to simplify some queries.
This has worked very well so far. Wouldn't it be possible to simply have a Client table (or UserCompany or whatever one might call it) with a one to many relationship with Customer table? Wouldn't the data integrity be sufficient for the other tables since the rest is handled by the relationships?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
至于是使用单个数据库还是多个数据库，这实际上完全取决于用例。更多的数据库意味着更多的管理需求，可能需要更多的磁盘空间等。这里需要考虑的事情不仅仅是如何创建数据库，例如如何自动创建备份过程等。我个人会使用一个数据库一个良好的身份验证系统，可以将数据过滤到适当的客户端。
关于创建数据库，请查看这篇博文。它描述了如何在c#.net中使用SMO（sql管理对象）创建数据库。它们是一个非常简洁的工具，您一定会想熟悉它们。
为了处理后续问题，是的，客户和客户之间的单一顶级关系应该足以限制新客户使用适当的数据。
如果对您的应用程序没有任何真正的了解，我无法说添加该表有多复杂，但假设您的数据层符合要求，我会假设您实际上只需要限制当前客户端的客户类别，并且然后根据可用客户获取所有其余数据。
这有什么意义吗？
as far as whether or not to use a single database or multiple databases, it really all depends on the use cases. more databases means more management needs, potentially more diskspace needs, etc. there are alot more things to consider here than just how to create the database, such as how will you automate the backup process creation, etc. i personally would use one database with a good authentication system that would filter the data to the appropriate client.
as to creating a database, check out this blog post. it describes how to use SMO (sql management objects) in c#.net to create a database. they are a really neat tool, and you'll definitely want to familiarize yourself with them.
to deal with the follow up question, yes, a single, top level relationship between clients and customers should be enough to limit the new customers to their appropriate data.
without any real knowledge about your application i can't say how complex adding that table will be, but assuming your data layer is up to snuff, i would assume you'd really only need to limit the customers class by the current client, and then get all the rest of your data based on the customers that are available.
did that make any sense?
请参阅我的答案，它也适用于您的情况： c# 数据库架构
See my answer here, it applies to your case as well: c# database architecture