如何着手开发自有Oracle数据库？应用建库schema选型及公共schema疑问

• 先搞定数据库实例环境：个人本地开发直接装Oracle XE版本就行，免费、资源占用低，完全覆盖开发阶段的功能需求；团队共用的测试/生产环境，在独立服务器上安装对应授权版本的Oracle，完成实例创建、监听配置，用SQL Developer或者sqlplus能正常连通实例就算环境就绪。
• 提前规划存储：单独创建业务专用的表空间，绝对不要把业务数据存在SYSTEM、SYSAUX这类系统默认表空间里，很容易因为空间占满导致整个数据库实例崩溃。
• 做好权限分层：不要上来就给所有账号开DBA权限，按开发、测试、运维的实际操作需要分配最小必要权限，减少误操作风险。

• Oracle的机制里Schema和数据库用户是强绑定的，一个用户对应一个同名Schema，没有脱离用户单独存在的Schema。你给应用专门创建的业务用户，就是这个应用对应的主Schema。
• 常规实践是给每个独立业务应用创建单独的业务用户，给这个用户绑定之前建好的业务表空间，授予建表、建序列、建视图、建存储过程等必要的开发权限，应用所有的业务对象（表、索引、触发器、存储过程、函数等）全部建在这个用户对应的Schema下，不要和其他应用的对象混放。
• 严禁直接用SYS、SYSTEM这类系统预置的管理用户作为应用主Schema，这类用户存储的是数据库核心运行元数据，误操作很可能直接导致整个实例不可用。

• Oracle本身没有预置可供所有普通用户随意修改使用的公共Schema，很多人搞混的PUBLIC是公共权限角色，不是Schema。
• 如果团队确实需要一个公共区域存放共享的字典表、通用工具函数/存储过程等公共对象，可以专门创建一个独立的业务用户（比如命名为COMMON_OBJ）作为公共Schema，把所有共享对象建在这个Schema下，再按需给其他开发用户、业务Schema授予对应对象的查询、编辑、执行权限即可，不要直接把这个公共用户的登录密码分发给所有人。
• 任何场景下都不要把SYS、SYSTEM这类系统Schema当作公共协作Schema使用，风险不可控。
• 团队协作时不要所有人共用同一个高权限账号操作，要给每个开发人员创建独立的个人账号，通过权限授权的方式访问主业务Schema、公共Schema的对象，方便后续操作审计、问题溯源。

内容的提问来源于stack exchange，提问作者ahmed mokhtar