PDA

View Full Version : سوال: روش مناسب جهت نگهداری و خواندن اطلاعات



saghari
سه شنبه 21 دی 1389, 22:01 عصر
با درود
فرض کنید یک نرم افزار کاربردی تحت وب میخواهیم تولید کنیم که باید در یک سازمان و 12 زیر مجموعه اون سازمان استفاده بشه. در سازمان مرکز و هر کدوم از دفاتر هم بطور متوسط 200 تا 800 کاربر قراره از سیستم استفاده کنن. هر کدوم از این مراکز دارای اینترانت داخلی هستند که نرم افزار باید بر روی اون نصب بشه و در عین حال ممکنه کاربران خاصی از طریق اینترنت هم به سیستم وصل بشن.
سازمان مرکز نیاز داره تا در پایان هر هفته از اطلاعات کلیه مراکز بصورت مجتمع گزارش تهیه کنه.
حال سوال اینه که برای طراحی بانک و نرم افزار فوق من از کدوم روش استفاده کنم؟
1- از طریق رپلیکیشن دیتابیس سازمان و مراکز اون.
2- دیتابیس هر مرکز کاملا مستقل باشه و من به ازای هر فیلد در جداول اصلی یک فیلد واسط در مراکز در نظر بگیرم و مراکز در پایان هر هفته اطلات در مرکز جمع بشه و از طریق و فیلدهای واسط گزارش تهیه بشه.
3- هر زمان قراره در جداول پایه اطلاعات ثبت بشه کاربرا به بانک سازمان مرکز وصل بشن و بالطبع در هنگام کار با برنامه هم باید اطلاعات جداول پایه از سازمان مرکز خونده بشه.
4- اگه روش دیگه و مناسب تری هست راهنمایی کنید.
قبلا از توجه شما سپاسگزارم

aminghaderi
چهارشنبه 22 دی 1389, 03:14 صبح
سلام .
به نظر من بهتره یه سرور مرکزی داشته باشی ، بعد توسط ip اون سرور و sql که روی اون سرور نصب شده به تمام کلاینت هاتون سرویس بدین.
به این صورت که کلا شبکه داخلی رو بی خیال بشید و از طریق اینترنت یا اینترانت اصلی مرکز به همه کلاینت ها سرورس بدین.

اگر باز دستتون برای این کار بسته هست (رعایت اصول و مقررات و بروکراتی سازمانی) به نظر من یه سیستم زمانبندی بنوسید که اخر هفته قبل گزارش گیری سازمان مرکزی به تمام سرور ها کانکت بشه و دیتا بیس هاشون رو بخونه و داخل سرور اصلی ذخیره کنه از طریق ریپلکیشن هم می شه ولی باید ببینم منظور شما از ریپلکیشن چی بوده؟؟؟؟؟؟؟؟؟

saghari
چهارشنبه 22 دی 1389, 13:57 عصر
با درود و تشكر از توجه شما
در روش سوم كه شما انتخاب فرموديد مشكل اينجاست كه با ساختار اينترنتي كه در كشور داريم و تعداد زياد كاربران (والبته حجم تقريبا بالاي ديتايي كه از ديتابيس واكشي ميشه يا به اون ارسال ميشه) سرعت بسيار پايين تري در مقايسه با حالتي كه هر مركز در بستر اينترانت خودش كار كنه خواهند داشت و اين نكته رو هم در نظر بگيريد كه هركدوم از مراكز در عين حال كه بايد به مركز اطلاعات جهت گزارشات بدهند، خودشون مستقل كار ميكنن.
البته قطعا ساده تريت روش پياده سازي همينه :لبخندساده:

اگر باز دستتون برای این کار بسته هست (رعایت اصول و مقررات و بروکراتی سازمانی) به نظر من یه سیستم زمانبندی بنوسید که اخر هفته قبل گزارش گیری سازمان مرکزی به تمام سرور ها کانکت بشه و دیتا بیس هاشون رو بخونه و داخل سرور اصلی ذخیره
خودم هم كم كم دارم به اين نتيجه ميرسم كه همين كار رو انجام بدم. فقط عيبش اينه كه بايد كلي روال براي پكپارچه كردن ديتابيس بنويسم. مگه اينكه روش بهتري دوستان پيشنهاد كنن.

Javad_Darvish_Amiry
چهارشنبه 22 دی 1389, 21:44 عصر
سلام خسته نباشید.
به نظر من: کاربرد های بزرگ واقعا بزرگن و دو طرف، کارفرما و مجری، هر دو باید براش بزرگ باشن. سطح بزرگی هم همیشه نسبیه البته. در بزرگی شما شکی نیست، پس میرم سراغ کارفرما، اگه کارفرما درک درستی از کار داره و حاضره اونقدری که لازمه هزینه کنه، خوب درست ترین روش، وجود یه سرویس دهنده مرکزی برای اتصال با پایگاه داده است. که البته باز نیازمند یه پوشش برای سریالیزه کردن داده و از اون مهمتر تعیین هویت و تایید اعتبار هستش. عملا هیچ کدوم از سناریوهای مدرن دسترسی چند تا کاربرد رو به صورت همزمان به پایگاه داده (البته تا اونجایی که من مطالعه کردم) نمیدن و همیشه حداقل یه پوشش برای پایگاه داده که تو چند لایه بهش گفتیم لایه دسترسی به داده، وجود داره. لایه امنیت هم سر جای خودش باید بررسی بشه. برای بهینه سازی هم باید دراز مدت رو در نظر گرفت. اول این که با روش های درست و اصولی سریالیزه کردن، حجم داده انتقالی به شدت می تونه بیاد پایین، ثانیا استفاده از کش کارایی کاربرد رو شدیدا بالا می بره. سوم کلاینت ها میتونن ( و علی القاعده باید تو این شرایط) برنامه سرویس گیرنده رو روی سیستم های خود شون داشته باشن (تحت دسکتاپ یا وبش فرق نمیکنه) یعنی تنها داده انتقالی، داده پایگاه باشه. حتی میشه قسمت اعظم لاجیک رو هم رو هر کلاینتی جداگانه سوار کرد و سرور فقط وظیفه مدیریت داده رو داشته باشه، بدون اجازه اتصال مستقیم به پایگاه. از همه این ها گذشته، مهمترین مسئله تو کارایی همونطور که عرض کردم، زمان هست. مسلما شکل هایی که در بالا بحث شد نگفته پیداست که در دراز مدت هزینه های کلانی رو به کارفرما (و گاهی هم به مجری اگه از پشتوانه محکمی در مقابل کارفرما برخوردار نباشه) تحمیل میکنه. باگ های بسیار زیادی که تو اینجور سیستم ها، مخصوصا تو دو تا قسمت همزمان سازی و توسعه و ارتقاء وجود دارند، قابل انکار نیستند. البته همه این ها همونطور که عرض کردم در صورتی به چشم میان که کارفرما درک درستی از کار داشته و حاضر باشه هزینه کافی (وافی بخوره تو سرشون، همون کافی هم برامون کافیه :چشمک:) رو بپردازه.
ببخشید از این که خیلی حرف زدم. موفق باشید.