چالشی با نام "برنامه تحت ویندوز، بانک تحت وب"

[p_ooya]

سلام به همه. اگر اینجا جای مناسبی برای این سوال نیست، ببخشید. واقعاً جای مناسبتری پیدا نکردم. سوال من بیشتر جنبه درخواست مشاوره داره و پیشاپیش از راهنمایی شما ممنونم.

من یه برنامه تحت ویندوز نوشته ام که بانکش قراره روی یه هاست قرار بگیره و حدود 10 نسخه از این نرم افزار قراره که با این بانک Mysql کار کنند. چند مسئله در این باره ذهن منو مشغول کرده که به صورت مختصر شرح میدم :


وقتی قراره این (حداکثر) 10 برنامه به بانک از راه دور وصل بشن، آیا ارتباطشون، ارتباط با کیفیته؟ به خاطر توان پایین، آیا هاست های ایرانی اجازه تعداد زیاد کانکشن راه دور به بانکشون رو میدن؟ (مثلاً نیاد بگه فقط 5 کانکشن !)
ارسال (مثلاً) 100 رکورد با 10 فیلد، چقدر زمانبر خواهد بود. دریافت این تعداد رکورد در قالب یه کوئری چطور؟
مشکلات قطع ارتباط و گم شدن بسته های داده سایر مسائل شبکه خیلی مسئله سازه؟

همونطور که می بینید مشکل اصلی من در نهایت کیفیت یه همچین ارتباطیه. به زبان دیگه آیا این روش قراره که منو خیلی آزار یده یا روش متداول و امتحان پس داده ایه؟
به دلایل خاصی نمی تونم از یه سیستم مبتنی بر وبسایت استفاده کنم یا یه سرور تهیه کنم و تنها راه حلم همینه. از اینکه بیش از یک سوال در تاپیک مطرح شد پوزش، اما چاره دیگه نیست وقتی حتی نمی دونم سوالم تو تاپیک مناسب مطرح شده یا نه.

سپاس.

[vcldeveloper]

وقتی مشخص نیست این 10 کلاینت قرار هست چه نوع ارتباط اینترنتی (با چه سرعتی) داشته باشند، و معلوم هم نیست که حجم هر رکورد ذخیره شده در بانک شما چقدر هست، انتظار دارید چه نوع جوابی دریافت کنید؟!

[p_ooya]

وقتی مشخص نیست این 10 کلاینت قرار هست چه نوع ارتباط اینترنتی (با چه سرعتی) داشته باشند، و معلوم هم نیست که حجم هر رکورد ذخیره شده در بانک شما چقدر هست، انتظار دارید چه نوع جوابی دریافت کنید؟!
اگر اطلاعات ناقصه ببخشید. مسئله من بیشتر راجع به مشکلات یه همچین استراتژی بود و اینکه اصولاً این روش تا چه حد قابل اطمینانه. اما به روی چشم :
اکثر این 10 کلاینت از ADSL 256 یا بالاتر استفاده می کنند. رکوردهای جدولی هم که بیشترین تراکنش رو با بانک دارند، به صورت زیر هستند :

`serial` char(14) COLLATE utf8_persian_ci NOT NULL (PK)
`archive_number` tinyint(3) unsigned NOT NULL
`da_f` char(10) COLLATE utf8_persian_ci DEFAULT NULL
`da_p` char(10) COLLATE utf8_persian_ci NOT NULL
`da_s` char(10) COLLATE utf8_persian_ci DEFAULT NULL
`state` tinyint(3) unsigned NOT NULL
`s_id` int(10) unsigned DEFAULT NULL (FK)و

`id` int(10) unsigned NOT NULL AUTO_INCREMENT,
`buyer` varchar(30) COLLATE utf8_persian_ci NOT NULL,
`date_d` date COLLATE utf8_persian_ci DEFAULT NULL
`comments` varchar(100) COLLATE utf8_persian_ci DEFAULT NULL
`u_1` varchar(30) COLLATE utf8_persian_ci NOT NULL,
`u_2` varchar(30) COLLATE utf8_persian_ci DEFAULT NULL,
`d_1` char(10) COLLATE utf8_persian_ci NOT NULL,
`d_2` char(10) COLLATE utf8_persian_ci DEFAULT NULL,
`ca_no` varchar(14) COLLATE utf8_persian_ci DEFAULT NULL,
`comments_2` varchar(300) COLLATE utf8_persian_ci DEFAULT NULL,
`sold` char(10) COLLATE utf8_persian_ci DEFAULT NULL
`last_modified` datetime NOT NULL,
`user_f` varchar(30) COLLATE utf8_persian_ci DEFAULT NULL
PRIMARY KEY (`id`)مجموعه اول بیشتر insert داره و سوال من در رابطه insert کردن 100 رکورد مربوط به همین مجوعه است.
مجموعه دوم insert ها پرس و جو های خیلی کمی داره (مثلاً 10 تا تک رکورد insert و 20 پرس و جو در روز) و پرس و جو هایی که روش انجام میشه معمولاً نتایج 50 تا 60 رکوردی داره. این توضیح رو هم بدم که دو تا فیلد comments که با سقف 300 تعریف شده اند معمولاً بیش از 70،80 کاراکتر ندارند.
همه جدول ها هم از نوع innodb هستند.

[vcldeveloper]

اکثر این 10 کلاینت از ADSL 256 یا بالاتر استفاده می کنند.
موردی نداره. جدول اول شما به ازاء هر رکورد حداکثر 60 بایت استفاده میکنه که اگر در 100 ضرب بشه، میشه 6000 بایت (یعنی 6 کیلوبایت). حتی اگر فرض بگیریم که مقداری سربار داده هم به این اضافه میشه، باز هم این حجم از داده باید با اتصالی با سرعت 256کیلوبیت در کسری از ثانیه ارسال بشه.

[p_ooya]

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