Sequelize ma wiele, należy do lub oba?

Korzystanie z belongsTo definiuje własność powiązanych modeli. Aby wyjaśnić to bardziej szczegółowo, odwołam się do przykładu przytoczonego z samouczków

Project.hasMany(Task);
Task.belongsTo(Project);

Załóżmy, że nie interesują Cię już zadania usuniętego projektu. W takim przypadku musiałbyś usunąć zadania ręcznie, gdybyś nie zdefiniował belongsTo stowarzyszenie. belongsTo ustanawia własność projektów nad swoimi zadaniami, a baza danych automatycznie usuwa również zadania należące do usuniętego projektu. Nazywa się to cascading delete i może łączyć wiele tabel.

Jeśli uruchomisz następujący fragment kodu

const Project = sequelize.define('project', {
    name: Sequelize.STRING
});
const Task =  sequelize.define('task', {
    name: Sequelize.STRING
});
Project.hasMany(Task);
Task.belongsTo(Project);

w skrypcie sequeli i obejrzyj wynik

Executing (default): DROP TABLE IF EXISTS `projects`;
Executing (default): CREATE TABLE IF NOT EXISTS `projects` (`id` INTEGER PRIMARY KEY AUTOINCREMENT, `name` VARCHAR(255), `createdAt` DATETIME NOT NULL, `updatedAt` DATETIME NOT NULL);
Executing (default): PRAGMA INDEX_LIST(`projects`)
Executing (default): DROP TABLE IF EXISTS `tasks`;
Executing (default): CREATE TABLE IF NOT EXISTS `tasks` (`id` INTEGER PRIMARY KEY AUTOINCREMENT, `name` VARCHAR(255), `createdAt` DATETIME NOT NULL, `updatedAt` DATETIME NOT NULL, `projectId` INTEGER REFERENCES `projects` (`id`) ON DELETE SET NULL ON UPDATE CASCADE);

zauważysz zachowanie kaskadowe ustawione podczas tworzenia tabeli zadań.

Tak dużo powiedziane, ostateczna odpowiedź brzmi:to zależy. Użycie belongsTo może się bardzo przydać lub będzie fatalne w skutkach, jeśli wolisz zachować zadania usuniętego projektu. Używaj tylko belongsTo jeśli ma to sens w kontekście Twojej aplikacji.