Question

Ce que je veux faire est très simple, mais j'essaie de trouver le moyen le plus élégant et le plus élégant de le faire. L'application Rails que je construis maintenant aura un horaire de cours quotidiens. Pour chaque classe, les champs pertinents pour cette question sont les suivants:

  • Jour de la semaine
  • Heure de début
  • heure de fin

Une seule entrée pourrait être quelque chose comme:

  • jour de la semaine: mercredi
  • heure de départ: 10h00
  • heure de fin: midi

Je dois également mentionner qu'il s'agit d'une application bilingue Rails 2.2 et que j'utilise la fonctionnalité native Rails i18n. J'ai en fait plusieurs questions.

En ce qui concerne le jour de la semaine, dois-je créer un tableau supplémentaire avec une liste de jours ou existe-t-il un moyen intégré de créer cette liste à la volée? Gardez à l'esprit que ces jours de la semaine devront être affichés en anglais ou en espagnol dans la vue de planification, en fonction de la variable de paramètres régionaux.

Lors de la consultation du calendrier, je devrai grouper et classer les résultats par jour de la semaine, du lundi au dimanche, et bien sûr, classer les cours pour chaque jour, en commençant à l’heure de début.

En ce qui concerne l'heure de début et l'heure de fin de chaque classe, utiliseriez-vous des champs date / heure ou des champs entiers? Si ce dernier, comment l’appliqueriez-vous exactement?

J'ai hâte de lire les différentes suggestions que vous formulerez.

Était-ce utile?

La solution

Je voudrais simplement stocker le jour de la semaine sous forme d’entier. 0 = > Lundi ... 6 = > Dimanche (ou comme vous le souhaitez. Par exemple: 0 = > dimanche). Enregistrez ensuite l'heure de début et l'heure de fin en tant qu'heure.

Cela rendrait le regroupement vraiment facile. Il vous suffit de trier le jour de la semaine et l'heure de début.

Vous pouvez l'afficher de plusieurs manières, mais voici ce que je ferais.

  1. Définissez des fonctions telles que: @sunday_classes = DailyClass.find_sunday_classes , qui renvoie toutes les classes de Sunday triées par heure de début. Répétez ensuite pour chaque jour.

    def find_sunday_classes
      find_by_day_of_week(1, :order -> 'start_time')
    end

    Remarque: find_by devrait probablement avoir un identifiant à la fin, mais il ne s'agit que d'une préférence dans la manière dont vous souhaitez nommer la colonne.

  2. Si vous voulez la semaine complète, appelez les sept à partir du contrôleur et passez-les en boucle dans la vue. Vous pouvez même créer des pages de détail pour chaque jour.

  3. La traduction est la seule partie délicate. Vous pouvez créer une fonction d'assistance qui prend un entier et retourne le texte du jour de la semaine approprié en fonction de local.

C'est très basique. Rien de compliqué.

Autres conseils

Si vos données sont une heure, je les enregistrerais en tant qu'heure - sinon, vous devrez toujours les convertir en dehors de la base de données lorsque vous effectuez des opérations liées à la date et à l'heure. Le jour est une donnée redondante, car elle fera partie de l’objet heure.

Cela devrait signifier que vous n’avez pas besoin de stocker une liste de jours.

Si t est une heure, alors

t.strftime('%A')

vous donnera toujours la journée sous forme de chaîne en anglais. Cela pourrait ensuite être traduit par i18n selon les besoins.

Il vous suffit donc de stocker l'heure de début et l'heure de fin, ou l'heure de début et la durée. Les deux devraient être équivalents. Je serais tenté de stocker moi-même l'heure de fin, au cas où vous auriez besoin de manipuler des données sur des heures de fin, qui n'auront donc pas à être calculées.

Je pense que la plupart du reste de ce que vous décrivez devrait également ne plus stocker de données temporelles en tant qu'instances de Time.

Pour commander par jour et par semaine, il vous suffira de commander par colonne de temps. c'est-à-dire

daily_class.find(:all, :conditions => ['whatever'], :order => :starting_time)

Le regroupement par jour est un peu plus délicat. Cependant, c'est un excellent article comment grouper par semaine. Le regroupement par jour sera analogue.

Si vous avez affaire à des volumes de données non triviaux, il peut être préférable de le faire dans la base de données, avec un find_by_sql et cela peut dépendre de la fonctionnalité d'heure et de date de votre base de données, mais là encore le stockage des données en tant que temps vous aidera également ici. Par exemple, dans Postgresql (que j’utilise), obtenir la semaine d’un cours est

date_trunc('week', starting_time)

que vous pouvez utiliser dans une clause Group By ou comme valeur à utiliser dans certaines logiques de boucles sur rails.

Re jours de la semaine, si vous avez besoin par exemple classes qui se rencontrent 09: 00-10: 00 sur MWF, alors vous pouvez soit utiliser une table séparée pour les jours où une classe se rencontre (saisie à la fois par ID de classe et DOW) ou être diabolique (c'est-à-dire non normalisée) et conserver l'équivalent d'un tableau de DOW dans chaque classe. L'argument classique est le suivant:

  • La table séparée peut être indexée de manière à prendre en charge les sélections orientées classe ou DOW, mais nécessite un peu plus de colle pour rassembler l’ensemble de l’image d’une classe.
  • Le tableau de DOW est plus simple à visualiser pour les programmeurs débutants et légèrement plus simple à coder, mais signifie que raisonner à propos de DOW nécessite d'examiner toutes les classes.

Si cela s’applique uniquement à votre horaire de cours personnel, faites ce qui vous donne la valeur que vous recherchez et en subissez les conséquences; si vous essayez de construire un vrai système pour plusieurs utilisateurs, j'utiliserais un tableau séparé. Toutes ces règles de normalisation sont là pour une raison.

En ce qui concerne les noms DOW (lisibles par l'homme), il s'agit d'un problème de couche présentation, qui ne devrait pas figurer dans le concept de base de DOW. (Supposons que vous décidiez de déménager à Montréal et que vous ayez besoin du français. Cela devrait être un autre visage et non pas une modification de la mise en œuvre principale.)

En ce qui concerne les heures de début et de fin, là encore, le problème concerne vos besoins. Si toutes les classes commencent et se terminent aux heures (x: 00), vous pouvez certainement utiliser 0..23 comme heure de la journée. Mais alors, votre vie serait misérable dès que vous auriez dû accueillir ce séminaire de 45 minutes. Comme le disait l'ancien message publicitaire, "payez-moi maintenant ou payez-moi plus tard".

Une approche consisterait à définir votre propre concept ClassTime et à partitionner tous les raisonnements sur les durées de cette classe. Il pourrait commencer par une représentation simpliste (heures intégrales 0. 23, ou minutes intégrales après minuit 0. 14 399), puis "grandir" au besoin.

Licencié sous: CC-BY-SA avec attribution
Non affilié à StackOverflow
scroll top