Re: [I] In the case of multiple data sources, if the same table name exists in different data sources, the loading and overwriting of table names and routing errors may occur [shardingsphere]

["terrymanu (via GitHub)" <gi...@apache.org>]

terrymanu commented on issue #34088:
URL: https://github.com/apache/shardingsphere/issues/34088#issuecomment-3536718853

   Analysis Conclusion: This is not a code defect in ShardingSphere, but rather a misunderstanding of ShardingSphere's design philosophy.
   
   ##  ShardingSphere Design Philosophy
   
     ShardingSphere's core design goal is to enable users to use distributed databases as if they were using a single database. Under this design philosophy:
   
     1. Unified Table Space: One logical database should have a unified table name space
     2. Handling Same-Named Tables: Tables with the same name across different data sources should be treated as sharded tables, not independent single tables
   
   ##  Root Cause Analysis
   
     The current configuration violates ShardingSphere's fundamental design principles:
     - Incorrectly configuring same-named tables from different data sources as single tables
     - Expecting to independently access same-named tables within the same logical database
   
   ##  Correct Solutions
   
     Option 1: Configure as Sharded Tables (Recommended)
   
   ```yaml
     spring:
       shardingsphere:
         rules:
           sharding:
             tables:
               t_user:  # Unified logical table name
                 actual-data-nodes: ds0.t_user, ds1.t_user
                 table-strategy:
                   standard:
                     sharding-column: user_id
                     algorithm-expression: t_user_${user_id % 2}
             default-database-strategy:
               standard:
                 sharding-column: user_id
                 algorithm-expression: ds${user_id % 2}
   ```
   
     Option 2: Use Different Logical Table Names
     If you truly need independent access for business reasons, use different logical table names:
   
   ```yaml
     spring:
       shardingsphere:
         rules:
           sharding:
             tables:
               user_ds0:  # User table in ds0
                 actual-data-nodes: ds0.user
               user_ds1:  # User table in ds1  
                 actual-data-nodes: ds1.user
   ```
   
   ##  Configuration Recommendations
   
     Please choose the appropriate configuration based on your business requirements:
   
     1. If data needs horizontal sharding → Use sharded table configuration
     2. If data is completely independent → Use different logical table names
     3. If cross-datasource access is needed → Consider using different logical databases
   
   ##  Conclusion
   
     ShardingSphere is designed to provide a transparent distributed database experience, not to manage multiple independent databases. Same-named tables within the same logical database should be managed uniformly through
     sharding rules, not exist as independent single tables.
   
     We recommend revisiting your data architecture design and choosing a configuration approach that aligns with ShardingSphere's design philosophy.
   
   


-- 
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.

To unsubscribe, e-mail: notifications-unsubscribe@shardingsphere.apache.org

For queries about this service, please contact Infrastructure at:
users@infra.apache.org