DB(MySQL)用户帐户与用户表-php

DB(MySQL)用户帐户与用户表-php,php,mysql,Php,Mysql,我对所有的web编程都是新手,我决定从PHP/MySql/Apache开始,避免使用框架来尽可能地简化事情 我的项目将涉及我的db为客户保存个人数据,因此安全性是一个优先事项,尽管不是财务方面的。因此,我一直在研究安全登录,除了我的首页,其他一切都将在ssl登录后运行 我的背景是oracle,我开发了oracle表单中的解决方案,每个用户都可以获得db登录,并根据db登录对用户进行身份验证,而对于MySql/PHP,身份验证似乎是建模的,因此您可以使用通用用户名/密码连接到db,然后使用哈希密码

我对所有的web编程都是新手,我决定从PHP/MySql/Apache开始,避免使用框架来尽可能地简化事情

我的项目将涉及我的db为客户保存个人数据,因此安全性是一个优先事项,尽管不是财务方面的。因此,我一直在研究安全登录,除了我的首页,其他一切都将在ssl登录后运行

我的背景是oracle,我开发了oracle表单中的解决方案,每个用户都可以获得db登录,并根据db登录对用户进行身份验证,而对于MySql/PHP,身份验证似乎是建模的,因此您可以使用通用用户名/密码连接到db,然后使用哈希密码对用户表进行身份验证

我总是发现oracle中的user session变量非常有用,可以从dual中选择user,用于控制对表、包、触发器、审核日志、管理会话等的访问

我的问题是,为什么不在web MySQL应用程序上执行这样的用户管理?我是否回到了客户机-服务器时代,我这样建模是否不正确,是否出于可伸缩性、安全性等原因


所有的讨论和示例都指向用户表模型,我在db身份验证中发现的唯一细节是。

在过去的10年里,我从Oracle的背景中学习了6年表单+报表+PL/SQL到PHP,我觉得我应该感同身受,但我没有!这主要是因为我一直不明白为什么有人想将应用程序用户镜像为数据库中的模式

我认为,最大的区别在于,在web开发世界中,数据库通常被视为存储数据的基础。在Oracle世界中,数据库被视为应用程序体系结构的中心

如果您将用户访问权限、他们的权限和特权视为数据,那么评估权限和特权并采取相应行动的业务就是应用程序的角色,这一点就开始有意义了。这与Oracle认为体系结构本身应该处理它的观点相反

将用户作为数据进行管理的一个巨大优势是它为您提供了灵活性

例如,如果您希望一个多租户的应用程序按服务付费,多个业务,都访问同一个数据库实例,但数据被分割,这样每个应用程序都看不到其他应用程序,该怎么办

在您描述的Oracle世界中,您只能在整个产品中拥有一个给定用户名的实例,即在企业之间。这听起来难以管理

如果你想允许用户名中有空格呢?或者使用他们的电子邮件地址?你需要开始应用某种形式的翻译


在我看来,自己管理它只会给您带来更多的灵活性,这将是我的默认立场。

我没有看到任何专业人士支持使用DB用户帐户,而不是考虑用户表:

在我看来,让10亿用户作为用户表中的行比让10亿数据库用户帐户更容易

如果您有数百种不同的用户权限,我认为无论哪种方式,您都需要一个用户权限表。在这种情况下,为什么不也有一个users表呢

考虑到您不会为每个用户单独设置一组数据表,我认为所有用户都需要对所有数据表拥有访问权限

通过在线应用程序管理用户的脚本包括添加新用户、设置用户权限等,我想需要某种根级别的访问。如果这些脚本中的任何一个可能被破坏,那么您的整个应用程序都将受到破坏


正如Rob Baillie已经提到的,您将受限于所选数据库的用户名命名约定。考虑到这可能不实用,您需要某种翻译来克服这一问题。

我可以想到一些原因-主要是用户数据特定于您的应用程序,而不是数据库。用户不需要db的权限/访问权限或其他任何东西,那么为什么要在那里设置它们呢

其次,如果不将用户数据存储为db用户,则可以完全控制如何使用应用程序存储和管理用户数据。你可以自由使用任何你想要的开发方法、标准或风格

第三,安全性——你真的不想让你的用户以任何方式直接连接到你的数据库。开发过程中的一个失误可能意味着他们有办法直接登录数据库