数据库设计:为所有客户或许多小型数据库提供一个大型数据库

时间:2010-07-14 11:10:03

标签: php mysql database database-design relational-database

寻找任何建议或建议甚至是最佳做法。 我用php和mysql开发了一个在线数据库。它允许公司记录投诉和解决方案等。有一个用于登录的用户数据库和一个用于记录主要数据的cip数据库。 2家公司正在试验和测试数据库。目前,每家公司都使用单独的数据库和单独的html页面。我想知道添加更多公司的最佳方式是什么 我的想法是:

1。 为用户创建一个大型数据库,为cip创建一个大型数据库,并使用公司ID或类似信息来识别数据库中的各个公司记录。

2。 为每个公司使用相同的html页面,但从登录详细信息中选择要使用的数据库。因此,每个公司都有一个单独的cip数据库,但所有公司都使用相同的用户数据库。

3。 或者只是为每个公司保持一切。 (这可能对更新非常不利)

我希望我已经清楚明白并期待任何建议。

由于

10 个答案:

答案 0 :(得分:2)

我想要回答的一个问题是,您是否需要查看cutomer的数据以供您自己报告或使用?在这种情况下,你需要选择第一,否则你将有一个噩梦来获得良好的报道。

您是否会按客户进行任何定制?这表明将事情分开可能是更好的选择。如果您永远不会自定义,那么请不要分开。

我在所有这些选项中都使用过系统,第一个是长期维护的最佳选择。但是,如果您有组织并且计划好,所有这些都是可行的。如果您选择单独的操作,则必须能够将更改推送到所有客户端,因此必须通过源代码管理中保留的脚本对数据库进行更改。您甚至可能需要按数据库版本保留源代码管理,以便客户端可以选择是否升级。当然,在选项1中,没有人可以选择保留旧版本。如果这更符合您的业务需求,那么这对选项1来说是一个加分。

我非常同意Ollie Jones,如果您使用选项1,您必须拥有良好的数据库安全设计,以防止客户端看到其他客户端的数据。我们曾经将客户端从他们是唯一客户端的服务器移动到共享数据库,只有一个错过了询问client_ID的进程(在旧系统中不需要它,开发人员已经马虎相思)最终通过电子邮件发送所有所有其他客户的销售代表,提供有关第一个客户的信息。这花费了公司很多钱(既解决了问题,又发出了电子邮件道歉,结果我们几乎失去了一个客户,并且不得不给他们一些成本中断以保留他们)以及许多卑鄙的道歉和开发人员只是狭隘地错过了失去工作。让这成为一个教训,你不会学到很多困难。

答案 1 :(得分:1)

就个人而言,我会选择候选人#3。除用户部分外,这些类型的数据库可以迅速增长。为了保持最佳性能,建议尽量减少表格。 根据用户的凭据选择不同的数据库应该不难,因此应用程序逻辑不应该受到影响。

我理解您对可维护性的关注。每个客户都住在完全相同的应用程序堆栈上,还是他们有单独的安装?无论如何,维护应该易于编写脚本以执行多数据库更新。这不应该阻碍你选择这样的设计。

答案 2 :(得分:1)

这是一个有趣的案例,说明您的方便与保护客户数据安全的责任之间存在冲突。为了您的方便,很明显,如您的选项(1)中所述,多租户应用程序将是最容易上手的。

但是,如果您的业务取得成功,那么您将面临未来的重大问题。您描述应用程序的方式,您的某个客户公司从未合法地需要查看属于另一个客户公司的数据。事实上,如果他们要查看其他人的数据,那么您将面临严重的安全漏洞。如果违规行为涉及个人记录,您将面临商业威胁的成本和处罚。

因此,如果您选择选项(1),请不要快速进行代码检查和安全测试。如果您的安全测试不佳,那么您会感到抱歉,更糟糕的是,您的客户也会如此。

为了更好的安全性,您可能需要考虑选项(2)和(3)的组合:单个Web应用程序代码库,将您的多租户基因座从Web应用程序移动到mySQL服务器。 mySQL安全系统在多租户方面表现得相当不错:Wordpress,Drupal和Joomla都以这种方式工作,并且它们都被广泛部署。

这种方法还有另一个优点。如果您为Web应用程序和数据库构建简单的安装脚本所需的开发工作,您将能够将您的应用程序提供给客户,以便在他们自己的服务器上运行,如果这是他们想要的。

我不是说完全避免(1)。您的企业可能会提供托管的多租户应用程序(选项1)解决方案,其服务条款可以涵盖您的风险。而且,对于更大或更好装备的客户,您可以提供私人解决方案。

答案 3 :(得分:0)

如果您有一个名为companies的表,那么每个用户都可以拥有company_id,因此它与该公司相关。您只需要一个数据库就可以使用一对多的关系。

答案 4 :(得分:0)

1号是最好的方法。拥有一个所需信息的数据库,并使用ID来识别公司。如果您不想修改当前的应用程序文件,可以使用此DB-layout,但创建视图,模拟旧的数据库结构。

答案 5 :(得分:0)

  
      
  1. 为用户提供一个大型数据库,为cip提供一个大型数据库,并使用公司ID或类似信息来识别数据库中的各个公司记录。
  2.   

这是最好的选择。您可以将所有信息存储在一个数据库中,并根据用户登录信息进行区分(您可以在哪里知道用户所在的公司并在会话中存储公司ID)。但是,小心你的编码作为一个错误可以向公司展示其他公司拥有的一些信息。

答案 6 :(得分:0)

只需一个用户和公司的数据库即可。而且我认为你的页面中需要一些php,asp或jsp来识别用户并查询数据库......

答案 7 :(得分:0)

我会寻求解决方案(1),或者如果您认为有数千名客户使用您的网络应用程序(2)。

(3)绝对是一个噩梦。

顺便说一句,我想在解决方案(1)中你认为使用相同的html页面就像在解决方案(2)中一样,无论你是在大型数据库上使用还是在很多小型数据库上使用,我强烈建议使用相同的应用程序逻辑(html / php页面)总是适用于所有

答案 8 :(得分:0)

第一点

  • 为用户提供一个大型数据库 和一个大型数据库的cip和 使用公司ID或类似的 识别个别公司的记录 在数据库中。

我的意见还可以。因为数据库是建立和调整来存储和管理大数据的。但只考虑你应该正确设计表格。避免数据重复的情况等等。构建和管理大数据集是好的。但应该专注于设计。你应该调整你的表。为此你可以搜索谷歌的数据库设计和性能调整。

  • 为每个人使用相同的html页面 公司,但选择哪个数据库 使用登录详细信息。以便 每家公司都会有一个单独的cip 数据库但所有公司都使用 相同的用户数据库。

最好是为所有公司构建基本模板。这将有助于管理您的应用程序。在登录时,您可以选择公司需要或拥有的相应详细信息并将其加载到模板中。为公司创建一个登录表,从他们使用id点到你的信息数据集并将其加载到模板。这将有助于您进行调试及其制作应用程序的标准方法。

像facebook一样。每个人在登录时都有共同的主页模板,他们填写了他们的相关数据,如照片,视频,帖子等...

尝试开发类似的应用程序。

这些是我的建议..

答案 9 :(得分:0)

您会发现使用单个数据库要容易得多。你正走在正确的轨道上,考虑维护成本等等。

使用设计合理/相关的表格 - 例如:

Company Information Table
--------
Company_ID (primary key)
Company_Name
Other Fields...


Issue Table
--------
Issue_ID (primary key)
Company_ID (foreign key tied to the Company Information Table)
Issue_Text
Other Fields...

希望有所帮助