Un modèle de données de livraison d'épicerie

S'il existe un moyen de commander des courses en ligne, pourquoi ne pas l'utiliser ? Cet article examine le modèle de données derrière le système de livraison d'une épicerie.

Nous ressentons toujours une sensation particulière en cueillant quelque chose dans le jardin et en le préparant immédiatement - mais ce n'est pas quelque chose que nous pouvons faire souvent. Le rythme rapide d'aujourd'hui ne le permet pas. En fait, parfois, cela ne nous permet même pas d'aller au magasin pour «cueillir» nos courses. Il est donc logique de gagner du temps et d'utiliser une application pour commander ce dont nous avons besoin. Notre commande apparaîtra juste à notre domicile. Peut-être que nous n'aurons pas cette sensation spéciale de fraîcheur, mais il y aura de la nourriture sur notre table.

Le modèle de données derrière une telle application est le sujet de l'article d'aujourd'hui.

De quoi avons-nous besoin pour un modèle de données de livraison d'épicerie ?

L'idée de ce modèle est qu'une application (web, mobile, ou les deux) permettra aux clients enregistrés de créer une commande (composée de produits de notre boutique). Ensuite, cette commande sera livrée au client. Nous stockerons évidemment les données client et une liste de tous les produits disponibles pour cela.

Les clients peuvent passer plusieurs commandes comprenant différents articles en différentes quantités. Lorsque la commande d'un client est reçue, les employés du magasin doivent être informés afin qu'ils puissent trouver et emballer les articles nécessaires. (Cela peut nécessiter un ou plusieurs conteneurs.) Enfin, les conteneurs seront livrés, soit ensemble, soit séparément.

Dans l'application elle-même, les clients et les employés doivent pouvoir insérer des notes et évaluer l'autre partie une fois la livraison effectuée.

Le modèle de données

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

Items & units
Customers & employees
Orders

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

Section 1 :Articles et unités

Nous allons commencer par les Items & units Domaine. Bien qu'il ne s'agisse que d'une petite partie de notre modèle, il contient deux tables très importantes.

L'unit table stocke des informations sur les unités que nous attribuerons à n'importe quel article de notre inventaire. Pour chaque valeur de ce tableau, nous stockerons deux valeurs UNIQUES :unit_name (par exemple "kilogramme") et unit_short (par exemple "kg"). Notez que unit_short est l'abréviation de unit_name .

Le deuxième tableau de ce domaine est item . Il répertorie tous les articles que nous avons en inventaire. Pour chaque article, nous stockerons :

item_name – Le nom UNIQUE que nous utiliserons pour cet article.
price – Le prix actuel de cet article.
item_photo – Un lien vers une photo de cet article.
description – Description textuelle supplémentaire de l'article.
unit_id – Fait référence à l'unit dictionnaire et indique l'unité utilisée pour mesurer cet élément.

Veuillez noter que j'ai omis certaines choses ici. Le plus important est un indicateur qui indique si un article en stock est actuellement proposé à la vente. Pourquoi n'avons-nous pas cela? Cela nécessiterait au moins un champ supplémentaire (le drapeau) ainsi qu'une autre table (pour stocker les modifications historiques pour chaque élément). Pour simplifier les choses, j'ai supposé que tous les articles que nous avons en inventaire sont également disponibles à la vente.

La deuxième chose importante que j'ai omise est le suivi de l'état de l'entrepôt. Mon hypothèse est que nous expédions tout depuis un entrepôt central et que nous aurons toujours des articles disponibles. Si nous n'avons pas d'article, nous en informerons simplement le client et lui proposerons un article similaire en remplacement.

Section 2 :Clients et employés

Les Customers & employees Le domaine contient toutes les tables nécessaires pour stocker les données des clients et des employés. Nous utiliserons ces informations dans la partie centrale de notre modèle.

Le employee Le tableau contient une liste de tous les employés concernés (par exemple, les emballeurs d'épicerie et les livreurs). Pour chaque employé, nous stockerons son first_name et last_name et un employee_code UNIQUE valeur. Bien que la colonne id soit également UNIQUE (et la clé primaire de cette table), il est préférable d'utiliser une autre valeur réelle (par exemple, un numéro de TVA) comme identifiant d'employé. Ainsi nous avons le employee_code champ.

Notez que je n'ai pas inclus les informations de connexion des employés, les rôles des employés et un moyen de suivre l'historique des rôles. Ceux-ci peuvent être facilement ajoutés, comme décrit dans cet article.

Nous allons maintenant ajouter des clients à notre modèle. Cela prendra deux tables supplémentaires.

Les clients seront segmentés géographiquement, nous aurons donc besoin d'une city dictionnaire. Pour chaque ville où nous proposons la livraison de courses, nous stockons le city_name et le postal_code . Ensemble, ils forment la clé alternative de cette table.

Les clients sont certainement la partie la plus importante de ce modèle; ce sont eux qui initient tout le processus. Nous stockerons une liste complète de nos clients dans le customer table. Pour chaque client, nous stockons les éléments suivants :

first_name – Le prénom du client.
last_name – Le nom de famille du client.
user_name – Le nom d'utilisateur que le client a sélectionné lors de la création de son compte.
password – Le mot de passe choisi par le client lors de la création de son compte.
time_inserted – Le moment où cet enregistrement a été inséré dans la base de données.
confirmation_code – Un code qui a été généré lors du code d'enregistrement. Ce code sera utilisé pour vérifier leur adresse e-mail.
time_confirmed – Lorsque la confirmation par e-mail s'est produite.
contact_email – L'adresse e-mail du client, qui sert également d'e-mail de confirmation.
contact_phone – Le numéro de téléphone du client.
city_id – L'identifiant de la city où réside le client.
address – L'adresse du domicile du client.
delivery_city_id – L'identifiant de la city où la commande du client doit être livrée.
delivery_address – L'adresse de livraison préférée. Notez qu'il peut s'agir (mais pas nécessairement) de la même adresse que l'adresse personnelle du client.

Section 3 :Commandes

La partie centrale et la plus importante de ce modèle est le Orders Domaine. Ici, nous trouverons tous les tableaux nécessaires pour passer une commande et pour suivre les articles jusqu'à ce qu'ils soient livrés aux clients.

L'ensemble du processus commence lorsqu'un client passe une commande. Une liste de toutes les commandes passées se trouve dans le placed_order table. J'ai intentionnellement utilisé ce nom et non "commande" car la commande est un mot-clé réservé SQL. Pour chaque commande, nous stockons :

customer_id – L'identifiant du customer qui a passé cette commande.
time_placed – L'horodatage auquel cette commande a été passée.
details – Tous les détails liés à cette commande, dans un format textuel non structuré.
delivery_city_id – Une référence à la city où cette commande doit être livrée.
delivery_address – L'adresse où cette commande doit être livrée.
grade_customer &grade_employee – Notes attribuées par l'employé et le client après la fin d'une commande. Jusqu'à ce moment, cet attribut contient une valeur NULL. La note d'un client indique à quel point il est satisfait de notre service ; la note d'un employé nous donne des informations sur ce à quoi s'attendre la prochaine fois que le client passera une commande.

Au cours du processus de passation de commande, un client sélectionnera un ou plusieurs articles. Pour chaque article, ils définiront une quantité souhaitée. Une liste de tous les articles liés à chaque commande est stockée dans le order_item table. Pour chaque enregistrement de ce tableau, nous stockerons les identifiants de la commande associée (placed_order_id ), article (item_id ), la quantité souhaitée et le price lorsque cette commande a été passée.

En plus de quoi ils veulent être livrés, les clients définiront également leur heure de livraison souhaitée . Pour chaque commande, nous créerons un enregistrement dans le delivery table. Cela enregistrera le delivery_time_planned et insérer des notes textuelles supplémentaires. Le placed_order_id L'attribut sera également défini lors de l'insertion de cet enregistrement. Les deux attributs restants seront définis lorsque nous attribuerons cette livraison à un employé (employee_id ) et quand la commande a été livrée (delivery_time_actual ).

Bien qu'il puisse sembler que nous n'aurons qu'une seule livraison par commande, ce n'est peut-être pas toujours le cas. Nous devrons peut-être effectuer deux livraisons ou plus par commande, et c'est la raison principale pour laquelle j'ai choisi de mettre les données de livraison dans un nouveau tableau.

Lorsque nous commençons à traiter une commande, les employés emballent les articles dans une ou plusieurs boîtes. Chaque box sera défini UNIQUEMENT par son box_code et sera affecté à une diffusion (delivery_id ). Nous conserverons également l'ID de l'employé qui a préparé cette boîte.

Chaque boîte contiendra un ou plusieurs articles. Par conséquent, dans le item_in_box table, nous devrons stocker les références à la box table (box_id ) et le item tableau (item_id ), ainsi que la quantité placée dans cette case. Le dernier attribut, is_replacement , indique si un article remplace un autre article. On peut s'attendre à ce qu'un employé contacte un client avant de mettre un article de remplacement dans une boîte. L'un des résultats de cette action pourrait être qu'un client accepte l'article de remplacement ; une autre pourrait être l'annulation de toute la commande.

Les trois autres tables du modèle sont étroitement liées aux statuts et aux commentaires.

Tout d'abord, nous allons stocker tous les statuts possibles dans le status_catalog . Chaque statut est UNIQUEMENT défini par son status_name . Nous pouvons nous attendre à des statuts tels que "commande créée", "commande passée", "articles emballés", "en transit" et "livré".

Les statuts seront attribués aux commandes soit automatiquement (une fois certaines parties du processus terminées) soit, dans certains cas, manuellement (par exemple, s'il y a un problème avec la commande). Tous les statuts de commande disponibles sont stockés dans le order_status table. Outre les clés étrangères de deux tables (status_catalog et placed_order ), nous stockerons l'horodatage réel lorsque ce statut a été attribué (status_time ) et tous les details supplémentaires sous forme textuelle.

Le tableau final de ce modèle correspond aux notes table. L'idée derrière ce tableau est d'insérer tous les commentaires supplémentaires liés à une commande donnée (placed_order_id ). Les commentaires peuvent être insérés par les employés ou les clients. Pour chaque enregistrement, un seul des employee_id ou customer_id les champs contiendront une valeur ; l'autre sera NULL. Nous enregistrerons le moment où cette note a été insérée dans le système (note_time ) et le note_text .

Quelles modifications apporteriez-vous au modèle de données de livraison de courses ?

Aujourd'hui, nous avons discuté d'un modèle de données qui pourrait prendre en charge les applications Web et mobiles de livraison de courses, tant du point de vue du client que du point de vue de l'employé. Comme déjà mentionné dans cet article, il existe de nombreuses façons d'améliorer ce modèle. N'hésitez pas à ajouter vos suggestions. Dites-nous ce que vous ajouteriez à ce modèle ou en retireriez. Ou peut-être organiseriez-vous cette structure complètement différemment. Faites-le nous savoir dans la section des commentaires !