PDA

View Full Version : آموزش: راهنمایی در مورد یک برنامه خاص



tomalaki
شنبه 26 اسفند 1391, 00:08 صبح
سلام اساتید.
یه برنامه ویندوز اپلیکیشن با دلفی دارم مینویسم که کارش ورود اطلاعات به یک پایگاه داده (MySQL) هست که بعضی از فیلدهای خاص جدول خاص اون پایگاه داده توسط یک وب اپلیکیشن به روز میشه. آیا راهی هست که اگه مقدار اون فیلد خاص جدول خاص تغییر کرد (مثلا اضاف شد یا UPDATE شد) توی برنامه ویندوزی به هر نحو (مثلا showmessege) متوجه شد؟ البته بدون اینکه برنامه ویندوزی هی بخواد پایگاه داده رو چک کنه. مثلا خود پایگاه داده یه دستوری چیزی بفرسته.

یه چیز حالت تریگر که اکه فعال شد یه پیام بفرسته به برنامه ویندوزی.

با تشکر:قلب:

tomalaki
شنبه 26 اسفند 1391, 00:21 صبح
خب تا اونجا که من فهمیدم نیاز من توی SQL Server با استفاده از CLR Trigger حل میشه. آیا همچین چیزی برای MySQL هست؟ یا اینکه توی ساختار برنامه ای که میخوام بنویسم تجدید نظر کنم؟

با تشکر

BORHAN TEC
شنبه 26 اسفند 1391, 12:08 عصر
سلام
در حالت کلی کارهایی از این دست با مکانیزم Callback انجام می شود ولی توجه داشته باشید که همه RDBMS ها به یک شکل ثابت این قابلیت را در درون خود پیاده سازی نکرده اند. من در مورد MySQL اطلاع ندارم که روش انجام این کار به چه شکلی است و یا اینکه اصلاً چنین قابلیتی دارد یا نه؟ :متفکر: ولی در مورد Firebird این قابلیت را می توان به سادگی با استفاده از Trigger ها و POST_EVENT پیاده سازی کرد. توجه داشته باشید که با کامپوننت های قدرتمند FireDAC (با نام قدیمی تر AnyDAC که محصول شرکت da-Soft بود و به تازگی Embarcadero خریدش) با چند خط کد می تونید از این قابلیت به ساده ترین شکل ممکن بهره ببرید. که نحوه انجام این کار در مورد Oracle و FireBird در صفحه زیر نشان داده شده است:
http://docs.embarcadero.com/products/rad_studio/firedac/frames.html?frmname=topic&frmfile=Database_Alerts.html
فقط توجه داشته باشد که داکیومنت مربوطه در مورد FireBird دو تا اشتباه جزئی داره. یکی از آنها مربوط به کدهای سمت دلفی است که بعد از آخرین خط از کد باید کد زیر را حتماً بنویسید:
qryCustomers.Active := True;
و دیگری کد مربوط به SQL است که کلمه AS رو یادش رفته بنویسه. به عبارتی به جای کد زیر :
CREATE TRIGGER TR_CUSTOMERS FOR CUSTOMERS
ACTIVE AFTER INSERT OR UPDATE OR DELETE
BEGIN
POST_EVENT 'Customers';
END;
باید از این کد استفاده کنید:
CREATE TRIGGER TR_CUSTOMERS FOR CUSTOMERS
ACTIVE AFTER INSERT OR UPDATE OR DELETE
AS
BEGIN
POST_EVENT 'Customers';
END;
موفق باشید...

tomalaki
شنبه 26 اسفند 1391, 15:07 عصر
استاد، اگه MySQL از مکانیزم آلرت پشتیبانی نکنه، به نظر شما کدوم دیتابیس برای کار با یک پروژه فروشگاه مناسب تر و سریع تر است؟ Firebird یا oracel؟

BORHAN TEC
شنبه 26 اسفند 1391, 15:29 عصر
این سوال شما خیلی کلی هستش. عوامل زیادی هست که دست به دست هم میده که از میان این همه RDBMS یکی رو انتخاب کنید. در این مورد به نظرم توجیهی نداره که بخواهید از ORACLE استفاده کنید. Oracle زمانی مناسب است که تعداد رکوردها از میلیارد تجاوز کند! بعید می دانم که در مورد فروشگاه این امر صادق باشد، از طرفی هم نگهداری Oracle نیاز به تخصص بالایی دارد و تعداد کسانی که از عهده این کار بر می آیند بعید میدانم که در ایران از عدد 100 تجاوز کند(تازه آن هم با خوشبینانه ترین حالت)! به نظر من FireBird گزینه خوبی است ولی به شرط اینکه از نسخه 2.5 به بعد استفاده شود. نسخه 3 آن که واقعاً فوق العاده است و مشکلات امنیتی را حل کرده است ولی فعلاً به صورت آزمایشی عرضه شده است و احتمالاً به زودی نسخه اصلیش میاد. در کل باید توجه داشته باشید که FireBird منبع آموزشی فارسی ندارد و استفاده از آن نیازمند این است که بتوانید با این موضوع به صورت کامل کنار بیایید. خوبی FireBird این است که همه چیز آن را می توانید با کد نویسی مدیریت کنید. استفاده از FireBird هزینه پشتیبانی را به شدت کاهش می دهد چون نیازی به مدیریت ندارد. از مزایای دیگر مهم آن پشتیبانی از udf است یعنی شما می توانید در دلفی یا C++‎ و یا ... تابعی را تعریف کنید و آن را به Firebird اضافه کنید و در دستورات SQL خودتون از اون تابع استفاده کنید(مثلاً تابعی برای تبدیل تاریخ میلادی به شمسی و ...)!!! توجه داشته باشید که FireBird رایگان است و اگر مشکلی را در آن ببینید سازندگان آن از شما تقاضای دلار نمی کنند! یکی از مزایای غیر مستقیم این محصول این است که اکثر ORM های مربوط به دلفی از آن پشتیبانی می کنند. در کل من فقط برخی از مزایای آن را نام بردم و انتخاب با شماست. اگر هم خواستید این پایگاه داده را برای کار انتخاب کنید من قبلاً در یک ویدئوی یک ساعته در مورد آن توضیح داده ام:
http://www.irstu.com/?p=7261
موفق باشید...

tomalaki
شنبه 26 اسفند 1391, 16:02 عصر
با تشکر از شما. آیا مشکلی برای کار کردن با PHP به وجود نمیاره و سازگاره؟

BORHAN TEC
شنبه 26 اسفند 1391, 16:29 عصر
با تشکر از شما. آیا مشکلی برای کار کردن با PHP به وجود نمیاره و سازگاره؟
آخه این سوالتون چه ربطی به موضوع بحث و کلاً بخش دلفی داره؟؟؟ :گریه:

tomalaki
شنبه 26 اسفند 1391, 17:31 عصر
البته حق دارید. ببینید، من یه سیستم میخوام راه بندازم که دو تا جنبه داره که به همدیگه ارتباط تنگاتنگی داره. یکی بحث دسکتاپ اپلیکیشن اون هست که قرار هست با دلفی نوشته بشه و اطلاعاتش هم به جای ذخیره توی پایگاه داده ی محلی، توی یک پایگاه داده در یک سرور ذخیره میشه و اطلاعات هم از همون پایگاه داده بازخوانی میشه. جنبه ی دوم این هست که روی اون سروری که پایگاه داده هست و اطلاعات دسکتاپ اپلیکیشن ذخیره میشه قراره یه وب اپلیکیشن هم بالا بیاریم که از اطلاعات اون پایگاه داده استفاده میکنه. این وب اپلیکیشن یه تراکنشی انجام میده و توی پایگاه داده اش ذخیره میکنه و باید یه پیامی، چیزی میزی هم به دسکتاپ اپلیکیشن هم بفرسته مبتنی بر اینکه توی اون جدول خاص یه رکورد اضاف شده. حالا من یه راه حلی به ذهنم که رسید این بود که این تاپیک رو زدم. که یه تریگر باشه که وقتی رکورد اضاف شد یه پیامی با کد دلفی درست کنه. اگه راه حلی دیگه به ذهنتون میرسه بگید. پروژه ی تجاریه، پول توشه :)

BORHAN TEC
شنبه 26 اسفند 1391, 22:16 عصر
آیا سرور شما یک سرور اختصاصی و یا یک سرور مجازی (vps) است؟

tomalaki
یک شنبه 27 اسفند 1391, 08:22 صبح
آره، باید باشه. فعلا با VPS شروع میکنیم، بعد سرور اختصاصی میگیریم. هر یک از برنامه های کلاینت ( که ویندوز اپلیکیشن هست) به این سرور وصل میشن، که ما اسمش رو میذاریم ترمینال. و تراکنشی که توی سایت توسط بازدیدکننده ها انجام میشه، مربوط به یکی از این ترمینال ها هست. میخوایم وقتی که اطلاعات یه تراکنش مربوط به یکی از این ترمینال ها توی پایگاه داده ثبت شد، یه هشدار، چیز، میز، هرچی، به سمت برنامه ترمینال بره و کاربری که پشت ترمینال نشسته ببینه که یه تراکنش انجام شده.

قبلا به شما برای مشارکت توی این پروژه پیام داده بودم، گویا شما وقت آزاد نداشتید :)

یوسف زالی
یک شنبه 27 اسفند 1391, 09:21 صبح
یک سوال، برنامه شما چند لایه هست؟
اگر بله؛ از لایه DAL یا حتی Business روی سرور می تونید یک پیغام Publish کنید.

BORHAN TEC
یک شنبه 27 اسفند 1391, 09:50 صبح
اگر بله؛ از لایه DAL یا حتی Business روی سرور می تونید یک پیغام Publish کنید.
ولی لایه ربطی به این موضوع نداره ها!!! لایه یک ماهیت منطقی است! اونی که ماهیت فیزیکی داره بهش میگن tier.

یوسف زالی
یک شنبه 27 اسفند 1391, 10:38 صبح
:لبخند:
منظورم همون بود.
به هر حال این هم روشی هست که می شه باهاش تا حدودی کار گفته شده رو انجام داد.
کامل نیست. بهینه نیست. دقیق هم نیست.

tomalaki
یک شنبه 27 اسفند 1391, 13:16 عصر
جالا به نظر شما من چه روشی استفاده کنم؟ میشه که یه تایمر توی برنامه ویندوزی به کار ببرم که هر 5 دقیقه یه بار یه کوئری بفرسته؟

یوسف زالی
یک شنبه 27 اسفند 1391, 13:23 عصر
من برای سیستم اس ام اس از تایمری استفاده کردم که میزان رفرش ریتش دست یوزره.
سیستم در ارتباط وب سرور هست و سورس وب سرور خارج از حیطه ما.
تایمر راه آخر هست.
اگر همه راهها بسته باشه دیگه چاره ای نیست.
اگر راهی پیدا نکردید می تونید یک DLL بگذارید رو سرور که مسئول دریافت درخواستهای کلاینت هاست (آی پی ها ولیده) این DLL دو تا کار می کنه، اول درخواست رو هندل می کنه بعد اگر لازم شد پیغامی رو BroadCast می کنه به کلاینت ها.
اگر امکان گذاشتن DLL ندارید می تونید به جای گرفتن کوئری های سنگین با تایمر، تریگرهایی رو روی جداول مهم بگذارید که هر وقت تغییری در اونها داده شد در یک جدول یک فلگ ست شه با نام جدول. می تونید حتی فیلد دیگه ای رشته ای بگیرید توش که کوئری مناسب اون اتفاق توشه.
حالا با تایمر فقط می رید اون جدول رو چک می کنید و اگر فلگی ست شده باشه کوئری مربوطه که توشه رو ران می کنید و فلگ رو ریست می کنید و باقی ماجرا ...

tomalaki
یک شنبه 27 اسفند 1391, 15:37 عصر
ممنون You-See. به نظر شما کدوم روش سرعت بیشتری داره و بار زیادی روی شبکه ی اینترنت به وجود نمیاره؟ آخه بحث اینترنت که بستر شبکه ی ما میشه برامون مهم هست. و اصلا میشه وب سرویس نوشت؟ هم روی سرور و هم روی کلاینت. و فقط بحث IP ولید میمونه که فکر کنم باید برای کاربرا IP ثابت بگیریم.

یوسف زالی
یک شنبه 27 اسفند 1391, 16:47 عصر
IP ولید گرفتن واسه کلاینت ها یجور خودکشیه!
اما اگر لازمه انجامش بدید. بهترین کار، البته بعد از CallBack همون استفاده از تایمر هست.
اگر آی پی گرفتید، می تونید از یک DLL استفاده کنید، استفاده از این روش دسترسی بیشتری روی سرور لازم داره و هزینه بالاتری هم داره. از این جهت که سرورها معمولا این اجازه رو نمی دن.
نظر شخصی من، با اجازه دوست عزیزم، استفاده از وب سرویسه. نمی دونم فناوری Ajax چقدر می تونه کمک کنه، اما به نظر میاد قضیه اول و آخر تایمره.
کافیه هر کلاینت یک درخواست در حد چند بایت بفرسته به سرور.
در سرور هم اگر روشی که گفتم رو پیش بگیرید داده های مینیمال بازگردونده می شند. یعنی اونچه واقعا بهش نیاز دارید.
تراکنش ها بهینه هست. تقریبا استقلال از نوع پایگاه داده و آی پی ها دارید.
صفحه بندی رو در گرفتن اطلاعات رعایت کنید.
روی سرور بار اضافی ای وجود نداره.
به نظر من به نسبت هزینه و توسعه راه حل منصفانه ای هست.

BORHAN TEC
یک شنبه 27 اسفند 1391, 16:57 عصر
فقط بحث IP ولید میمونه که فکر کنم باید برای کاربرا IP ثابت بگیریم.
کارتون واقعاً اشتباهه. اگر فقط سرور IP ولید داشته باشه کافیه! حتی یک کلاینت هم نیاز به IP ولید نداره. ارتباط کلاینت با سرور از طریق یک کانال است. حتی به واسطه یک سرور برنامه های کلاینت هم می توانند بدون کوچکترین مشکلی به یکدیگر اطلاعات ارسال کنند(مثل برنامه های چت).

نظر شخصی من، با اجازه دوست عزیزم، استفاده از وب سرویسه. نمی دونم فناوری Ajax چقدر می تونه کمک کنه، اما به نظر میاد قضیه اول و آخر تایمره.
بعید میدونم که به این کارها نیازی باشه! فکر می کنم که انجام این کار ساده تر از اونی باشه که تصور می کنی! الان یه چند تا تست در این رابطه انجام میدم و نتیجه رو همینجا می گم. خدا رو شکر vps هم برای تست دارم.

یوسف زالی
یک شنبه 27 اسفند 1391, 17:02 عصر
اگر فقط سرور IP ولید داشته باشه کافیه!


اصلا حواسم به نوشتن روی کانکشن کلاینت نبود! درسته. فقط سرور کافیه. ممنون.
شما چی پیشنهاد می کنید؟ Indy ؟

BORHAN TEC
یک شنبه 27 اسفند 1391, 17:26 عصر
شما چی پیشنهاد می کنید؟ Indy ؟
Indy یک مقدار delay بالایی داره و موقعی که ترافیک زیاد باشه خوب نیست. در کل پروتکل TCP اونطور که باید و شاید در Indy پیاده سازی نشده، البته این مورد در برخی موارد(ونه همه!) زیاد هم غیر عادی نیست چون از ابتدا در مورد Indy بحث Cross-Platform مطرح بوده که همین مورد یک مقدار برخی از قابلیتها رو میتونه کاهش بده چون همیشه باید اشتراکات سیستم عاملها رو باید در نظر می گرفتند. به عنوان مثال از آنجایی که اکثر سیستم عاملهای پشتیبانی شده توسط Indy از IOCP پشتیبانی نمی کنند سازندگان نتوانسته اند این مورد رو در INDY پیاده سازی کنند(تا اونجایی که من میدونم فقط ویندوز از IOCP پشتیبانی میکنه).در کل به نظر من استفاده از Indy جزو حاشیه های این بحث است و ارتباط مستقیمی با موضوع بحث ندارد. این دوستمون نگفت که امنیت این کلاینتها چقدر مهمه؟ خوب اگه مثلاً این کلاینتها دست چند کارمند باشه که فقط بخواهند به درخواست هایی که از کاربران سایت میرسه پاسخ بدهند انجام کار خیلی راحتتر میشه و اصلاً نیازی به استفاده از معماری Middle tier نیست ولی اگر دامنه استفاده از این کلاینتها به چند کارمند محدود نشه برای بالا بردن امنیت باید از Middle Tier استفاده بشه.
جناب tomalaki من یه چیزی رو متوجه نشدم. آیا این تغییرات در پایگاه داده فقط باید به اطلاع برنامه های کلاینت برسه یا تمام صفحات باز وب هم باید این تغییرات رو سریع متوجه شوند؟ به عبارتی کار صفحه وب فقط ثبت درخواستها است؟ آخه تا موقعی که این موارد کاملاً روشن نباشه نمیشه راه حل مناسبی رو ارائه داد و نمیدونم دقیقاً باید چی رو تست کنم.

tomalaki
یک شنبه 27 اسفند 1391, 17:38 عصر
با تشکر از شما اساتید که این موضوع رو پیگیری میکنید.

در پاسخ به دوستمون Object Pascal باید بگم که کارمندان هر ترمینال فقط یک نفر هست. یعنی یه اپراتور میشینه و تراکنش مربوط به خودش رو میبینه.
در مورد پرسش دوم هم باید بگم که تنها کار وبسایت ثبت درخواست هست و تنها به اطلاع ترمینال مربوطه (برنامه ی ویندوزی مربوطه) میرسه.
اگه اطلاع بیشتری میخواید باید توی پیام خصوصی بهتون بگم. و البته یه تعهد وجدانی و اخلاقی برای حفظ حقوق پدیدآورنده.

همونطور که گفتم این پروژه تجاریه و انشاالله بعد از اتمام اون یه جورایی جبران میکنم.

البته اینی که گفتید مثل برنامه ی چت میمونه من هم دقیقا داشتم به همین فکر میکردم.

یا یه مثال عملی تر، نمیشه این فروم رو کاریش کرد که وقتی پاسخی به پستی که دادم داده شد، یه هو یه messagebox وسط صفحه باز بشه و بگه که پاسخی به شما داده شد، بدون اینکه من اینترنت اکسپلورر رو باز کرده باشم.
مثلا الان من یه Add-in برای گوگل کروم دارم، وقتی برام یه ایمیل میاد بهم یه هشداری میده، بدون اینکه اصلا گوگل کرومی باز باشه. اما همیشه سرویسش توی task manager هست و بازه.

BORHAN TEC
یک شنبه 27 اسفند 1391, 23:34 عصر
در پاسخ به دوستمون Object Pascal باید بگم که کارمندان هر ترمینال فقط یک نفر هست. یعنی یه اپراتور میشینه و تراکنش مربوط به خودش رو میبینه.
در مورد پرسش دوم هم باید بگم که تنها کار وبسایت ثبت درخواست هست و تنها به اطلاع ترمینال مربوطه (برنامه ی ویندوزی مربوطه) میرسه.
اگه اینطوری باشه اون جوابی که در پست شماره 3 این تاپیک گفتم کاملاً مشکل شما رو حل می کنه. فقط کافیه که وبسایت شما اطلاعات رو در پایگاه داده ثبت کنه و با کد تریگری که قرار دادم این موضوع به اطلاع کلاینت میرسه و کارمند هم میتونه به اون درخواست پاسخ بده و اون رو در پایگاه داده ذخیره کنه و تمام. :چشمک:

tomalaki
چهارشنبه 30 اسفند 1391, 00:06 صبح
ممنون Object جان! خیلی کمکم کردی و بهترین راه حل رو بهم ارائه دادی. فقط یه راهنمایی دیگه میخوام.
این درست نیست که برنامه های کلاینت مستقیم با پایگاه داده در ارتباط باشن. آیا میشه یه سرویس ویندوز نوشت که تمام درخواست های کلاینت ها رو هندل کنه؟ و کار Notify کردن کلاینت ها رو هم انجام بده؟

با تشکر خیلی فراوان

BORHAN TEC
چهارشنبه 30 اسفند 1391, 10:04 صبح
این درست نیست که برنامه های کلاینت مستقیم با پایگاه داده در ارتباط باشن. آیا میشه یه سرویس ویندوز نوشت که تمام درخواست های کلاینت ها رو هندل کنه؟
اگه فقط چند کارمند با برنامه کلاینت سر و کار دارند ارتباط مستقیم مشکلی ندارد ولی برای برنامه هایی که به صورت انبوه عرضه می شوند حتماً و حتماً باید از یک tier میانی استفاده شود. البته انجام این کار با DataSnap خیلی راحته و قبلاً مقاله ای را در این خصوص در همین سایت قرار داده ام. در کل این مورد بستگی به خودتون داره ولی در حالت کلی همیشه بهتره که برای بالا بردن امنیت از یک tier میانی استفاده بشه، چون همه کارمندان هم قابل اعتماد نیستند و معمولاً همه کارمندان هم مجوز های یکسان برای دسترسی به پایگاه داده ندارند(البته در برنامه شما نمیدونم که اینطور هست یا نه؟!).
http://barnamenevis.org/showthread.php?290914

آیا میشه یه سرویس ویندوز نوشت که تمام درخواست های کلاینت ها رو هندل کنه؟ و کار Notify کردن کلاینت ها رو هم انجام بده؟
بله، اگه همون مقاله رو بخونید و کمی هم تحقیق کنید نحوه کار دستتون میاد. چون DataSnap امکان ایجاد tier را به صورت یک سرویس ویندوزی را هم دارد.

tomalaki
چهارشنبه 30 اسفند 1391, 11:00 صبح
خیلی گُلی آقا Object. کارمندان ما آنچنان نیستند. روش فکر میکنم، اگه دیدم فعلا به صرفه نیست فعلا ازش استفاده نمیکنم. و یا شاید هم توی فازهای توسعه سیستم بعدا ازش استفاده کردم.
با تشکر از شما
سال خجسته ای براتون آرزومندم.