Raw PHP与Codeigniter项目合并及数据库表共享可行性咨询

Hey there! Totally get the confusion with your first project—combining different codebases can feel overwhelming at first, but yes, you absolutely can merge these two projects and share database tables between them. Let’s break this down into actionable steps and options that fit your situation:

This is the easiest part to tackle first, and it’s a great way to dip your toes into integration:

• Use a single database (if possible): If your Raw PHP merchant backend and CodeIgniter (CI) projects already use the same database server, you just need to configure CI to access the merchant tables directly.
• Multi-database setup (if separate): If they’re on different databases, add a second connection in CI’s application/config/database.php:

  $db['merchant_db'] = array(
      'hostname' => 'your_merchant_db_host',
      'username' => 'db_username',
      'password' => 'db_password',
      'database' => 'merchant_database_name',
      'dbdriver' => 'mysqli',
      'char_set' => 'utf8',
      'dbcollat' => 'utf8_general_ci',
      // Keep other default settings
  );
  

  Then load this connection in your CI models/controllers:

  $this->merchant_db = $this->load->database('merchant_db', TRUE);
  // Example query to get merchant data
  $shops = $this->merchant_db->get('merchant_shops')->result();
  

• Use CI’s features: Stick to CI’s Query Builder or Model classes for database operations—it’s safer, cleaner, and aligns with the framework’s structure, even when accessing external tables.

You have two solid options here, depending on how much refactoring you’re comfortable with:

Option 1: Migrate the Raw PHP Merchant Backend into CodeIgniter #

This is the long-term best choice—it unifies your entire project under one framework, making maintenance easier down the line. Here’s how to start:

• Start with core functions: Pick the simplest merchant feature first (like login or shop profile viewing) and rewrite it in CI’s MVC structure:
  • Move business logic into a CI Model (e.g., Merchant_model.php)
  • Create a Controller (e.g., Merchant.php) to handle requests
  • Convert Raw PHP HTML pages into CI View files (store them in application/views/merchant/)
• Configure routes: Update application/config/routes.php to point merchant URLs to your new CI controller, like:

  $route['merchant/login'] = 'merchant/login';
  $route['merchant/dashboard'] = 'merchant/dashboard';
  

• Test incrementally: After each migrated feature, test it thoroughly to ensure it works the same way as the Raw PHP version.

Option 2: Keep Separate Codebases but Integrate via Shared Database #

If you don’t want to rewrite the entire merchant backend right now, you can keep both projects running but share data:

• Sync user sessions (if needed): If merchants need to switch between the backend and CI portal without re-logging in, store sessions in a shared database table that both projects can access.
• Avoid duplicate code: Any shared logic (like validation for merchant data) should be centralized—either in a shared PHP file that both projects include, or move it to CI and have the Raw PHP backend call CI’s API endpoints (if you set one up).
• Note: This is a temporary fix—over time, having two separate codebases will lead to inconsistencies and extra work, so plan to migrate to Option 1 eventually.

Since this is your first project, take it slow and avoid overwhelm:

• Backup everything first: Make copies of both codebases and databases before making any changes—you don’t want to lose work if something breaks.
• Document as you go: Keep notes on which tables you’re sharing, which features you’ve migrated, and any quirks you encounter. This will save you time later when troubleshooting.
• Leverage CI’s built-in tools: Use CI’s form validation, session management, and security features instead of reinventing the wheel—they’re tested and secure.
• Ask for help when stuck: If you hit a specific roadblock (like session syncing or query errors), break it down into a specific question and reach out to communities for targeted help.

• Table naming mismatches: Raw PHP might use different naming conventions (e.g., MerchantShops vs. CI’s preferred merchant_shops). Just explicitly define the table name in your CI models with protected $table = 'MerchantShops';.
• Session conflicts: If both projects use sessions, ensure they use the same session name and storage method (database is best for shared sessions).
• Permission logic gaps: Don’t forget to carry over any access control from the Raw PHP backend to CI—make sure only authorized merchants can access their dashboard.

Don’t worry if it feels slow at first—your first project is all about learning. Take it step by step, test every part, and you’ll have a unified system before you know it!

内容的提问来源于stack exchange，提问作者Ani Shah