بهترین راه حل برای مدیریت تغییرات حساب کاربری

[leaping]

سلام
فرض کنید که یک وب سایت هست که چون وظیفش سرو کله زدن با گردش های مالی هست نیاز داره که اطلاعات حساب کاربری دقیق و صحیح باشن
از همین رو اگه کاربر به فرض بیاد اول اطلاعات صحیح و دقیق وارد کنه و طبق اون کارش راه بیفته و در ادامه بیاد اطلاعات حساب کاربریشو تغییر بده و اگه کارهایی کرده باشه با اون حساب اگه فقط این اطلاعات از یکجا لود و تغییر داده بشن مشکلاتی ایجاد میکنه
حالا اگه بیایم رو بک اپ حساب باز کنیم بک آپ هم همیشگی و لحظه ای که نیست
در نتیجه به نظرتون این راه حل که بیایم در کنار جدول اصلی اطلاعات حساب کاربری یک جدول پشتیبان هم داشته باشیم که با هر تغییر رکورد جدیدی از اون کاربر ذخیره بشه منطقی و بهینه هست یا خیر؟

[Veteran]

یک جدول بزار با حداقل 5 تا فیلد
id,userID, tableID, data, create_time
قبل از هر تغییر ( اپدیت) رکورد قدیمی رو serialize کن و درج کن توی فیلد data، اسم جدول مربوط به رکورد رو هم بزار توی فیلد tableID، همینطور ایدی کاربری که میخواد ویرایش کنه رو بزار توی userID، زمان هم که مشخصه.
اینجوری هیچی از زیر دستت درنمیره و همه چیو داری.

[leaping]

میشه یکم بیشتر توضیح بدی؟

[Veteran]

عذر میخوام، اشتباه گفتم.
با فیلد های id, userID, TableID, data, create_time
من توی کارام واسه اینکه چیزی رو از دست ندم و همیشه از اطلاعات کپی داشته باشم میام کاری که گفتم رو پیاده میکنم.
مثلا فرض کن توی سیستم کاربر میخواد پروفایل رو اپدیت بکنه. خب توی صفحه پروفایل اول باید بیایم اطلاعات کاربر رو در بیاریم نشونش بدیم.
حالا قبل از اینکه اپدیت کنه، میام همون رکورد کاربر رو با تابع serialize تبدیل به رشته میکنم و بعد توی جدول tbl_backup با اون فیلد ها اضافه میکنم.
خروحی serialize روی میزارم توی فیلد data
ایدی کاربر رو میزارم توی userID
اسم جدول هم توی tableID، تا بدونم این رکورد مربوط بکدوم جدوله
زمان رو هم که مشخصه.
اینجوری هیچی از دست نمیره

[leaping]

آها گرفتم
ممنون

[prans.info]

عذر میخوام، اشتباه گفتم.
با فیلد های id, userID, TableID, data, create_time
من توی کارام واسه اینکه چیزی رو از دست ندم و همیشه از اطلاعات کپی داشته باشم میام کاری که گفتم رو پیاده میکنم.
مثلا فرض کن توی سیستم کاربر میخواد پروفایل رو اپدیت بکنه. خب توی صفحه پروفایل اول باید بیایم اطلاعات کاربر رو در بیاریم نشونش بدیم.
حالا قبل از اینکه اپدیت کنه، میام همون رکورد کاربر رو با تابع serialize تبدیل به رشته میکنم و بعد توی جدول tbl_backup با اون فیلد ها اضافه میکنم.
خروحی serialize روی میزارم توی فیلد data
ایدی کاربر رو میزارم توی userID
اسم جدول هم توی tableID، تا بدونم این رکورد مربوط بکدوم جدوله
زمان رو هم که مشخصه.
اینجوری هیچی از دست نمیره

اینطوری هم تعداد رکورد ها بسیار بالا میره و تویه پروژه های نسبتا بزرگ مشکل ساز میشه و باعث فشار اومدن به سرور میشه ...
البته احتمال میدم اگه انجین جدول رویه archive باشه این مسئله دیگه زیاد به چشم نیاد ...

[Veteran]

گاهی باید قید کارایی رو زد،اهمیت آرشیو های مختلف از اطلاعات کاربرا توی بعضی از سناریو ها و سیستم ها مهمتر از کارایی میشه.
گرچه توی این سناریو زیاد هم که بظاهر نشون میده دستو پاگیر نیست.
به عنوان مثال اگر یک سیستم داشته باشیم 10 هزار کاربر داشته باشه،این 10 هزار تا احتمالش چقدر هست که بیان اطلاعات رو ویرایش بکنند ( بیش از 50% کاربران) ؟ گرچه الان سیستم های بزرگ هم از این روش استفاده میکنند،البته منظور راه حلی که توضیح داده شده نیست،بلکه منظور نگه داری اطلاعات ویرایش شده هست. مثل گوگل،فیسبوک و.... این سیستم ها کوچترین داده ایی رو حذف نمیکنند! حتی سیستم های بانکی(یک مورد همکاری داشتم) هم حذف نمیکنند و تماما داده هارو نگه میدارن. اونقدرا هم مشکل ساز نمیشه. درعوض شما همه اطلاعات رو دارید.

[leaping]

اینطوری هم تعداد رکورد ها بسیار بالا میره و تویه پروژه های نسبتا بزرگ مشکل ساز میشه و باعث فشار اومدن به سرور میشه ...
البته احتمال میدم اگه انجین جدول رویه archive باشه این مسئله دیگه زیاد به چشم نیاد ...
وقتی اطلاعات رو آرشیو کردین خیلی راحت میشه بعد یه مدت قسمت به قسمت اونهارو بایگانی کرد و از مدار خارج کرد که فشاری هم به سرور نیاد
اینطوری هم اطلاعات نگهداری میشه و هم کارایی هم کم نمیشه
نگهداری اطلاعات کاربران در خیلی از موارد واقعا ضروری هست و نباید پشت گوش انداخت وگرنه خود شما مسئول هستید یادتون باشه

[Unique]

به جای آرشیو گرفتن های اینطوری بهتر نیست مانع تغییر رکورد ها بشیم و یک کپی از تغییرات مورد نظر برای مدیر ارسال بشه و در صورت تایید مدیر اعمال بشه ؟

[leaping]

جلوگیری از تغییرات یجورایی پاک کردن صورت مسئله ست
و این موضوع هم که برای هر تغییر قطعا مدیریت اطلاع پیدا میکنه اما اینکه همه این اطلاعات برای مدیر مثلا ایمیل بشه فک نکنم اصلا فکر خوبی باشه , اینطوری بازم خودش نیازمند یه آرشیو دیگه هست

[Unique]

راستش به نظرم این آرشیو های کور کورانه یکجور تولید Junk Data هست. من نمیدونم اطلاعات شما چیه. مثلا نام و نام خانوادگی و کد ملی شخص که عوض نمیشه. پس وقتی یکبار تایید میکنیم که درست وارد شده دیگه لازم نیست اجازه تغییرش را بدیم. آدرس ایمیل و موبایل را هم میشه با ارسال ایمیل و پیامک تایید مانع از تغییر الکیشون شد. منظور من هم در رابطه با تایید مدیریت این بود که یک جدول برای تغییرات درخواستی داشته باشین و وقتی کسی درخواست ویرایش میکنه (منظور اینه که مقادیر جدید را وارد میکنه) مدیر توی مرکز کنترلش بتونه ببینه و اگه صلاح دونست اجازه تغییر بده.

روش آرشیو کردنی که مطرح شد هم اگه برای مدیر رابط کاربری برای مدیریتش وجود نداشته باشه و فقط یکسری رکورد ذخیره شده باشه کلا بی فایده هستش.

[leaping]

راستش به نظرم این آرشیو های کور کورانه یکجور تولید Junk Data هست. من نمیدونم اطلاعات شما چیه. مثلا نام و نام خانوادگی و کد ملی شخص که عوض نمیشه. پس وقتی یکبار تایید میکنیم که درست وارد شده دیگه لازم نیست اجازه تغییرش را بدیم. آدرس ایمیل و موبایل را هم میشه با ارسال ایمیل و پیامک تایید مانع از تغییر الکیشون شد. منظور من هم در رابطه با تایید مدیریت این بود که یک جدول برای تغییرات درخواستی داشته باشین و وقتی کسی درخواست ویرایش میکنه (منظور اینه که مقادیر جدید را وارد میکنه) مدیر توی مرکز کنترلش بتونه ببینه و اگه صلاح دونست اجازه تغییر بده.

روش آرشیو کردنی که مطرح شد هم اگه برای مدیر رابط کاربری برای مدیریتش وجود نداشته باشه و فقط یکسری رکورد ذخیره شده باشه کلا بی فایده هستش.
آیتم هایی مثل آدرس و شماره تلفن ثابت
و همچنین آیتم های تصویری مثل تصویر اجاره نامه و یا بقیه چیزهای قابل تغییر و در کنارش مهم هم وجود داره که مدیریت می بایست وقت تغییر کردنش همیشه مطلع باشه و البته سوابقش رو داشته باشه

در مورد آرشیو کردن هم میشه پنل های اختصاصی هم براش تعبیه کرد در حد گردش بین رکوردها و نمایشش
چیز خاص دیگه ای ازش انتظار نمیره فک کنم :لبخندساده: