هل يجب تخزين تسجيلات الموقع في جدول منفصل للمستخدمين النشطين؟

Question

أنا أتساءل عن أفضل الممارسات لتسجيل المستخدم.أنا أميل إلى تخزين تسجيلات الموقع في جدول تسجيلات منفصل وبعد ذلك بمجرد تأكيد الاشتراك عن طريق البريد الإلكتروني يتم نقل البيانات إلى جدول المستخدمين.

تتمثل الفائدة من ذلك في عدم ازدحام عمليات القراءة من جدول المستخدمين مع عدم تنشيط التسجيلات مطلقًا.فائدة أخرى هي أن حقل البريد الإلكتروني (اسم المستخدم) يمكن أن يظل فريدًا في جدول المستخدمين، ولكن إذا حاولت التسجيل باستخدام عنوان بريد إلكتروني لا تملكه، فسيظل مالك عنوان البريد الإلكتروني هذا قادرًا على التسجيل به باعتباره لن يكون حقل البريد الإلكتروني فريدًا في جدول التسجيلات.

أتساءل عما إذا كانت هذه ممارسة شائعة أو إذا كان هناك أي سبب يجعلها ليست فكرة جيدة؟

Answer 1

تفعيلها أم لا

ليست هناك حاجة حقيقية لتخزين مستخدم في جدول مختلف.ما عليك سوى تخزين جميع المستخدمين في جدول واحد، مع وضع علامة منطقية تشير إلى ما إذا كان قد تم تنشيطهم أم لا.قم بتشغيل وظيفة cron بين الحين والآخر للتحقق ومعرفة ما إذا كانت هناك حسابات عمرها x من الأيام ولم يتم تنشيطها وحذفها.

بريد إلكتروني

لذا من المفترض أنك تقوم بتنشيط المستخدم من البريد الإلكتروني، أليس كذلك؟هل ترغب أيضًا في إعداده بحيث إذا قام مستخدم آخر بإدخال البريد الإلكتروني الخاص بشخص آخر، فلا يزال بإمكان هذا الشخص الآخر التسجيل بشكل صحيح؟هذا في الواقع أمر بسيط إلى حد ما.في رسالة البريد الإلكتروني التي تم إرسالها إليهم عن طريق الخطأ، ما عليك سوى الحصول على رابط لإزالة هذا البريد الإلكتروني من قاعدة البيانات الخاصة بك لأنه من الواضح أنهم ليسوا هم ولن يقوموا أبدًا بتنشيط الحساب.

ولكن ماذا لو قام الشخص الآخر بحذفها؟

ثم عندما يقومون بالتسجيل، أخبرهم أن لديك بالفعل بريدهم الإلكتروني واعرض عليهم إرسال التنشيط مرة أخرى، وسيكون لهذا البريد الإلكتروني أيضًا خيار إزالته من قاعدة البيانات.

أو

فقط قم بإزالة الحساب الأقدم من قاعدة البيانات.من المنطقي أنه إذا كان الشخص يحاول تنشيط حساب جديد وكان هناك حساب قديم لم يتم تنشيطه مطلقًا، فيمكنك إزالته فقط.

Answer 2

وأنا أعتقد أن ذلك سيكون على الهندسة.

وتخزين كل منها في جدول واحد وجدولة استعلام SQL (كل يوم) لحذف حسابات لا actived مضى عليها أكثر من 30 يوما.

Answer 3

ولنفسك صالح والاحتفاظ بها جدول واحد. كنت فقط لن يكون التسجيلات أجهضت ما يكفي لمشاكل الأداء على ان يدخل حيز اللعب (خاصة إذا كنت تصفيتهم بعد 3 أسابيع).

والتبرير لديك حول عناوين البريد الإلكتروني سخيف. لا أحد من المرجح أن تحصل على بريدهم الإلكتروني سدت تسجيل كاذبة.

Answer 4

وربما تكون هناك حالة واحدة التي كنت تقسيم منطقيا الجدولين: إذا عملية تسجيلك تطلب الكثير من معلومات المستخدم إلزامية إلا بعد أن تتأكد من عنوان البريد الإلكتروني. على سبيل المثال، إذا كان لديك جدول تسجيل في انتظار أن ينتهي بهم الأمر سوى بضعة أعمدة، مثل البريد الإلكتروني ومفتاح التنشيط في حين مستخدمين الجدول يحتوي على العديد من أعمدة إضافية، مثل اسم المستخدم، الاسم الأول واسم العائلة والعنوان البريدي، الخ.

والانقسام قد يكون له معنى في هذه الحالة، كما كنت تريد ان تكون قادرة على الإعلان عن أن تلك الأعمدة NOT NULL.

وبخلاف ذلك، على الرغم من أنني يجب أن نتفق مع معظم الإجابات الأخرى. هذا يبدو وكأنه الأمثل من السابق لأوانه بالنسبة لي. جداول متعددة مع نفس الهيكل هو علامة تحذير قوي بأن <م> اور تفعلين ذلك الخطأ. ليس واضحا، ولكن تحذيرا قويا.

Answer 5

وأنا أتفق مع هذه الممارسة للفصل بين أسباب القلق: A "عملية التسجيل" و "حسابات المستخدمين" مفهومان منفصلة

.

وستستخدم الجدول التسجيل لتستمر حالة "عملية التسجيل". وبمجرد أن اكتمال العملية (مرة واحدة يتم التحقق من صحة البريد الإلكتروني)، "إخراج" عملية ستكون "حساب المستخدم" الجديد. إذا فشلت العملية (على سبيل المثال، "مهلة" بعد فشل المستخدم لتأكيد بريده الإلكتروني لشهر 1)، وليس هناك تأثير على "حساب المستخدم" المفهوم.

وكما قيل في جواب آخر، وهذا يمكن أن يكون أكثر من الهندسة في بعض الحالات، ولكن يمكن أيضا أن يكون وسيلة مفيدة لenapsulate تعقيد هذه مفهومين منفصلين. ويمكن أيضا أن ينظر إليها على أنها تناقض مبادئ التطبيع، ولكن بعد ذلك أعتقد أن لديك لاختيار المفاضلة بين التغليف والتطبيع اعتمادا على السياق الخاص بك.