Home Explore Help
Sign In
heyw
/
TugboatAIRebuild
1
0
Fork 0
Files Issues 0 Pull Requests 0 Wiki
Tree: 5e94ed188c
Branches Tags
TugboatAIReb...
/
.trae
/
skills
/
db-table-analyzer
/
SKILL.md

SKILL.md 4.1 KB
History Raw

name: "db-table-analyzer"

description: "Analyzes database tables for read/write separation rules. Identifies which tables exist in both tugboatcommon and liandatugboatmis databases and need read/write separation. Invoke when checking or fixing data source configurations."

Database Table Analyzer

This skill helps identify which tables need data source separation based on the FlinkDataSync configuration and actual database architecture.

Database Architecture

  • tugboatcommon: System common library, stores data shared by all institutions
  • liandatugboatmis: Branch institution business library, stores business data for individual institutions

This is not a simple read/write separation but rather a distinction between public/shared data and institutional business data.

Tables That Exist in Both Databases

Based on FlinkDataSync's tableList configuration, the following tables exist in both tugboatcommon and liandatugboatmis databases and need proper data source routing:

Dispatch Tables (Disp_*)

  • Disp_Port - Port information
  • Disp_PortDictionary - Port dictionary
  • Disp_Tugboat - Tugboat information
  • Disp_DeepLevel - Deep level information
  • Disp_Berthage - Berthage information
  • Disp_BerthageDictionary - Berthage dictionary
  • Disp_Pilot - Pilot information
  • Disp_Tugboatowner - Tugboat owner information
  • Disp_Waterway - Waterway information

Business Tables (Bus_*)

  • Bus_Holiday - Holiday information
  • Bus_ShipPaymentType - Ship payment types
  • Bus_ShipPaymentType_ShipType - Relationship between ship payment types and ship types

Financial Tables (Fin_*)

  • Fin_AssistCode - Financial assist codes
  • Fin_AssistCodeItem - Financial assist code items
  • Fin_Subject - Financial subjects
  • Fin_Subject_AssistCode - Relationship between financial subjects and assist codes
  • Fin_TaxRule - Tax rules

Process Tables (Pro_*)

  • Pro_FeeItemAssistCode - Fee item assist codes
  • Pro_FeeItemSettings - Fee item settings

Salary Tables (Sal_*)

  • Sal_Holiday - Salary holiday information
  • Sal_SocialInsuranceStandard - Social insurance standards
  • Sal_TaxLevel - Tax levels

Tugboat Tables (Tug_*)

  • Tug_Certificate - Certificate information

Tables That Exist Only in One Database

Tables that exist only in one database and should use the appropriate data source:

Customer Business Tables (exist in liandatugboatmis - branch business data)

  • Bus_CustomerCompany - Customer company information
  • Bus_CustomerCompanyBusiness - Customer company business relationships
  • Bus_Customer_CustomerType - Customer types
  • Bus_Ship - Ship information

System Tables (typically exist in tugboatcommon - common data)

  • Sys_Menu - System menus
  • Sys_User - System users
  • Sys_DictionaryItem - System dictionary items

Implementation Guidelines

  1. For tables that exist in both databases:

    • Use @DataSource(RoutingDataSourceConfig.DataSourceType.COMMON) for common/shared data operations (tugboatcommon - system common library)
    • Use @DataSource(RoutingDataSourceConfig.DataSourceType.BRANCH) for branch-specific operations (liandatugboatmis - branch institution business library)

  2. For tables that exist only in liandatugboatmis (branch business data):

    • Use @DataSource(RoutingDataSourceConfig.DataSourceType.BRANCH) consistently
    • This applies to customer, ship, and business-related tables

  3. For tables that exist only in tugboatcommon (common data):

    • Use @DataSource(RoutingDataSourceConfig.DataSourceType.COMMON) consistently
    • This applies to system configuration tables

Naming Convention

The new naming convention clearly reflects the database architecture:

  • COMMON → tugboatcommon: System common library, stores data shared by all institutions
  • BRANCH → liandatugboatmis: Branch institution business library, stores business data for individual institutions

This eliminates confusion compared to the previous READ/WRITE naming that suggested a simple read/write separation.

Validation

Always verify that the @DataSource annotations align with the actual database architecture and business requirements.