Best Practices for Database and Table Name Specification Validation

Task Objectives

• Verify whether database names and data table table names comply with team specifications
• Support automatic modification of table names in files (default behavior)
• Only applicable to the names of databases and data tables, not involving table field naming

Database Naming Specifications

Format Requirements

• Use lowercase letters exclusively
• Separate different semantic segments with underscores (_)
• Naming length: Controlled within 2-4 semantic segments

Core Principles

• Concise and expressive: Directly reflect the business affiliation or purpose of the database
• Avoid redundancy: Do not include meaningless abbreviations or duplicate characters

Data Table Naming Specifications

Note: Only validates the table name of data tables, not involving column/field naming.

Format Requirements

• Basic structure: "Adjective + Noun (plural form)"
• Use lowercase letters exclusively
• Separate different semantic segments with underscores (_)
• The last noun must be in English plural form

Core Principles

• Adjective: Reflects the business attribute or scope of the table (e.g.,

  user

  ,

  order

  ,

  system

  )
• Noun: Reflects the core data object stored in the table, must be in plural form
• Self-explanatory: The overall meaning is clear, avoiding meaningless abbreviations
• Length control: Controlled within 3-4 semantic segments

Supplementary Rules

• Single noun expansion: For detailed rules, see references/english-plural-rules.md
• Avoid overly long names:

  user_order_addresses

  is acceptable, while

  user_order_shipping_receive_addresses

  needs simplification
• Common errors and corrections: See references/common-errors.md

File Naming Specifications (Drizzle ORM Files)

database_table_name + _table

• The database table name must comply with table name specifications (plural, lowercase, underscores)
• The table name in the file name must match the table name in the

  pgTable()

  function

• users_table.ts

  →

  pgTable("users", {...})

• user_profiles_table.ts

  →

  pgTable("user_profiles", {...})

Validation Process

Single Naming Validation

Batch Naming Review

File Naming Validation and Correction

1. Identify user intent and context (priority: file/folder path → active search → only check)
2. Locate or read the file
3. Validate the file name (for table definition files such as Drizzle ORM)
4. Identify and validate the table name
5. Determine whether to modify
6. Execute modification (using

   edit_file

   ,

   limit=-1

   )
7. Validate results and output report

Resource Index

• Common Errors and Corrections: See references/common-errors.md (When to read: When encountering specific error types or needing correction solutions)
• Usage Examples: See references/usage-examples.md (When to read: When needing to refer to complete execution processes and examples)
• English Plural Rules: See references/english-plural-rules.md (When to read: When unsure about English plural forms)
• Best Practice Examples: See best-practice-examples/ (When to read: When needing to refer to Drizzle ORM best practice code examples)

Notes

• Scope of Application: Only validates the names of databases and data tables, not involving table field naming
• Default Behavior: When a file path is provided or the user asks "Does the database/table comply with specifications?", automatically perform modifications by default
• Check-Only Mode: When the user says "only check", "only suggest", "do not modify", "don't change", etc. → Only check without modifying
• File Search Strategy:
  • If the user provides a file/folder path → Only process the specified one, do not actively search for other files
  • If the user does not provide a path → Use

    glob_file

    to actively search for relevant files
  • If the user provides a folder → Only search within that folder, do not recurse into subfolders (unless explicitly requested)
• File Modification Principles:
  • Use

    limit=-1

    to replace all matching items
  • Keep the original file format and indentation unchanged
  • Read before modification, validate after modification
  • Provide a detailed modification report including the file path

Usage Scenarios

• Table name validation before creating a new database/table
• Table name specification check during code review
• Specification explanation in team training
• Table name standardization during database refactoring
• Batch review of consistency of existing database and data table names
• Automatically modify table names in files (SQL files, configuration files, code files, etc.) — Default behavior
• Check only without modification (when explicitly requested by the user)