Commandes récurrentes

Question

Salut tout le monde Je travaille sur un projet d'école, et pour mon projet j'ai choisi de créer un système de commerce électronique capable de traiter les commandes récurrentes. C'est pour mon projet final, je serai diplômé en mai avec un associé en informatique. Gardez à l'esprit que ce n'est pas une solution finale et qu'il s'agit essentiellement d'un point de départ pour la conception de cette base de données.

Un peu de fond sur les processus d'affaires.
- Le client commandera un produit et indiquera lors de la commande s'il s'agit d'une commande unique ou d'une commande hebdomadaire/mensuelle.
- Le client spécifiera un lieu où récupérer sa commande (cet emplacement est spécifique à la commande uniquement)
- Si la valeur de la commande> 25.00 est acceptée, sinon elle est rejetée.
- Cela renseignera les orders_test et tables order_products_test respectivement

• personne à l'arrière aura un rapport généré pour les livraisons pour la journée à partir de ces deux tables.
• Ils seront en mesure de l'imprimer et il va générer une liste des éléments qui vont à quel endroit. Basé sur les critères suivants.
• date_of_next_scheduled_delivery = date
• de remaining_deliveries> 0
• Une fois qu'ils sont satisfaits de la liste de distribution, ils appuyez sur le bouton "Les livraisons de process".
• Permet de régler la table order_products_test comme suit
• Soustraire 1 de remaining_deliveries
• Date d'insertion actuelle dans date_of_last_delivery_processed
• Basé sur delivery_frequency (une fois, hebdomadaire, mensuel), il va changer la date_of_next_scheduled_delivery
• valeurs d'état dans la table order_products_test peut être soit active, soit en attente, soit annulée, expirée

Je voudrais juste quelques opinions si je suis proche g correctement ou si je devrais gratter cette approche et recommencer à zéro.

Answer 1

Quelques pensées, mais pas nécessairement complète (il y a beaucoup à votre question, mais nous espérons que ces points de l'aide):

• Je ne pense pas que vous devez garder une trace des livraisons restantes. Vous n'avez que 2 options: une commande unique ou une commande récurrente. Dans les deux cas, cela n'a aucun sens de calculer les livraisons restantes. Ce n'est jamais mis à profit.

• En ce qui concerne le suivi de la prochaine date de livraison, vous pouvez simplement garder une trace du jour de la commande. Si c'est récurrent - mensuel ou hebdomadaire, indépendamment - tout est calculable à partir de cette première date. La plupart des systèmes de base de données (MySQL, SQL Server, Oracle, etc.) supportent une flexibilité de calcul des dates plus que suffisante pour que vous puissiez les calculer à la volée, plutôt que de maintenir un tel calendrier connu.Si le lieu de livraison est uniquement spécifique à la commande, je ne vois pas l'utilité de créer une table distincte pour cette commande. Elle dépend de la commande, vous devez la conserver dans la même table que la commande. Pour la plupart des systèmes de commerce électronique, ce n'est pas le cas car ils ont tendance à associer une liste d'emplacements de livraison à des comptes, qu'ils vous indiquent lorsque vous en commandez plusieurs (par exemple, Amazon).

• Compte tenu de ce qui précède, je parie que vous pouvez juste sortir avec 2 de vos 4 tableaux ci-dessus - et compte Ordre. Mais encore une fois, si les lieux de livraison sont associés à des comptes, je le ferais en effet. (Mais votre question ci-dessus ne suggère pas que)

• Ne pas nommer vos tables avec un suffixe « _test » - il est source de confusion.