Un modèle de données de livraison de restaurant

Vous avez faim mais vous ne voulez pas cuisiner ? Appelez un restaurant, commandez votre repas préféré et découvrez un modèle de données capable d'organiser l'ensemble du processus.

Malgré une abondance de technologies « permettant de gagner du temps », nous semblons avoir moins de temps pour satisfaire nos besoins de base, comme manger. Si nous voulons manger quelque chose mais que nous n'avons pas le temps (ou les compétences) pour le cuisiner nous-mêmes, nous pouvons commander de la nourriture dans un restaurant (c'est-à-dire un plat à emporter ou à emporter), qui apportera nos repas directement à nos portes. Bien sûr, nous devons payer pour cette commodité, alors nous nous attendons à ce que la nourriture soit bonne et chaude !

De toute évidence, tout restaurant est motivé pour satisfaire ses clients. Vous pourriez être surpris d'apprendre la quantité de travail nécessaire à la gestion d'un plat à emporter. La plupart utilisent un certain type de système de suivi pour gérer les commandes et les livraisons. Examinons le modèle de données sous un tel système. Prenez une collation, asseyez-vous et profitez de l'article.

Que devons-nous savoir sur le secteur de la restauration ?

Faire de la nourriture et la livrer aux clients n'est pas facile. Tout d'abord, vous devez avoir du talent et des connaissances pour préparer de délicieux repas. Il faut aussi être organisé :tout doit fonctionner parfaitement pour que ces repas soient livrés à temps et au bon endroit !

Avant de commencer à livrer des repas, nous devons savoir :

Qui a commandé le repas
Où et quand le repas doit être livré
Quels plats sont inclus dans la commande
De quels ingrédients avons-nous besoin pour exécuter la commande
Si la commande a déjà été payée

Nous devons également suivre les statuts de livraison et enregistrer les commentaires des clients sur leur repas et/ou notre processus de livraison. De plus, nous voulons peut-être savoir quels plats sont les plus (ou les moins) populaires. Et nous devons également conserver certaines informations financières à des fins de reporting et d'analyse.

Supposons que nous ayons une application que nos clients peuvent utiliser pour passer des commandes à livrer. Il leur permet de choisir des éléments de menu, de les payer et de spécifier une heure et une adresse de livraison. À quoi pourrait ressembler le modèle de données sous une telle application ?

Le modèle de données

Vous pouvez ouvrir ce modèle dans votre navigateur en cliquant sur Edit model in your browser bouton.

Le modèle de données se compose de trois domaines :

Restaurants & customers
Menus
Orders

Nous présenterons chaque domaine dans l'ordre dans lequel il est répertorié.

Restaurants et Clients

Les Restaurants & customers Le domaine contient trois tableaux qui stockent des détails sur nos restaurants (il peut y en avoir plusieurs), les villes où nous opérons et nos clients.

Les clients et les restaurants sont situés dans les villes (ou villes, villages, etc.). Par conséquent, nous avons besoin d'une city dictionnaire. Il ne contient que deux attributs, city_name et zip_code . Si nous opérons dans plus d'un pays, nous aurions également besoin d'un dictionnaire de pays qui serait lié à ce tableau, mais nous n'aborderons pas cela ici.

Ensuite, nous avons besoin d'une liste de tous les restaurants que nous exploitons. Nous utiliserons le restaurant tableau pour cela. Pour simplifier les choses, nous ne conserverons que l'address de chaque restaurant et une référence à la city où il se trouve.

Le dernier tableau de ce domaine est le customer table. C'est là que nous stockerons une liste de tous nos clients de livraison enregistrés. Nous utiliserons les données de ce tableau pour lier les clients à leurs commandes plus tard dans le modèle. Bien sûr, les clients n'ont pas besoin d'être enregistrés dans notre modèle pour passer une commande, mais nous avons toujours besoin de cette liste. Nous pourrions offrir des rabais aux clients enregistrés dans le cadre d'un programme de fidélité. Ou peut-être utiliserions-nous ces données pour contacter les clients avec des offres spéciales. Pour chaque client enregistré, nous stockerons :

customer_name – Le nom complet du client.
city_id – Référence la city où habite le client.
address – L'adresse du client.
contact_phone – Le numéro de téléphone du client.
email – L'adresse e-mail utilisée par le client lors du processus d'inscription.
confirmation_code – Un code de confirmation utilisé lors du processus d'inscription.
password – Le mot de passe sélectionné par le client pour cette application.
time_joined – Un horodatage du moment où le client a rejoint notre application.

Menus

Cette rubrique contient des informations sur les menus de nos restaurants. Pour l'instant, supposons que tous nos restaurants utilisent le même menu.

Le premier tableau est la category dictionnaire. Il contient un seul attribut UNIQUE, category_name . Ce champ contiendra probablement les catégories de menu habituelles, telles que « boissons », « entrées », « salades », « sandwichs », « pizza », etc.

Ensuite, nous avons le menu_item table. Il répertorie tous les éléments que nous avons (ou avions) sur l'un de nos menus. Pour chaque article, nous stockerons :

item_name – Un nom pour cet élément, par ex. "sandwich au poulet".
category_id – Fait référence à la category auquel l'article appartient, par ex. "sandwichs".
description – Une description de cet article. Cela devrait être le même que sur le menu imprimé.
ingredients – Les ingrédients utilisés pour produire cet article et leurs quantités. Ce champ pourrait en fait stocker une recette.
price – Le prix actuel d'un article (par exemple, un sandwich au poulet).
active – Si l'élément est proposé dans le menu actuel.

Si nous voulons stocker des menus dans plusieurs langues, nous devons utiliser une approche comme celle présentée dans cet article.

La plupart des restaurants proposent des offres spéciales à durée limitée. Ils peuvent également avoir des offres pour une durée illimitée. Nous utiliserons l'offer tableau pour ceux-ci. Pour chacun, nous aurons :

date_active_from et date_active_to – Ensemble, ils définissent quand cette offre est active. Si une offre a une durée illimitée ou si elle est basée sur des heures plutôt que sur des jours, ces deux attributs contiendront des valeurs NULL. Un exemple de ce type d'offre est "Pendant le mois de mars, achetez un curry et obtenez-en un à 50 %".
time_active_from et time_active_to – Définit l'heure de la journée à laquelle une offre est valide – par ex. "Obtenez un café gratuit de 6h à 9h tous les jours".
offer_price – Le prix de cette offre.

Tous les éléments de menu inclus dans les offres sont stockés dans le in_offer table. Cette table contient la paire UNIQUE de offer_id – menu_item_id .

Si nos restaurants ont des menus différents, nous devons créer un menu séparé pour chaque restaurant. Nous aurions alors besoin de relier les menus et les offres aux restaurants utilisant des clés étrangères. Cela nous permettrait de modifier les menus et les offres de n'importe quel restaurant sans impacter les autres. Cela ne compliquerait pas seulement la base de données; le modèle économique deviendrait également plus complexe. C'est pourquoi la plupart des chaînes de restaurants s'en tiennent à un seul menu et pourquoi j'ai décidé de ne pas utiliser cette méthode dans ce modèle.

Commandes

Le dernier domaine de notre modèle est les Orders Domaine. C'est là que nous aurons tout le nécessaire pour stocker les commandes et leurs statuts.

La table centrale ici est le placed_order table. Il est préférable de ne pas utiliser uniquement "commande" comme nom de cette table :"commande" est un mot-clé SQL. Essayez d'éviter d'utiliser des mots-clés comme noms de tables et de colonnes; sinon, vous risquez d'obtenir des erreurs lors de l'écriture des requêtes. Pour chaque commande, nous enregistrerons :

restaurant_id – L'identifiant du restaurant lié à cette commande.
order_time – Un horodatage du moment où la commande a été passée.
estimated_delivery_time – Un horodatage de la livraison prévue de cette commande.
food_ready – Un horodatage indiquant quand les articles de la commande ont été préparés. Celui-ci contiendra une valeur NULL jusqu'à ce que la nourriture soit préparée. Nous pourrions utiliser cet attribut pour calculer la différence de temps entre le moment où la commande a été passée et le moment où la nourriture a été préparée. Nous pourrions également l'utiliser pour savoir combien de temps s'est écoulé entre le moment où la nourriture était prête et sa livraison. Ces informations peuvent être très utiles pour accroître l'efficacité du personnel.
actual_delivery_time – Un horodatage du moment où cette commande a été réellement livrée. Il sera NULL jusqu'à ce que la nourriture soit livrée au client.
delivery_address – L'adresse où la commande doit être livrée.
customer_id – L'identifiant du customer qui a passé cette commande. Cet attribut peut contenir une valeur NULL si la commande a été passée par quelqu'un qui n'est pas un utilisateur enregistré de l'application.
price – Le prix de tous les articles inclus dans cette commande.
discount – Le montant de la remise (par exemple, coupon ou remise de fidélité) appliqué au prix, le cas échéant.
final_price – Le prix de la commande moins la remise.
comment – Commentaires supplémentaires insérés par le client lors de la passation de la commande. Il peut s'agir d'instructions de livraison supplémentaires ou de tout autre élément que le client juge important.
ts – Un horodatage du moment où cet enregistrement a été inséré dans la table.

Le in_order Le tableau répertorie tous les articles ou offres spéciales inclus dans une commande. Pour chaque enregistrement de cette table, nous stockerons :

placed_order_id – L'identifiant de la order .
offer_id – Fait référence à l'offer tableau, mais uniquement lorsqu'une ou plusieurs offres sont incluses dans cette commande. Dans ce cas, le menu_item_id l'attribut sera NULL.
menu_item_id – Référence le menu_item table, mais uniquement si cet enregistrement est lié à un élément de menu et non à une offre.
quantity – Combien d'offres ou d'éléments de menu sont inclus dans cette commande.
item_price – Le prix d'une seule offre ou d'un élément de menu.
price – Le prix total pour cette ligne, exprimé sous la forme item_price * quantity .
comment – Tout commentaire inséré par le client qui se rapporte spécifiquement à cet article de commande, par ex. "Veuillez couper la pizza en 8 tranches".

Le comment table nous permet de prendre en charge l'insertion de plusieurs commentaires liés aux commandes. Pour chaque commentaire, nous enregistrerons l'identifiant de la commande associée et l'identifiant du client. Nous stockerons également un horodatage du moment où ce commentaire a été saisi. Nous indiquerons également si ce commentaire était une plainte ou un compliment ; un seul de ces deux paramètres peut être défini à la fois. Si aucun n'est défini, nous traiterons ce commentaire comme neutre.

Les deux dernières tables de notre modèle sont liées aux statuts que nous attribuerons aux commandes. Le status_catalog table contient une liste de tous les status_name UNIQUES possibles attributs que nous pourrions attribuer aux commandes. Le order_status table contient tous les statuts qui sont affectés aux commandes. Pour chaque enregistrement de cette table, nous stockerons les clés étrangères liées à la commande et au statut, ainsi que l'horodatage auquel ce statut a été attribué.

Que pensez-vous du modèle de données de livraison des restaurants ?

Aujourd'hui, nous avons discuté d'un modèle de données qui pourrait être utilisé pour organiser, gérer et stocker les commandes de livraison des restaurants. Nous pouvons suivre l'état de chaque commande et certains détails financiers. J'ai quelques idées sur la façon dont nous pourrions rendre ce modèle plus robuste, mais je serais heureux d'entendre votre opinion. Veuillez le partager dans la section des commentaires !