لقد رأيت للتو بعض الأفكار حول عربات التسوق من زميلي وو لي، وصادف أنني كنت على دراية بهذا الجانب من التجارة الإلكترونية، لذلك قفزت لإظهار خجلي وآمل أن يكون ذلك مفيدًا لبعض الزملاء. أردت في الأصل الرد على ما يلي، لكن اتضح أن كتابته تستغرق الكثير من الوقت، لذا سيكون من الأسهل العثور عليها بنفسي في المستقبل : 1. ينبغي هل سيتم تخزين البيانات الموجودة في عربة التسوق في قاعدة البيانات؟
أريد بشكل خاص أن أعرف كيف يفكر مهندسو البرمجيات الحقيقيون في هذه المشكلة في المشاريع الحقيقية. بعد البحث في Google، وجدت مقالًا من أحد مستخدمي الإنترنت في حديقتنا: يجب أن تكون عربة التسوق وحدة لتخزين البيانات مؤقتًا، وقد قام بتخزينها في كائن الجلسة. ما قاله مستخدم الإنترنت هذا منطقي، لكني لا أحب هذا النهج. إذا قام الجميع بتخزينه في كائن الجلسة وتسوق آلاف المستخدمين معًا، فمن المؤكد أن خادم ASP.NET سيتحمل عبئًا كبيرًا. ربما تكون مواقعنا الإلكترونية المحلية أفضل، ولكن كيف نفعل ذلك لمواقع مثل أمازون؟ لا يقوم موقع Amazon China، وهو موقع Joyo، بتخزينه في كائن الجلسة، لأنه إذا لم أقدم طلبًا للمنتجات التي أضعها في عربة التسوق هذه المرة، فستظل هذه المنتجات في عربة التسوق بعد تسجيل الدخول في المرة القادمة. لذلك اعتقدت أنهم ربما يضعون البيانات من عربات التسوق هذه في قاعدة بيانات.
الرد: يبدو أن تخزين عربة التسوق في الجلسة موجود فقط في تصميم المقررات الدراسية في الجامعات أو في بعض مشاريع التدريب التي لا يهتم بها أحد. في الواقع، تقوم جميع مواقع التجارة الإلكترونية تقريبًا بتخزين بيانات عربة التسوق في قاعدة البيانات. فيما يلي بعض التوضيحات واعتبارات التصميم:
1. الجلسة غير مناسبة لتخزين كميات كبيرة من البيانات، فعند وجود عدد كبير من المستخدمين، سيؤثر ذلك حتمًا على أداء الخادم، وهو ما يجب تجنبه.
2. هناك مشكلة فقدان الجلسة عن طريق الخطأ، أو عندما يقوم المستخدم بإغلاق المتصفح عن طريق الخطأ، سيتم فقدان جميع العناصر الموجودة في عربة التسوق، مما يؤدي إلى تجربة مستخدم سيئة للغاية.
3. يمكن أن تحل ملفات تعريف الارتباط مشكلة الجلسة في العنصر أعلاه، ولكن نظرًا للحد الأقصى لطول ملفات تعريف الارتباط، وحمل الاتصالات عند استخدام ملفات تعريف الارتباط، والاعتبارات الأمنية، فإن ملفات تعريف الارتباط ليست مناسبة لعربات التسوق.
4. تجربة المستخدم الأفضل هي أنه بغض النظر عما إذا كان المستخدم قد قام بتسجيل الدخول أم لا، يمكن تسجيل حالة عربة التسوق خلال فترة زمنية معينة. وهذا يتطلب عدم ربط عربة التسوق في قاعدة البيانات بالمستخدم.
5. المنتجات الموضوعة في عربة التسوق هي بشكل عام منتجات ذات نية شراء، ولكنها قد لا تصبح بالضرورة طلبات فعلية في هذا الوقت، ويلعب الاحتفاظ بهذه البيانات دورًا حيويًا في استخراج البيانات وتحليل الأعمال.
السؤال: 2. حول التزامن؟
اتضح أنه عندما كنت أقوم بتطوير موقع الويب الوهمي الخاص بي، فكرت ذات مرة في هذا السؤال: إذا وضع العميل بعض الكتب في عربة التسوق على الموقع، فهل يجب طرح هذا العدد من الكتب من المخزون؟ هذا ما فعلته. أقوم بطرح كمية الكتب المقابلة في عربة التسوق من قاعدة البيانات لمنع المستخدمين الآخرين من رؤية كمية المخزون الزائفة في هذا الوقت (إذا لم يتم طرحها، فيمكن للمستخدمين الآخرين شرائها. على سبيل المثال: عدد الكتب في المخزون هو 10 هذا الكتاب، العميل "أ" يضع 10 نسخ في عربة التسوق الخاصة به، والعميل "ب" يضع أيضًا 10 نسخ في عربة التسوق الخاصة به، ومن سيشتري هذا الكتاب سيصبح صراعًا). ومع ذلك، فإن النتيجة هي أنه في كل مرة يقوم فيها العميل بتحديث عربة التسوق، سيكون هناك اتصال بقاعدة البيانات، مما يزيد العبء على خادم البيانات. Amazon.cn لا تعمل بشكل جيد في هذا الصدد منذ بضعة أيام، أعتقد أنك ربما واجهت مشكلة تتمثل في أنك عندما اشتريت كتاب "الفهم المتعمق لأنظمة التشغيل"، قمت بتقديم طلب في الأصل، ولكن تم إبلاغك بذلك. أنه كان من المخزون في اليوم التالي. لقد أثر هذا الحادث بالفعل بشكل كبير على مصداقية Amazon.cn، ولا أعرف ما إذا كان نظامهم قد حل هذه المشكلة الآن، لكن سعر Joyo لكتاب "الفهم المتعمق لأنظمة التشغيل" لم يعد كما كان من قبل. . لا أعرف كيف حل الخبراء هذه المشكلة، فنحن نرحب بك لتدوين تجربتك الناجحة في التعليقات.
الرد: أولاً، دعونا نتحدث عن العبء الواقع على خادم قاعدة البيانات، فكر في عدد المرات التي تحتاج إلى الوصول إلى قاعدة البيانات في كل مرة يتم فيها الوصول إلى الصفحة، ثم فكر في عدد المرات التي يستغرقها التبادل لعملية إضافة واحدة. عربة التسوق (يعتمد عدد مرات الوصول بشكل أساسي على سهولة استخدام موقع الويب). التصميم، هذا موضوع آخر)، لذا على الرغم من أن تعديل التصميم هنا يمكن أن يقلل بعض الضغط على قاعدة البيانات، إلا أنه لا يمثل عنق الزجاجة هنا ليست هناك حاجة إلى إيلاء الكثير من الاهتمام هنا.
من الممارسات الشائعة في الوقت الحاضر عدم خصم البضائع الموجودة في عربة التسوق على الفور من المخزون، وذلك بشكل أساسي لمنع أي شخص من احتلال البضائع بشكل ضار من خلال عربة التسوق، بالإضافة إلى ذلك، يتم توفير التكرار بشكل عام، لأن معظمها لن يتم خصم البضائع الموجودة في عربة التسوق من المخزون. عند إدخال الطلب النهائي الناجح، يجب ألا تدع عربة التسوق تؤثر على المبيعات. يتم خصم المخزون بشكل عام عند تقديم الطلب بنجاح، أي أنه عندما يقوم المستخدم بتقديم الطلب، يكون لديك فرصة أخرى لتذكير المستخدم بعدم وجود مخزون، لذلك ليست هناك حاجة لخصم المخزون عند تقديم الطلب. عربة التسوق. بالنسبة للأوامر الناجحة، لا تعتبر جميع الطلبات المقدمة من قبل المستخدمين أوامر ناجحة. هناك عملية مراجعة تلقائية للطلبات يصعب كتابتها، ولكنها في الواقع مهمة جدًا بناءً على تحليل البيانات السابقة وسلوك المستخدم وسمعة المستخدم وما إلى ذلك تأتي البيانات من النظام الذي يقوم تلقائيًا بإكمال مراجعة الطلب في غضون دقائق قليلة. وترتبط شدة المراجعة بالصناعة. وهذا يمكن أن يزيل معظم الطلبات المزيفة، وقد يلزم تحويل بعضها إلى المراجعة اليدوية بواسطة نظام المراجعة التلقائية.
هناك وضع خاص هنا بالنسبة لبعض المنتجات الخاصة مثل تذاكر الحفلات الموسيقية، حيث قد يكون هناك اختيار للمقعد عبر الإنترنت، وفي هذه الحالة، يصبح من المفيد حجز مقعد بعد وضع عربة التسوق مباشرة بعد وضع عربة التسوق، ولكن سيتم تحريرها تلقائيًا إذا لم تصبح طلبًا حقيقيًا خلال فترة زمنية معينة، مثل عشر دقائق. على الرغم من أنها لا تستطيع القضاء تمامًا على شغل المقعد الضار، إلا أنها يمكن أن تحل معظم المشكلات. في الوقت الحاضر، تختلف الطلبات الناجحة في مجال التذاكر عن معظم الصناعات الأخرى. إن معيار الحكم على طلبات اختيار المقاعد الناجحة عبر الإنترنت في صناعة التذاكر هو ما إذا كان الدفع ناجحًا، مما يعني أنه ما لم تدفع، فلن تتمكن من البقاء إلا لمدة عشرة أيام. دقائق.
السؤال: 3. العلاقة بين الطلبات وتفاصيل الطلب وعربات التسوق
أعتقد أن هذه المشكلة ربما كانت دائمًا مشكلة كبيرة لهذا النوع من مواقع الويب! قبل يومين، أجرى معي المعلم تشين من CSTP مقابلة عبر الهاتف حول هذا السؤال، وكنت متوترًا للغاية في ذلك الوقت ولم تكن إجابتي على السؤال واضحة جدًا. في الواقع، ليس من الصعب التفكير في هذه المشكلة ببساطة: هناك جدولان، أوامر وتفاصيل، كل عمود في جدول الطلبات يشير إلى العمود المقابل في جدول التفاصيل. المفتاح الخارجي هو رقم الطلب في جدول الطلب.
الرد: هذا السؤال بسيط نسبيًا. الأول هو وضعه في عربة التسوق ومعاملته كطلب. في هذه الحالة، يمكن تعديل الطلب ودمج عربة التسوق في نظام الطلب ( انتبه إلى التعامل مع حالة تسجيل دخول المستخدم وعدم تسجيل الدخول)؛ والثاني هو أن يكون لديك جدول عربة تسوق منفصل عند تقديم الطلب أخيرًا، يتم نسخ المعلومات الموجودة في عربة التسوق إلى جدول تفاصيل الطلب. الخيار الأخير هو الأكثر استخدامًا، ويعتمد الاختيار المحدد على سمات الصناعة والمنتج.
سؤال: 4. كيف يتم إنشاء رقم الطلب في القائمة التفصيلية؟
هذا السؤال موروث من السؤال 3. وما زلت لا أعرف كيفية حل هذه المشكلة. لدي حلان، أحدهما يستخدم المشغل والآخر البرمجة. يضيف الأول تفاصيل في كل مرة يضع فيها العميل منتجًا في عربة التسوق، وينشئ طلبًا بعد تأكيد الشراء، ويغير حالة الشراء في جدول التفاصيل لتشغيل المشغل وإنشاء رقم الطلب (بالطبع رقم الطلب هذا) يمكن أن تكون البرمجة في المشغل أيضًا لتعيين عمود رقم الطلب في جدول الطلب لإنشاء رقم تسلسلي تلقائيًا). سيحكم الأخير على رقم الأمر ثم يضيف 1 إليه لإنشاء رقم أمر جديد. لكني أشعر دائمًا أن هذين الحلين سيئان للغاية، وأود أن أعرف كيف يتم التعامل مع أرقام الطلبات على المواقع التجارية.
الرد: أولاً، أنا شخصياً أعتقد أن الحل الزناد غير مستحسن ولن أشرح الأسباب، وإلا ستكون هناك فوضى كبيرة. هناك أيضًا طريقتان هنا: أحدهما هو إنشاء أرقام تلقائيًا من جدول الطلب، عند إنشاء طلب، اكتبه أولاً في جدول الطلب، ثم استخرج رقم الطلب ثم قم بتحديث جدول تفاصيل الطلب رقم الطلب وفقًا لقواعد العمل، عندما يكون رقم الطلب معروفًا، يمكنك إنشاء سجل طلب أو سجل تفصيلي أولاً، ولكن يجب التأكد من أن سجل التفاصيل يجب أن يحتوي على سجل طلب في النهاية، وإلا سيكون هناك. الكثير من التفاصيل الغريبة. هناك طريقتان للطريقة الأخيرة، الأولى هي أن يتم إنشاء رقم الطلب بواسطة قاعدة البيانات، ويتم استخدام جدول مؤقت بشكل عام، والميزة هي أنه يمكن استخدام الرقم التسلسلي عالميًا في جميع الشركات يمكن استخدام المعرف الفريد العمومي (GUID) الذي يتم إنشاؤه بواسطة برنامج عند إنشاء البرنامج، ولكن الطريقة الأفضل هي استخدام وقت الطلب بالإضافة إلى قيمة التعريف التي يمكن أن تعتمد على الطلب يتم تحديد حجم التفاصيل بناءً على الحجم، ويتم ترقيم جزء التعريف بالترتيب، ويجب أيضًا مراعاة التفاصيل الزمنية لمنع الآخرين من حساب حجم عملك بشكل تقريبي (العرق ~ ~ هذه أيضًا مشكلة أخرى. هناك العديد منها). يعتمد الأمر على الموقف. سأكتب في يوم آخر عندما يكون لدي الوقت. دعنا نكتب مقالًا حول إنشاء أرقام الطلبات أولاً، لذلك ربما لدي معلومات كافية...)