Bonne pratique pour DB Schema dans Ruby on Rails

Question

Je suis un programmeur PHP depuis plus d'une décennie et je suis passé à RoR. Voici ce que je suis habitué du monde PHP:

1. Créer un schéma DB dans un outil comme MySQL WorkBench - et rendre les champs précisément la taille que je veux sans perdre de l'espace (par exemple varchar (15) si elle est adresse IP). Ecrivez des modèles en utilisant Datamapper et placez ces longueurs exactes de champs et ces spécifications afin que mon application n'essaie pas de mettre des valeurs plus grandes.

Dans le monde RoR de ce que j'ai vu au cours des deux derniers jours, cela semble être le flux suggéré:

1. Ajouter des champs/schéma en utilisant la ligne de commande qui crée une migration script et apparemment créé de grands champs ass (par exemple "ip_address string" fait probablement le champ varchar (255) dans la base de données quand j'exécute la migration).

2. Mettre en validation lors de la création du modèle.

Est-ce qu'il me manque quelque chose ici? Quel est le processus dans le monde RoR pour les applications de niveau entreprise où vous voulez réellement créer un schéma hautement personnalisé? Dois-je écrire manuellement des scripts de migration?

Answer 1

L'échafaudage est ce que vous utilisez pour démarrer rapidement. Mais avant d'exécuter la migration, vous pouvez l'éditer et ajouter des contraintes et des longueurs de colonnes spécifiques.

Les validations spécifiées dans le modèle (dans le code ruby) ne présentent pas le même niveau de sécurité que les validations/contraintes spécifiées dans la base de données. Vous devez donc toujours définir ceux sur la base de données.

Bien qu'il soit possible de travailler avec Rails sans migrations, je déconseille fortement de le faire. Dans certains cas, il ne peut pas être évité (lorsque vous travaillez avec des bases de données existantes par exemple). Le plus grand avantage de l'utilisation des migrations est que votre schéma de base de données, sur différentes plates-formes, peut être synchronisé à travers différentes étapes. Par exemple. votre développement et votre base de données de production. Lors du déploiement de votre code, les migrations veilleront à ce que la base de données soit migrée correctement.

Answer 2

Vous pouvez modifier les scripts de migration avant d'exécuter la migration afin de personnaliser les champs.

Answer 3

Oui, si vous devez modifier les valeurs par défaut, vous devez modifier les scripts de migration.

Notez également que vous n'avez pas besoin pour utiliser les migrations, ils sont un "confort" lors de l'itération par le développement DB. Il n'y a rien qui dise que vous devez les utiliser. Le modèle d'enregistrement actif ne dépend pas de la façon dont les tables/champs/DB. sont créés ou définis. Par exemple, les migrations sont inutiles lorsqu'il s'agit de bases de données héritées, mais vous pouvez toujours écrire une application Rails autour d'elles.