Conception d'un magasin de données pouvant être mis à jour et interrogé en même temps

Question

Nous concevons un système d'inventaire en temps réel pour un site de commerce électronique qui agrège son inventaire auprès de plusieurs fournisseurs.

• Nos visiteurs peuvent rechercher et acheter des articles de notre site
• Nous obtenons des mises à jour de l'inventaire de plusieurs fournisseurs sur des horaires différents tout au long de l'heure. Les mises à jour se présentent sous la forme d'un cliché d'inventaire de leur système. En d'autres termes, nous n'obtenons pas une liste de ce qui a été vendu ou ce qui a été ajouté à partir d'eux, seulement un aperçu de leur inventaire au moment de la mise à jour.

Quelle est la meilleure conception pour ce système afin que nous puissions mettre à jour notre inventaire sans perturber l'expérience de commerce électronique?

Exigences:

1. assurer notre magasin d'inventaire ne varie pas. Lorsque nous actualisons notre inventaire avec les mises à jour de nos fournisseurs, nous ne pouvons pas simplement supprimer les anciens enregistrements, puis insérer les nouveaux enregistrements. Cela provoquera momentanément un état inexact dans notre magasin d'inventaire.
2. Assurez-vous qu'il n'y a pas de doublons dans le magasin d'inventaire à tout moment.

La solution ne doit pas nécessairement être limitée à la conception de la base de données. Nous sommes ouverts aux solutions impliquant la base de données, le cache distribué en mémoire ou tout autre moyen. MISE À JOUR (@Andrew Keith): Ma question se concentre sur la façon de maintenir un magasin d'inventaire (qu'il s'agisse d'une base de données ou d'un cache en mémoire) afin que les mises à jour d'inventaire puissent être appliquées au magasin tout en gardant le magasin ouvert pour les opérations de commerce électronique (par exemple, recherche, paiement, etc.).

Answer 1

Votre question est trop ouverte. Un système de commerce électronique est un terme informatique générique utilisé pour désigner de nombreux systèmes. Ce que vous devez faire est de décomposer votre question en sous-questions plus gérables afin que vous obteniez des réponses significatives.

Les exigences que vous avez mentionnées sont toutes des exigences simples qui peuvent être facilement supportées par n'importe quelle conception.

Êtes-vous intéressé à développer le système à partir de rien, ou à acheter et intégrer un système de commerce électronique existant?

Answer 2

Vous avez insisté sur votre désir de Atomicity des changements à l'inventaire - utiliser l'un des systèmes de DB populaires et concevoir vos mises à jour comme des transactions pour tout système que vous choisissez.

En ce qui concerne vos besoins:

1. C'est ce que garantit atomicité. Bien que n'importe quelle requête de client particulière puisse devoir attendre qu'une mise à jour d'inventaire soit accomplie ou qu'elle devienne obsolète dans un temps (presque) arbitrairement petit. Vous devriez re-vérifier l'inventaire quand un client passe à l'étape suivante de votre processus de commande (de toute façon).
2. Ce n'est pas si difficile si vous utilisez des instructions 'update' dans le langage de requête quel que soit le système DB que vous choisissez. Je ne suis pas familier avec un nouveau record, remove-old-record pattern pour le maintien de l'état (sans parler des quantités d'inventaire).
3. Ceci est impossible en général.Vous pouvez vendre x unités d'un article et la prochaine mise à jour de l'inventaire que vous recevez de votre fournisseur (s) peut diminuer la quantité disponible de cet article à une valeur inférieure à x. Votre seule réponse (générale) est de présenter des excuses à un certain nombre de clients, bien que dans la pratique ceci soit probablement une préoccupation insignifiante.