جلوگیری از ثبت مقدار تکراری در database

[salimi24]

سلام علیکم.
من یه پروژه دفترچه تلفن با سی شارپ 2013 و دیتابیس Sql server 2012 نوشتم.ام یه مشکلی داره.
هنگام ایجاد جدول در اسکیو ال شماره (موبایل 1) را به عنوان گلید در نظر گرفتم.
حالا می خواهم درون سی شارپ در رویداد Leav (تکس باکس موبایل 1) کدی بنویسم که قبل از ثبت چک کنه ببینه اگر چنین شماره موبایلی در جدول قبلا ثبت شده به کابر پیغام بده که فردی قبلا با این شماره موبایل در جدول ثبت شده.
.
.
.
کسی می تونه کمکم کنه؟؟؟
.
.
کد ذخیره اطلاعات وارد شده توسط کاربر هم بدین صورت نوشتم.

 

SqlConnection cn = new SqlConnection();

cn.ConnectionString = @"Data Source=(local);Initial Catalog=PhonBook;Integrated Security=True";

cn.Open();

 

SqlCommand cmd = new SqlCommand();

cmd.Connection = cn;

cmd.CommandText = @"insert into tblPhone(tname,tfamily,tfather,tdate,tmobile1,tmob  ile2,ttel,tfax,ttype,tpost,tadres,temail,ttozih) values('" + txtName.Text + "','" + txtFamily.Text + "','" + txtFather.Text + "','" + txtYear.Text + "/" + txtMounth.Text + "/" + txtday.Text + "','" + txtMobile1.Text + "','" + txtMobile2.Text + "','" + txtTell.Text + "','" + txtFax.Text + "','" + comboBox1.Text + "','" + txtPost.Text + "','" + txtAdress.Text + "','" + txtEmail.Text + "','" + txtTozih.Text + "')";

cmd.ExecuteNonQuery();

cn.Close();

 

Namayesh();

labelresuilt.Text = "با موفقیت ثبت شد";

[ahmad.jafery]

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


برو حالشو ببر

[AmiN0012]

datatable datatable1=new datatable();

string str="select mobilenumber from table1 where mobilenumber ="+textboxmobile.text;

connection.open();

sqldataadapter da=new sqldataadapter(str,connection);

da.fill(datatable1);

connection.close();

if(datatable1.rows.count>0)

{

messagebox.show("tekrari ast shomare mobile");

return;

}

else

{

//insert

}

سلام دوست من تو نوت پد نوشتم برات خودت ردیفش کن تو سی شارپ

[salimi24]

سلام.
خیلی ممنون از پاسخ تون.
من برنامه را به همون صورتی که گفته بودید نوشتم ولی به خط (da.Fill(dt که می رسد خطا می دهد.
که عکس این خطا را هنگام اجرای برنامه پیوست این پست کردم.

Salimi24.jpg

[ASKaffash]

سلام
جلوی دستور Select هیچ چیزی نیست

[شهابسلطانی]

باید مینوشتید
select * from
شما علامت '''' * ''''' رو فراموش کردید

[leila2204]

سلام
من دستور شما در مورد تکراری بودن رو اجرا کردم و برای حروف انگلیسی مشکلی نداره ولی وقتی حروف فارسی باشه خطا روی دستور زیر میده
da.fill(dt)

[leila2204]

اینم عکس حطا



khata.jpg

[رامین مرادی]

کوئریتون مشکل داره. نام ستون رو پیدا نمیکنه

[danialafshari]

قبلا هم گفتم بازم میگم اگر چیزی رو سمت SQL Server میشه هندل کرد، هندل کنید
کافیه اون فیلد رو Unique قرار بدید و هندل کنید و پیام مناسب نمایش بدید

[sds1920]

قبلا هم گفتم بازم میگم اگر چیزی رو سمت SQL Server میشه هندل کرد، هندل کنید
کافیه اون فیلد رو Unique قرار بدید و هندل کنید و پیام مناسب نمایش بدید

اتفاقا من با این دیدگاه کاملا مخالفم. هر چیزی رو که میتونید، بهتره سمت برنامه هندل کنید دلیلش هم فقط یک چیزه و اونم Unit Test هست.
اگر قرار باشه پروژه ای استاندارد باشه باید براش تست نوشته بشه و زمانی که قرار تست نوشته بشه باید همه چیز جوری نوشته شده باشه که تحت کنترل برنامه باشه. باید وابستگی برنامه به بیرون کم بشه و از پراکنده شدن Business برنامه جلوگیری کرد. پس از دوستانی که علاقه شدیدی به پردازش ها سمت دیتابیس دارن باید بخوام این دیدگاهشون رو عوض کنن. امروز بهتر از فرداست.
در دنیای امروز دیتابیس حکم یک گونی رو داره که فقط اطلاعات داخلش میریزن. بیشتر از این دیتابیس معنا و مفهومی نداره.
برای درک بهتر حرف هایی که زدم به دوستان پیشنهاد میکنم کتاب The Art of unit testing رو مطالعه کنن. این کتاب میتونه رو دیدگاه شما تاثیر مثبتی داشته باشه

[رامین مرادی]

اتفاقا من با این دیدگاه کاملا مخالفم. هر چیزی رو که میتونید، بهتره سمت برنامه هندل کنید دلیلش هم فقط یک چیزه و اونم Unit Test هست.
اگر قرار باشه پروژه ای استاندارد باشه باید براش تست نوشته بشه و زمانی که قرار تست نوشته بشه باید همه چیز جوری نوشته شده باشه که تحت کنترل برنامه باشه. باید وابستگی برنامه به بیرون کم بشه و از پراکنده شدن Business برنامه جلوگیری کرد. پس از دوستانی که علاقه شدیدی به پردازش ها سمت دیتابیس دارن باید بخوام این دیدگاهشون رو عوض کنن. امروز بهتر از فرداست.
در دنیای امروز دیتابیس حکم یک گونی رو داره که فقط اطلاعات داخلش میریزن. بیشتر از این دیتابیس معنا و مفهومی نداره.
برای درک بهتر حرف هایی که زدم به دوستان پیشنهاد میکنم کتاب The Art of unit testing رو مطالعه کنن. این کتاب میتونه رو دیدگاه شما تاثیر مثبتی داشته باشه

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

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

[sds1920]

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

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

تا حدودی با نظر شما موافقم ولی در حجم اطلاعات دارید یکم زیاده روی میکنید و از 1 میلیون رسیدید به 500 میلیون.
برنامه ای که بخواد هر بار این حجم از اطلاعات رو پردازش کنه نیاز به یک ابر کامپیوتر داره ولی شاید بهتر باشه بگم برنامه نویسی که اینجور برنامه ای بخواد بنویسه رو باید بهش حبس ابد داد. همه ما تجربه کار با دیتای بزرگ رو داشتیم. من الان با دیتا بیسی کار میکنم که حدود 130 گیگ اطلاعات غیرگرافیکی داخلش هست ولی در 1درصد مواقع هم نیازی به چنین پردازشی نداشتم و ندارم. ولی در کل شاید ماهیت پروژه جوری باشه که در چند مورد خاص نیاز به چنین کاری باشه و منم هم منکرش نیستم. به همین خاطر گفتم "

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

در مورد امنیت هم باید بگم من و شما برنامه نویس نباید نگران امنیت داده ها توی شبکه باشیم. اونی که باید نگران باشه مسئول شبکه و امنیت هست. در ضمن برای جلوگیری از این مورد به راحتی میتونید برای SQL Server یک گواهینامه SSL تعریف کنید تا اطلاعات توی شبکه قابل دستیابی نباشه.

[c0mmander]

اتفاقا من با این دیدگاه کاملا مخالفم. هر چیزی رو که میتونید، بهتره سمت برنامه هندل کنید دلیلش هم فقط یک چیزه و اونم Unit Test هست.
اگر قرار باشه پروژه ای استاندارد باشه باید براش تست نوشته بشه و زمانی که قرار تست نوشته بشه باید همه چیز جوری نوشته شده باشه که تحت کنترل برنامه باشه. باید وابستگی برنامه به بیرون کم بشه و از پراکنده شدن Business برنامه جلوگیری کرد. پس از دوستانی که علاقه شدیدی به پردازش ها سمت دیتابیس دارن باید بخوام این دیدگاهشون رو عوض کنن. امروز بهتر از فرداست.
در دنیای امروز دیتابیس حکم یک گونی رو داره که فقط اطلاعات داخلش میریزن. بیشتر از این دیتابیس معنا و مفهومی نداره.
برای درک بهتر حرف هایی که زدم به دوستان پیشنهاد میکنم کتاب The Art of unit testing رو مطالعه کنن. این کتاب میتونه رو دیدگاه شما تاثیر مثبتی داشته باشه

یعنی با این نظرتون اصل و اساس و اصول طراحی پاییگاه داده و مهندسی پاییگاه داده رو زیر سوال بردید!

طراحی اصولی پاییگاه داده مثل تمام بخش های دیگه نرم افزار مثل طراحی ساختمان داده های مورد نیاز (حتی در برنامه های شئ گرا)، طراحی واحد های اجرایی ، طراحی پل های رابط ، و غیر از بنیادی ترین اصول طراحی نرم افزار استاندارده. و بازم هم از اصولی ترین و پاییه ای ترین اصول طراحی پاییگاه داده رابطه ای ایجاد index ها , fk , pk ها صحیح و بجا داشتن جداول رابطه ای متعدد برای جلو گیری از افزونگیه. حالا کاری ندارم که در پروژه های سنگین تریگر کردن و این موارد هم مورد نیاز میشن.

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

با این دید شما که دیتا بیس حکم گونی داره و فقط باید همین طوری پرش کرد بعدا پردازش کرد به هیچ عنوان نمیتونید برنامه مورد اعتماد درست کنید. برنامه به هر دلیلی ممکنه دچار مشکل بشه باگ داشته بشه یا به n + 1 دلیل دیگه نتونه تمام شرایط ممکن برای جلوگیری از افزونگی رو رعایت کنه بعدش با این تفکر مشتری بی نوا باید مجددا مزاحتون بشه که داده هایی که باعث خرابی شده رو درست کنید که در این شرایط شما یا باید از داده ها صرفه نظر کنید یا تغییراتی بدید. که اگر این تغییرات یکی دوتا باشه خوب شاید بگید مشکلی نیست اما در خیلی از موارد فقط به یکی دو مورد ختم نمیشه!

مورد بعدی هم Unit test هست من از تست واحد زیاد استفاده میکنم از تست های عملکردی برای ارتباط ها با وبسرویس ها تا بررسی ساختارهای mvvm اما ارتباط ش رو unique کردن دیتابیس رابطه ای متوجه نشدم! (البته من از .net mvc استفاده نمیکنم)

در کل توصیه میکنم بجای خراب کردن طراحی پاییگاه داده از مدیریت استثنا درست در برنامه استفاده کنید.

[sds1920]

یعنی با این نظرتون اصل و اساس و اصول طراحی پاییگاه داده و مهندسی پاییگاه داده رو زیر سوال بردید!

طراحی اصولی پاییگاه داده مثل تمام بخش های دیگه نرم افزار مثل طراحی ساختمان داده های مورد نیاز (حتی در برنامه های شئ گرا)، طراحی واحد های اجرایی ، طراحی پل های رابط ، و غیر از بنیادی ترین اصول طراحی نرم افزار استاندارده. و بازم هم از اصولی ترین و پاییه ای ترین اصول طراحی پاییگاه داده رابطه ای ایجاد index ها , fk , pk ها صحیح و بجا داشتن جداول رابطه ای متعدد برای جلو گیری از افزونگیه. حالا کاری ندارم که در پروژه های سنگین تریگر کردن و این موارد هم مورد نیاز میشن.

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

با این دید شما که دیتا بیس حکم گونی داره و فقط باید همین طوری پرش کرد بعدا پردازش کرد به هیچ عنوان نمیتونید برنامه مورد اعتماد درست کنید. برنامه به هر دلیلی ممکنه دچار مشکل بشه باگ داشته بشه یا به n + 1 دلیل دیگه نتونه تمام شرایط ممکن برای جلوگیری از افزونگی رو رعایت کنه بعدش با این تفکر مشتری بی نوا باید مجددا مزاحتون بشه که داده هایی که باعث خرابی شده رو درست کنید که در این شرایط شما یا باید از داده ها صرفه نظر کنید یا تغییراتی بدید. که اگر این تغییرات یکی دوتا باشه خوب شاید بگید مشکلی نیست اما در خیلی از موارد فقط به یکی دو مورد ختم نمیشه!

مورد بعدی هم Unit test هست من از تست واحد زیاد استفاده میکنم از تست های عملکردی برای ارتباط ها با وبسرویس ها تا بررسی ساختارهای mvvm اما ارتباط ش رو unique کردن دیتابیس رابطه ای متوجه نشدم! (البته من از .net mvc استفاده نمیکنم)

در کل توصیه میکنم بجای خراب کردن طراحی پاییگاه داده از مدیریت استثنا درست در برنامه استفاده کنید.

من هم مشکلی با طراحی بانک داده ندارم ولی صرفا در حد همون pk ، fk ، index ، Relation و موضوع افزونگی که شما خیلی روش تاکید دارید(که صد البته موضوع مهمی هست). ساختار بانک داده باید به درستی تعریف بشه وگرنه داستان خشت اول کج گذاشتن هست. ولی نباید بیشتر از این از بانک داده انتظار داشته باشید.
یکی از بدترین چیزهای که میتونه برای یک برنامه وجود داشته باشه وجود تریگر هست. توصیه میکنم شما هم دور تریگر توی دیتابیس رو خط بکشید. چون به شدت کار عیب یابی و رفع خطا رو زیاد میکنه.

در ضمن دوست عزیز. این دیتابیسی شما دارید اینجور سنگش رو به سینه میزنید در حال منسوخ شدن هست. پروژه های بزرگ توی دنیا دارن از مفهومی به نام NoSql استفاده میکنن. چون وجود اینهمه index و relation و .... باعث کند شدن عملیات در داده های بزرگ میشه. به نظر من این دیتابیس هایی که ما داریم استفاده میکنیم بیشتر برای پروژه های خانگی به درد میخوره تا پروژه های بزرگ.

در آخر من باز هم شما رو به تقوا و تغییر دیدگاه در مورد روش برنامه نویسی دعوت میکنم. باشد که رستگار شوید.