绝大多数的Oracle数据库性能问题都是由于数据库设计不合理造成的，只有少部分问题根植于Database Buffer、Share Pool、Redo Log Buffer等内存模块配置不合理，I/O争用，CPU争用等DBA职责范围上。所以除非是面对一个业已完成不可变更的系统，否则我们不应过多地将关注点投向内存、I/O、CPU等性能调整项目上，而应关注数据库表本身的设计是否合理，库表设计的合理性才是程序性能的真正执牛耳者。
在Oracle数据库设计中，合理的设计至关重要，因为它直接影响到系统的性能和效率。大多数性能问题源于设计不合理，而非内存、I/O或CPU配置。因此，优化Oracle库表设计是提升程序性能的关键。
我们需要考虑如何有效地表达业务数据。例如，员工的多个Email地址，可以采用多种方式处理：在一个表中设立多个字段，创建子表，或者在一个字段中以逗号分隔。每种方式都有其优缺点，需要根据实际业务需求和性能考虑。
物理存储方案也很重要。对于大数据表，分区策略能显著提高查询速度，降低I/O压力。表空间的合理分配可以避免资源争抢，确保数据分布均匀。
再者，建立合适的索引是提升查询性能的关键。Oracle提供了多种索引类型，如B树索引、位图索引、函数索引等。根据查询模式和数据分布，选择最适合的索引类型可以大大提高查询效率。在案例中，设计人员在T_ORDER表上建立了复合索引IDX_ORDER_COMPOSITE，用于支持特定查询，这是一个常见的优化手段。
然而，设计还有待优化的地方。索引和数据应分开存储在不同的表空间，这样可以减少索引维护时对数据操作的影响。索引的选择应考虑全列扫描和部分列扫描的情况，避免过度索引导致写操作性能下降。此外，应考虑使用覆盖索引，即索引包含查询所需的所有列，以减少回表操作。
在实际操作中，使用数据库设计工具如PowerDesigner可以提高设计效率和质量。PowerDesigner支持创建ER模型、逆向工程现有数据库、生成SQL脚本等功能，是设计过程中的得力助手。
回到案例，T_ORDER_ITEM表的外键ORDER_ID上的索引IDX_ORDER_ITEM_ORDER_ID是为了快速查找关联的订单信息。但是否需要在每个外键上都建立单独索引，需要结合查询模式评估。如果多数查询都涉及订单条目与订单的关联，考虑使用索引联接（Index-Nested Loop Join）可能更为合适。
优化Oracle库表设计涉及多方面因素，包括数据表达、物理存储、索引策略以及工具使用。通过深入理解业务需求、数据库原理和性能优化技巧，我们可以创建更高效、更适应业务发展的数据库结构。
