ASP.net网站/项目可以拥有多个数据库吗？

Question

我有大约15天的编程任务，我决定制作一种购物车/网络销售的东西。

我将拥有一个包含产品，价格，图片等的数据库

我正在考虑使用已处理订单的另一个数据库等

我应该制作一个有效的组合（制作一个数据库），还是应该为这些情况使用单独的数据库？

PS。我不是在谈论桌子，我在谈论DATABASES。 谢谢你们

Answer 1

除非您有充分的理由拥有多个数据库，否则请坚持使用。

话虽如此，单个项目的数据库数量没有技术限制。

编辑：拥有多个数据库的原因。除了已经提到的可扩展性选项之外，如果您从应用程序的性质中看到不经常需要这些旧记录，您可能还希望存档一些非常旧的东西（例如，按年份）。

Answer 2

虽然我确信有很多理由可能为什么你需要一个单独的数据库，但我会坚持使用一个数据库和一个订单表，（因为我猜你会在那里引用那些相同的产品订单）。它将使外键引用....更简单....

Answer 3

如果使用单个数据库，则可以强制实施数据完整性 如果您使用两个数据库，则可以分配费用

Answer 4

除非有实际原因，否则请保留到单个数据库。例如，如果您混合预先构建的应用程序，以便在加载自己的表之前删除所有表。即使这样，你也可以破解他们的脚本并使用1分贝。

此外，除非你有很多人与你合作 - 在15天内创建一个可行的购物车将是一个挑战。您可能真的想环顾一下可以修改的操作系统购物车。如果你是一个网络形象的人，那么DashCommerce还有其他几个人。如果你进入MVC，你可以修改Kona。

Answer 5

在企业级别，您希望限制需要支持的数据库的数量。

在SQL 7/2000中，我们采用了极端的方法，并为30多个应用程序使用了相同的数据库。这些天我们将其称为垃圾填埋场数据库 - 难以支持。我们最终决定将小型一次性应用程序放入垃圾填埋场数据库，但为具有10多个表，100k +记录等的任何内容创建新数据库。

使用SQL 2005，我们希望使用模式分离，因此DBA可以拥有更少的数据库，但开发人员可以依赖模式来了解哪些对象属于哪些应用程序。我们还没有完善这个概念，但我相信它会成功。

Answer 6

我认为您没有理由使用多个数据库。 我可以看到多个数据库的唯一优点是：

• 扩展 - 如果您是一个大型商业网站，使用多个数据库（您可以将每个数据库放在不同的服务器上）将更容易扩展。
• 安全性 - 如果您需要某些信息更安全，并且您不希望将其保存在具有用户创建内容的同一数据库中（因此可能被利用，即SQL注入），您可以将其分离到另一个另一台内部网络上的另一台机器上的数据库。

主要缺点是开发复杂性和额外维护。 通常你可以在没有其他数据库的情况下实现一些目标。 例如，如果是为了安全性，那么首先尝试所有查询清理和数据库身份验证方案似乎更具成本效益

Answer 7

购买的大多数购物车和电子商务解决方案都使用一个数据库。你为什么要考虑多个数据库？

您是否考虑使用多个dbs来获得性能优势？您可以改用复制。

多个dbs的问题的一个实例可能是外键。有些数据库，你无法在数据库中创建它们。

Answer 8

我目前使用的项目实际上是使用三个数据库，也有充分的理由。一个数据库用于用户向系统提供数据并查看该数据。用户只是内部同事，他们使我们的应用程序的数据保持最新。 第二个数据库包含此用户数据库的摘录，该数据库将发送给我们软件产品的客户。这些客户无法修改我们的数据，我们也不想让他们访问实时数据，特别是因为我们首先要确保数据有效。 第三个数据库用于通用错误/消息记录和维护用户数据库。

将整个项目划分为三个数据库的部分原因是为了安全起见。如果有人可以访问一个数据库，那么另外两个仍然是安全的。如果一个人失败，其他两个仍然有用。即使来自一个数据库的数据用于为另外两个数据库生成数据，三个数据库中的数据也完全不相关。这是使用多个DB的最重要条件：数据不应相互关联。 （尽管有些DBMS系统确实允许这些跨数据库链接！）

Answer 9

我当前的项目使用至少四个数据库，但那是因为我的项目是一个后期添加，旨在从其中三个数据库中提取数据并将其显示在地图上。第四个数据库是作为项目的一部分创建的，用于存储有关地图和项目用户的信息。

如果我必须添加不适合我创建的数据库的新信息，我会考虑添加一个全新的数据库。但是，确保所有数据库工作（SP，视图，表结构）在三种环境（本地，测试，生产）中保持一致是一项重大成本。我不确定我是否想要为我自己创建的多个数据库做这件事。 （我很幸运，维护项目使用的其他数据库是别人的工作。）

Answer 10

First, it's perfectly okay to use multiple databases, 
but unless you have a compelling reason, you're better 
off sticking to one.


I don't know what RDBMS you are using for your project, 
but most of them (like Oracle, SQLServer) offer a concept 
of schemas. So, you can use one database and create 
multiple schemas to segregate your tables.