英文:
Are there any pros, cons or best practice of having multiple Oracle APEX apps on multiple workspaces\schemas vs a single workspace\schema?
问题
Case 1: 我在同一个工作区中有两个Oracle APEX应用，连接到模式A，该模式已被授权访问存储在模式X中的数据。
Case 2: 我在同一个工作区中有两个Oracle APEX应用，连接到模式A，该模式已被授权访问存储在模式X和Y中的数据，这两个应用分别存储其数据。
Case 3: 我有两个独立的Oracle APEX应用，它们位于不同的工作区。应用1的工作区连接到模式A，该模式已被授权访问存储在模式X中的数据。而应用2的工作区连接到模式B，该模式已被授权访问存储在模式Y中的数据。
这两个应用还会相互通信并共享一些数据。
关于如上所述结构化Oracle APEX应用、它们的工作区和底层模式的做法，是否存在任何优缺点或最佳实践？
英文:
Case 1: I have two oracle APEX apps in a single workspace connected to schema A, which has granted access to data stored in schema X.
Case 2: I have two oracle APEX apps in a single workspace connected to schema A, which has granted access to data stored in schema X and Y, where the apps store their data separately.
Case 3: I have two oracle APEX apps in separate workspaces. Where app 1's workspace connects to schema A, which has granted access to data stored in schema X. And app 2's workspace connects to schema B, which has granted access to data stored in schema Y.
The two apps also communicates and share a little data between them.
Are there any pros, cons or best practice related to structuring the oracle APEX apps, their workspaces and underlying schemas as mentioned above?
答案1
得分: 2
I'd say it is you who should decide.
When HTMLDB was released (and then came Apex itself), we ("we" is our IT department) used [1 schema - 1 workspace - 1 application].
Then, as we grew older, we found out that this isn't the best option. Why? Because there's stuff we'd like to share (trivial example: workspace images), so - why would we import them into ALL workspaces and - basically - duplicate things? Nowadays, it is [n schemas - 1 workspace - n applications].
(OK, not really - there are different workspaces when we think that we'd rather separate one group of jobs from another, but it definitely isn't 1:1:1 any more).
As of schemas exchanging data: it works, no problem; grant required privileges, create synonyms (or not) and you're good to go. Lately, on one project, lead developer meant to split one application to 2 schemas/applications (so we'd have [2 schemas - 1 workspace - 2 applications] for that project). After discussion, we decided to keep everything in the same schema (to avoid grants/synonyms issues), one workspace, and 2 (or more) applications, all based on the same schema.
So - it is up to you. Oracle talks about modularization, but - perhaps we shouldn't overmodularize things. Instead of making things simpler, they might actually become more complex than they should be.
英文:
I'd say it is you who should decide.
When HTMLDB was released (and then came Apex itself), we ("we" is our IT department) used [1 schema - 1 workspace - 1 application].
Then, as we grew older, we found out that this isn't the best option. Why? Because there's stuff we'd like to share (trivial example: workspace images), so - why would we import them into ALL workspaces and - basically - duplicate things? Nowadays, it is [n schemas - 1 workspace - n applications].
(OK, not really - there are different workspaces when we think that we'd rather separate one group of jobs from another, but it definitely isn't 1:1:1 any more).
As of schemas exchanging data: it works, no problem; grant required privileges, create synonmys (or not) and you're good to go. Lately, on one project, lead developer meant to split one application to 2 schemas/applications (so we'd have [2 schemas - 1 workspace - 2 applications] for that project). After discussion, we decided to keep everything in same schema (to avoid grants/synonmys issues), one workspace and 2 (or more) applications, all based on same schema.
So - it is up to you. Oracle talks about modularization, but - perhaps we shouldn't overmodularize things. Instead of making things simpler, they might actually become more complex than they should be.
通过集体智慧和协作来改善编程学习和解决问题的方式。致力于成为全球开发者共同参与的知识库，让每个人都能够通过互相帮助和分享经验来进步。
评论