جلوگیری از ویرایش یک رکورد تو سط چند تا کلاینت

[MTPROG]

- اگر مورد بالا برای شرایط کاری برنامه منطقی نیست و باید هر نوع شماره های خودش را داشته باشد، خوب فیلد شماره فاکتور را با جفت State با هم UniqueIndex معرفی کنید.

فیلد State میتونه تکراری باشه چون هرچی فاکتور فروش وارد بشه این فیلد مقدار 0 میگیره ، برگشت از فروش مقدار 1 و الی آخر
البته اگر با فیلدIdFactor با هم مقایسه بشن تکراری نمیشه مثلا ممکن نیست دو تا شماره فاکتور یکسان State یکسان داشته باشن
با UniqueIndex کردن فیلد State مشکلی به وجود نمیاد؟

یه سئوال دیگه:
تو بعضی از توابع برنامه ام پیش میاد که 3 تا 4 دستور INSERT,DELETE,UPDATE انجام میشه که اینها رو پشت سر هم انجام میدادم مثلا اول دستور DELETE بعد INSERT و بعد UPDATE
بعضی مواقع مشکلاتی به وجود میامد که دو مرحله DELETE,INSERT انجام میشد ولی تو UPDATE دچار مشکل میشد(حالا به هر دلیلی)
تو این حالت اطلاعات دچار مشکل میشد چون یه مرحله از کار انجام نشده بود

چطور میشه کاری کرد که این دستورات یا همه اجرا بشن یا هیچکدوم ؟

[_H2_]

سلام

البته اگر با فیلدIdFactor با هم مقایسه بشن تکراری نمیشه مثلا ممکن نیست دو تا شماره فاکتور یکسان State یکسان داشته باشن

خوب منظور من همین بود.
منطقی است شرایط برنامه شما طوری باشد که State و IdFactor شما هر کدام جداگانه تکراری باشند ولی دیگر منطقی نیست هر دو با هم و جفت تکرار شوند و حتماً در کنارهم منحصر به فرد خواهند بود و باید برای سرعت و جلوگیری از تداخل یکتا اعلام شوند.

... شماره فاکتور را با جفت State با هم UniqueIndex معرفی کنید

چطور میشه کاری کرد که این دستورات یا همه اجرا بشن یا هیچکدوم ؟

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

(
شما خودتان یک ذهنیتی دارید برای کسی که لزوم "همه یا هیچ" را درک نمیکند، مثال ساده ای میزنم تا تداخلش را درک کند:

پولی را میخواهید ااز یک حساب به حساب دیگر منتقل کنید.
در ساده ترین شرایط ممکن و با کمترین عملیات دو کار لازم است...
1) کسر پول از حساب مبداً و 2) افزودن پول به حساب مقصد
حالا فرض کنید کار نیمه انجام شود و فقط یکی از دو عمل فوق موفقیت امیز اجرا شود!
چه میشود؟
اگر 1) انجام شود و 2) انجام نشود (کاری به دلیلش نداریم، به هر دلیل!) پول حقیقی که قبلاً وجود داشته و مالکیت داشته در رایانه از بین میرود

اگر 2) انجام شود و 1) انجام نشود، پولی که وجود نداشته و مالکی ندارد و پشتوانه ای ندارد در رایانه خلق میشود و به وجود می آید.

پس اجرای عملیات فوق مستلزم "همه یا هیچ" است.
)

راه حل:
خوشبختانه اکثر بانکهای اطلاعاتی موجود این عملیات ها را خودشان پشتیبانی میکنند.
در T-SQL با دستورات BEGIN TRAN و COMMIT TRAN و ROLLBACK TRAN میتوانید تراکنش ها را ایجاد و مدیریت کنید.

برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید

ولی برای حالت عادی و معمول پیشنهاد میکنم تمام عملیات هایتان را (برای سرعت و شفافیت و قابلیت نگه داری) در بانک یک SP کنید و از دستورات فوق در آن استفاده کنید.

(یا در خود دات نت هم میتوانید با کلاس System.Data.SqlClient.SqlTransaction مشبه عمل فوق را انجام دهید.)

[MTPROG]

خیلی جالب است، خیلی!!!!
شما حتی لفظ برنامه نویسی اش را هم نمیدانید اما دقیقاً دارید جملاتی را میگویید که برنامه نویسان گذشته دقیقاً همین جملات را تکرار کرده بودند و طراحان بانکهای اطلاعاتی رابطه ای هم با ان دست به گریبان بودند.

نمیدونم تیکه پروندی یا نصیحت کردی! به هر حال بگذریم

در T-SQL با دستورات BEGIN TRAN و COMMIT TRAN و ROLLBACK TRAN میتوانید تراکنش ها را ایجاد و مدیریت کنید.


کد:
BEGIN TRAN T1;--...--... any t-sql ...--... if error then "ROLLBACK TRAN T1;"--...COMMIT TRAN T1;

قبلا یکی دو مثال از این روش که توسط خود SQL درست شده بود دیدم ولی این روش رو فقط تو خود محیط SQL میشه اجرا کرد و نمیشه تو محیط VS به SQL فرستاد من میخوام تمام دستورات بانکی رو از برنامه به بانک بفرستم

شما خودتان یک ذهنیتی دارید برای کسی که لزوم "همه یا هیچ" را درک نمیکند، مثال ساده ای میزنم تا تداخلش را درک کند:

پولی را میخواهید ااز یک حساب به حساب دیگر منتقل کنید.
در ساده ترین شرایط ممکن و با کمترین عملیات دو کار لازم است...
1) کسر پول از حساب مبداً و 2) افزودن پول به حساب مقصد
حالا فرض کنید کار نیمه انجام شود و فقط یکی از دو عمل فوق موفقیت امیز اجرا شود!
چه میشود؟
اگر 1) انجام شود و 2) انجام نشود (کاری به دلیلش نداریم، به هر دلیل!) پول حقیقی که قبلاً وجود داشته و مالکیت داشته در رایانه از بین میرود

اگر 2) انجام شود و 1) انجام نشود، پولی که وجود نداشته و مالکی ندارد و پشتوانه ای ندارد در رایانه خلق میشود و به وجود می آید.

پس اجرای عملیات فوق مستلزم "همه یا هیچ" است

خوب این هم دقیقا شبیه همون مثال منه

(یا در خود دات نت هم میتوانید با کلاس System.Data.SqlClient.SqlTransaction مشبه عمل فوق را انجام دهید.)

این بیشتر به درد میخوره ولی باهاش کار نکردم اگه میشه یه کم درباره ش توضیح بدید

[_H2_]

سلام

نمیدونم تیکه پروندی یا نصیحت کردی!

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

... ولی این روش رو فقط تو خود محیط SQL میشه اجرا کرد ...

بله برای این مورد طراحی شده ولی همینطوری در کد هم قابل استفاده است (که چندان جالب نیست)
ولی حالا استفاده فققط در SQL و در طی دستورات T-SQL مشخص در SP های مشخص چه ایرادی دارد؟؟؟

به نظر من که (خارج از بحث فوق) هر چه بتوان برنامه را به لایه های مجزا تفکیک کرد و کلاً دستورات SQL را از بیخ و بن از درون کدها حذف کرد و به خود دیتابیس منتقل کرد خیلی بهتر است.
باعث شفافیت بیشتر و افزایش اصل نگه داری و سرعت دیباگ و بازدهی و سرعت بیشتر برنامه خواهد شد.

این بیشتر به درد میخوره ولی باهاش کار نکردم اگه میشه یه کم درباره ش توضیح بدید

نمونه کد:
msdn.microsoft.com/en-us/library/system.data.sqlclient.sqltransaction.aspx

[MTPROG]

ه نظر من که (خارج از بحث فوق) هر چه بتوان برنامه را به لایه های مجزا تفکیک کرد و کلاً دستورات SQL را از بیخ و بن از درون کدها حذف کرد و به خود دیتابیس منتقل کرد خیلی بهتر است.
باعث شفافیت بیشتر و افزایش اصل نگه داری و سرعت دیباگ و بازدهی و سرعت بیشتر برنامه خواهد شد.

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

نمونه کد:
msdn.microsoft.com/en-us/library/system.data.sqlclient.sqltransaction.aspx _

کد خیلی عالی و واضحیه ممنون

[_H2_]

سلام

امنیت سورسهات پایین نمیاد؟

اخه چی را میخواهید لو نرود؟؟؟ یک دستور SQL ای DELETE یا UPDATE یا ...
به نظر شخصی من با وجودی که زبان TSQL کلمات و امکانات زیادی دارد ولی ارزش خاصی ندارد.

من لایه بندی و شفافیت کدها و نیز توسعه آینده ساده تر و اشکال یابی و رفع باگ سریعتر و سرعت بیشتر برنامه را ترجیح میدهم به اینکه کسی نتواند TSQL های من را ببینید!

کدهای قاطی و اسپاگتی وار میتواند در زمان رفع ایراد چالش جدی ایجاد کنند و خود برنامه نویس هم سردرد بگیرد که بین صفحات کدش جا به جا شود بعد هم هر بخش را دستکاری میکنید جای دیگر خراب میشود ، من وقتی برخی کدهای افراد را میبینیم از درهم بودن کدها و قاطی پاتی بودن بخش ها (فقط از دیدنش) دچار سردد میشوم! خدا صبر بده به برنامه نویش!

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

تازه SP ها چون ثابت در داخل خود SQLServer هستند، هسته مرکزی آنها را بهینه سازی میکند و مسیرهای ایندکسی لازم و عملیات های مورد نیاز را قبلاً پردازش کرده و ذخیره میکند.
یک حالتی شبیه یک نوع نیمچه کامپایل!

در حالی که دستورات SQL عادی شما string خالص هستند و تازه باید بروند و پردازش متنی شوند و بعد ...

=====

چون استفاده نمیکنم، فراموش کرده ام ولی گمانم SQLServer امکانی برای حفاظت و عدم رویت کدهای SQL داخل SP هایش داشته باشد.
در msdn جستجو کنید شاید پیدایش کنید.

آیا کاملا جوابگو هستش

شما باید تا حد امکان و تا جایی که میتواند SP هایی برای کارهای مختلفتان ایجاد کنید که طبیعتاً پارامترهایی بگیرند و کاری انجام دهند که میتواند موارد ساده تا پیچیده را شامل شود!
مثلاً به همین سادگی:

برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید

بعد دیگر اگر در جای خیلی خاص و ویژه ای نمیشد کاری کرد که دستور SQL حتماً از قبل مشخص و واضح باشد و پارامتری مقدار بگیرد، دیگر ناچاراً میتوانید از سایر روشها استفاده کنید.

موفق باشید.

[MTPROG]

اخه چی را میخواهید لو نرود؟؟؟ یک دستور SQL ای DELETE یا UPDATE یا ...

همه کارها یک DELETE یا UPDATE نیستند بعضی ها گزارشهای مهمی هستند که نیاید هیچ جا درز بشه

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

البته تا حدی هم حق با شماست اگر کاربر میخواد اطلاعتش سالم بمونه نزاره کسی بره پشت سرورش
ولی در عوض سرعت کارش بالا میره و همون بقیه مثالی که شما ذکر کردید

تا حالا چندتا نرم افزار تحت شبکه که تو ایران اسم و رسمی به هم زدن دیدم و سر بانکشون رفتم هیچکدوم از SP,View و سایر موارد دیگه تو بانک میشه انجام داد استفاده نکردن گفتم شاید حتما ارزشو داره که تمام کارهاتو تو خود برنامه انجام بدی!

[_H2_]

سلام

همه کارها یک DELETE یا UPDATE نیستند بعضی ها گزارشهای مهمی هستند که نیاید هیچ جا درز بشه

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

حاضر بود 10 میلیون پول بابت اون بکاپ رقیب تجاریش بده

تاجایی که من یادم می آید بحث ما سر دستورات SQL بود که داخل برنامه String بماند یا در بانک به صورت SP و View و ... باشد.
من واقعاً مثال شما را نمیتوانم با بحث خودمان تطبیق دهم.
من که نگفتم اطلاعات را محافظت نکنید! یا فایل backup را فشرده و رمزنگاری نکنید! اتفاقاً در سایزهای معقول فشرده سازی و رمزنگاری فایلهای پشتیبان به نظرم کار خوبی است.

البته تا حدی هم حق با شماست اگر کاربر میخواد اطلاعتش سالم بمونه نزاره کسی بره پشت سرورش

شما میتوانید برنامه های ویرایشی SQLServer را برای رایانه مقصد نصب نکنید که از جمله مهم ترین این ابزار SSMS است.
برای ورود به برنامه و اتصال به دیتابیس هم رمز عبور تایین کنید.
بارها گفتم امنیت SQLServer بسیار دقیق و گسترده و کامل است ولی پیشفرض ان امنیت فیزیکی دسترسی به سرور است.

اگر به فکر این هستید که فردا آمدند و کیس را یک تکه دزدیدند، باز هم اطلاعات درز نکند (!!!) دیگر باید اطلاعات را داخل دیتابیس رمزنگاری کنید!
اگر فکر میکنید کار به دزدیدن کیس نمی انجامد شاید نیازی به رمزنگاری نباشد و تدابیر دیگر ویندوزی و دیتابیسی کافی باشد.
ولی این مطلب بازهم ارتباطی با دستورات SQL و بهینه سازی و لایه بندی انها ندارد.

تا حالا چندتا نرم افزار تحت شبکه که تو ایران اسم و رسمی به هم زدن دیدم و سر بانکشون رفتم هیچکدوم از SP,View و سایر موارد دیگه تو بانک میشه انجام داد استفاده نکردن گفتم شاید حتما ارزشو داره که تمام کارهاتو تو خود برنامه انجام بدی!

من هم تا حالا برنامه های دسکتاپی و وبی ایرانی اسم درکرده و معروف زیادی دیده ام و به جرآت میگویم که اگر من میخواستم نمره دهم از بیست نمره با بالای 6 یا 7 نمیدادم.
خودم یک سایت پر ادعای ایرانی طراحی شده میشناسم (و برنامه نویسش را نمیشناسم) ولی حاضر فتوا دهم برنامه نویسش برخلاف کلاس و ادعا و پز سایت مطلقاً سواد برنامه نویسی نداشته.
(
قبلاً هم در تاپیک دیگری گفتم، ماشا ا... برنامه نویسان ایرانی (دور از جون دوستان عزیز این سایت ) فقط اینقدر وقت میکنند که اول Caption فرم را حذف کنند و یک و بعد هم یک عکس منظره بیاندازند تنگ فرم بعد هم دکمه های را دایره ای کنند و با حرکت ماوس استایل دکمه بین نقره ای و بلورین و طلایین سوییچ کند، دیگر گمانم وقتی برایشان نمیماند که برنامه نویسی لایه بندی شده و شی گرایانه و اصولی انجام دهند و دیتابیس را نرمال کنند و اصول کدنویسی قابل نگه داری طولانی مدت و کد نویسی با بازده و سرعت بالا و کدهای مناسب چند ریسمانی و شبکه و... و... و... را یادبگیرند و پیاده سازی کنند.
)

=====

مجدد تاکید میکنم که فقط از جهت محافظت از سورس کدها شاید شاید شاید شاید شاید منطقی باشد برخی دستورات SQL محافظت شوند که در این صورت هم ...
1) باز باید سرعت و بازدهی برنامه و رضایتمندی سفارش دهنده را مد نظر داشت
2) همانطور که گفتم احتمال دارد SQLServer امکاناتی در جهت محافظت از سورس های SQL اجزای خودش داشته باشد ولی آلان چیزی یادم نمی آید و فرصت خالی کافی برای بررسی در msdn را ندارم.

موفق باشید.

[MTPROG]

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

تو گزارشهای پیچیده دیدن جدول اصلا مهم نیست چون اطلاعت اون جداول به علت ارتباط چند به چند شامل فیلدهای عددی نا مفهوم است و با دیدن این جداول هیچ چی دستگیر کسی نمیشه ولی با اجرای View,SP های اماده اطلاعات مهم فاش میشه

تاجایی که من یادم می آید بحث ما سر دستورات SQL بود که داخل برنامه String بماند یا در بانک به صورت SP و View و ... باشد.
من واقعاً مثال شما را نمیتوانم با بحث خودمان تطبیق دهم

بحث سر امنیت نمایش اطلاعات هستش چرا تطبیق نداره الان چه بکاپ ببره چه بره سر بانک وقتی SP و View اماده است کار تمومه
اصلا بحثی هست به نام SQL Injection که هکر میتونه تو شبکه یا تو اینترنت با تزریق دستوراتی به SQL SERVER دستورات SP و View رو بدست بیاره و اونو اجرا کنه و اطلاعاتو بکشه بیرون (بالاخره SQL هم هر چقدر قوی باشه بازم جای ضعف داره)
PDF زیر توضیحاتی درباره SQL Injection نوشته

برای مشاهده محتوا ، لطفا وارد شوید یا ثبت نام کنید

حالا شاید بگید کی میتونه این کارو بکنه ولی بهتر نیست که خودمونو با اصولی ترین روش و بهینه ترین روش که کمترین ایراد رو داشته باشه تطبیق بدیم
(تا به قول شما مثل بعضی برنامه نویسان ایرانی پر مدعا و بی سواد نشیم! )(جنبه شوخی داشت)

[_H2_]

سلام
بحرحال من فقط و فقط یک روش برای حفاظت از دیتاهای شبکه های مبتنی بر SQLServer بلد هستم که بسیار قوئی است.
1) SQLServer را در رایانه سرور و با ترجیحاٌ یک user و pass نصب میکنیم
2) برای اتصال به SQLServer مفاهیم login و user و pass با اختیارات معلوم و به حد لازم محدود شده تعریف میکنیم.
3) برای اکانت های administrator یک password محکم و سری میگذاریم.
4) برای اطمینان نهایی و صد در صد اتاق سرور را از نظر امنیتی از سایر بخش ها ایزوله میکنم و یک چندتایی قفل خفن به دربش میزنیم!

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

این خط مشی استاندارد امنیتی به راحتی در یک سازمان و اداره قابل انجام و پیاده سازی است.

برای موارد کوچک تر هم میتوان از مورد 4) صرف نظر کرد ولی دیگر باید بخش های رایانه password داشته باشد.
(منظورم password واقعی است، نه اینکه میوه فروشی سر کوچهه هم password را بداند و فقط بماند خواجه حافظ شیرازی مظلوم !)

=====

اما اگر میخواهید برنامه را عمومی بفروشید و در جهت امنیت کدها و اینکه برنامه نویس دیگری نتواند برود CD برنامه شما را بخرد و روش شما را تجزیه کند و از ان کپی کند، من راحتان کنم که کمکی نمیتوانم بکنم.
(که گمانم نگرانی شما از این جهت است)

خود من شخصاً به این موارد اهمیتی نخواهم داد و معتقدم صرف لو رفتن جداول و ساختار ها و یک دیتابیس عادی نرمال شده نمیتواند امنیت کپی رایتی محصول من را در قبال سایر برنامه نویسان و رقبا کاهش دهد.


یعنی اگر نگرانی امنیتی به معنای واقعی ان دارید با روشهای صحیح قابل حل است ولی اگر خیلی نگرانی لو رفتن ساختار دیتابیس و ارتباط جداول را دارید، دستورات SQL را داخل برنامه مستقر کنید!

=====

اصلا بحثی هست به نام SQL Injection

1)
من هنوز PDF شما را دانلود نکرده ام ولی با این مورد کاملاً آشنایی دارم و تضمین 100% میدهم اگر کد نویسی اصولی و منطقی انجام دهید و همه موارد و اصول برنامه نویسی را رعایت کنید هیچ مشکلی پیش نمی آید.

2)
ضمن اینکه بحث وجود SP و View و... هم هیچ تاثیر بد و خوبی روی مورد فوق ندارد و من ان را در بحث جاری مان چندان مرتبط نمیبینم.

=====

موفق باشید.