Ich bin neu bei Laravel, also ein bisschen neu in Bezug auf die Best Practices dieses Frameworks. Ich versuche zu verstehen, wie ich am besten an die Erstellung einer Datenbank herangehen kann Migrationen.
Die wenigen Beispiele, die ich im Internet gefunden habe, einschließlich der Laravel-Dokumentation hier und hier, scheinen sich auf Migrationsskripte zu beziehen, die nur eine Tabelle verarbeiten. Ich erstelle eine Anwendung mit etwa 10 Tabellen, die alle mit Fremdschlüsseln miteinander verbunden sind, einige mit Viele-zu-Viele-Beziehungen.
-
Ist der empfohlene Ansatz, eine Migrationsdatei pro Tabelle zu haben? Wenn ja warum? (Welche Nachteile hat es, wenn überhaupt, alle Skripts zur Tabellenerstellung in einer Datei abzulegen?)
-
Was ist mit Fremdschlüsseln und Beziehungen? Wie erzwingt man diese Beziehungen und die Reihenfolge, in der Migrationen so ausgeführt werden, dass, wenn Tabelle1 auf eine Spalte in Tabelle2 verweist, Tabelle2 vor Tabelle1 erstellt wird?
-
Was ist mit Many-to-Many-Beziehungen? Muss die Beziehungstabelle (Pivottabelle) auch manuell über ein separates Migrationsskript erstellt werden? Wenn ja, was stellt sicher, dass es nach den 2 verwandten Tabellen erstellt wird?
Während der Entwicklung Ihrer Anwendung sollten Sie sich meiner Meinung nach nicht allzu sehr darum kümmern, nur eine Tabelle pro Migration zu haben. Manchmal ist es einfach einfacher, einige Tabellen in einer einzigen Migration zusammenzufassen, aber sobald Ihr System in die Produktion geht, werden Sie es nicht sein in der Lage, so weiterzuarbeiten, da Sie nur in der Produktion migrieren und wahrscheinlich nie ein Rollback durchführen, sodass Ihre Migrationen sehr klein sein werden, manchmal müssen Sie eine Migration für eine einzelne Spaltenerstellung durchführen.
Die Vorteile des Einfügens von Tabellen in verschiedene Migrationen sind die gleichen wie bei einer dünnen Klasse. Je weniger Informationen Sie in einer Datei haben, desto einfacher ist es, sie zu verwalten und Änderungen daran vorzunehmen. Wenn Sie also alle Tabellen in eine einzige Migration packen, wird die Wartung schwieriger, aber das liegt wirklich an Ihnen.
Fremdschlüssel sind ein gutes Beispiel dafür, warum Sie eine Migration pro Tabelle und sogar pro Fremdschlüssel erstellen sollten: Jedes Mal, wenn Sie eine Tabelle im Zusammenhang mit Fremdschlüsseln zurücksetzen, müssen Sie zuerst alle Fremdabhängigkeiten löschen, deshalb erstellt Laravel eine Migration sie alle in der gleiche Reihenfolge, es hilft Ihnen, niemals einen Tisch fallen zu lassen. Erstellen Sie also zuerst Ihre Tabellenmigrationen und dann Ihre Fremdschlüsselmigrationen. Wenn Sie also ein Rollback durchführen, werden zuerst die Einschränkungen und dann die Tabellen zurückgesetzt.
Ich erstelle Fremdschlüssel für eine Tabelle in derselben Migration dieser Tabelle, es sei denn, ich habe zu viele Fremdschlüssel. Aber ich erstelle immer einen Fremdschlüssel in einem separaten Schema::table() Befehl, da einige Datenbanken Sie benötigen, um die Spalte zu haben, bevor Sie die Einschränkung daran anhängen:
public function up()
{
Schema::create('statuses', function(Blueprint $table)
{
$table->string('id', 64)->primary();
$table->string('user_id', 64)->index();
$table->text('body');
$table->timestamps();
});
Schema::table('statuses', function(Blueprint $table)
{
$table->foreign('user_id')
->references('id')
->on('users')
->onUpdate('cascade')
->onDelete('cascade');
});
}
Ungefähr viele zu viele, wenn Sie die Tabelle und die Fremdschlüssel zusammen erstellen, sollten Sie zuerst die Master- und dann die Pivot-Tabellen erstellen, aber wenn Sie Ihre Fremdschlüssel in separaten Migrationen erstellen, erstellen Sie zuerst die Tabellen (Reihenfolge spielt keine Rolle, aber es ist auch besser, in diesen Fällen organisiert zu sein) und dann die Migrationen für die Fremdschlüssel.
Während der Entwicklung nehme ich viele Änderungen an meinen Tabellen vor, also komme ich immer wieder darauf zurück, also mache ich das, wenn ich eine Migration ändere:
1) php artisan migrate:reset viele Male
2) Migration ändern
3) php artisan migrate
Wenn ich nur eine neue erstelle, habe ich normalerweise keine Probleme, da Migrationen normalerweise idepotent sind.
Ihre letzte Frage wurde bereits beantwortet, aber ich sage es noch einmal: Laravel benennt die Migrationsdateien mit Zeitstempeln, so wie Sie niemals eine Migration ausführen müssen, bevor eine andere davor erstellt wurde:
2014_07_16_190821_create_statuses_table
Und der Name der Migrationsangelegenheit, denn dieser oben wird diese Klasse erstellen:
CreateStatusesTable
Eine Sache, die Sie also tun müssen, ist, jede Migration mit einem anderen Namen zu erstellen, sonst werden Sie am Ende zwei Klassen mit demselben Namen haben und nicht Laravel, sondern PHP wird sich darüber beschweren.
