Beim Thermocook-Portal treffen zwei Welten aufeinander: die Geräte-Telemetrie schreibt in die eine Datenbank, das Shop-System liest aus einer anderen. Laravel kann das von Haus aus — man muss nur ein paar Dinge bewusst entscheiden, sonst rächt es sich im Test.
Zwei Connections, klar benannt
Beide Verbindungen werden in `config/database.php` definiert und sprechend benannt. Models bekommen ihre Connection explizit — Raten ist keine Strategie.
class DeviceReading extends Model
{
protected $connection = 'telemetry';
}
class ShopOrder extends Model
{
protected $connection = 'shop';
}Migrations wissen, wohin sie gehören
Jede Migration legt fest, auf welcher Connection sie läuft. Sonst landet die halbe Telemetrie-Struktur in der Shop-DB und niemand findet sie wieder.
Schema::connection('telemetry')->create('device_readings', function (Blueprint $t) {
$t->id();
$t->string('device_serial')->index();
$t->json('payload');
$t->timestamps();
});Der wunde Punkt: Tests
Eloquent kann nicht über zwei Connections joinen — das ist keine Schwäche, sondern eine Designgrenze. Beziehungen über die DB-Grenze hinweg löst man in der Anwendung, nicht in SQL. Und in den Tests müssen beide Connections migriert werden, sonst laufen sie grün, obwohl die zweite DB leer ist.
- Connections explizit auf Models und Migrations setzen
- Cross-DB-Joins vermeiden — Beziehungen in der App auflösen
- In Tests beide Connections migrieren und seeden