جلوگیری از ثبت مقدار تکراری در 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 که می رسد خطا می دهد.
که عکس این خطا را هنگام اجرای برنامه پیوست این پست کردم.

138665

[ASKaffash]

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

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

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

[leila2204]

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

[leila2204]

اینم عکس حطا



148454

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

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

[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 تعریف کنید تا اطلاعات توی شبکه قابل دستیابی نباشه.

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

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

در مورد امنیت هم باید بگم من و شما برنامه نویس نباید نگران امنیت داده ها توی شبکه باشیم. اونی که باید نگران باشه مسئول شبکه و امنیت هست. در ضمن برای جلوگیری از این مورد به راحتی میتونید برای SQL Server یک گواهینامه SSL تعریف کنید تا اطلاعات توی شبکه قابل دستیابی نباشه.
شاید متوجه منظور بنده نشدید. من اینجور میگم که یک میلیون رکورد داخل یه جدول هست. پونصد کاربر همزمان درخواست ثبت رو میدن. اگه قراره پردازش سمت برنامه باشه خب باید اون یک میلیون رکورد به هرکدوم از 500 کاربر که درخواست رو کردن برگردونده بشه. پس با یه ضرب ساده باید 500 میلیون داده تو جریان شبکه برگشت داده بشه.(برا مثال میتونید همین سیستم آمارگیری که تو کشور انجام میشه رو در نظر بگیرید. هر لحظه داره داده ها و کد ملی ثبت میشه. نباید کد ملی تکراری ثبت بشه. هروز این جدول که بزرگتر شد . فرض کنید داده ها هم رسیدن به 60 میلیون رکورد و تو کشور هم ده هزار آمارگیر وجود داره :متفکر::عصبانی++: حسابش با شما:چشمک:)

ما عملا با این روش داریم لایه دیتا رو میاریم داخل لایه تجاری (البته هستن کسایی که لایه دیتا رو تو لایه اول UI هم میارن ) . که به نظر من اصلا کار درستی نیست. اگه سورس برنامه لو بره. اطلاعات جداول و ... هم بطبع لو میره.

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

[c0mmander]

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

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

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

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

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

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

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

[sds1920]

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

ما عملا با این روش داریم لایه دیتا رو میاریم داخل لایه تجاری (البته هستن کسایی که لایه دیتا رو تو لایه اول UI هم میارن ) . که به نظر من اصلا کار درستی نیست. اگه سورس برنامه لو بره. اطلاعات جداول و ... هم بطبع لو میره.

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

شما هم گویا نظر بنده رو متوجه نشدید. من میگم برنامه که قراره هر دفعه یک میلیون رکورد رو با هم لود اساسا از نظر طراحی مشکل داره. کدوم کاربریه که بخواد اینهمه رکورد رو یکجا بررسی کنه؟
شما میگید برای مثال نباید کد ملی تکراری ثبت بشه. سوال من اینه. آیا شما به جای یک دستور Select ساده با چندتا شرط هر بار میای و همه داده رو از بانک داده میخونید و بعد با هم مقایسه میکنید؟
در مورد لایه تجاری میشه لطف کنید و بگید قراره این لایه کجای پروژه قرار بگیره؟ به نظر شما توی دیتابیس جای خوبیه برای این لایه؟ پس زبان های برنامه نویسی به چه درد میخورن؟ اگه صرفا قراره در حد ایجاد UI ازشون استفاده کرد که از همون HTML استفاده میکردن.
علاوه بر این اگه همون 500 کاربر شدن 5000 کاربر میدونید چه بار محاسباتی زیادی رو دارید به دوش سرور میذارید؟
در ضمن همون اندازه که امکان لو رفتن سورس برنامه هست امکان لو رفتن دیتابیس هم هست. این بستگی به محیط کار و امنیت محیطی که کار میکنید داره.
برخلاف نظر شما من میگم شما به عنوان یک برنامه نویس باید و باید نگران performance بانک داده و برنامه ای که مینویسه باشه. چون دیتابیس مهمترین منبع اشتراکی بین همه کاربران هست. درسته که بانک داده مدیر برای خودش داره ولی شما به عنوان برنامه نویس قراره پول چی رو بگیرید؟ کد نویسی برای یک بچه 10 ساله هم اینجور که شما میگید کار راحتیه. 4 تا متغییر و 2 تا حلقه و 5 تا متد ایجاد کردن کار سختی نیست.

[sds1920]

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

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

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

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

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

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

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

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

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

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

شما هم گویا نظر بنده رو متوجه نشدید. من میگم برنامه که قراره هر دفعه یک میلیون رکورد رو با هم لود اساسا از نظر طراحی مشکل داره. کدوم کاربریه که بخواد اینهمه رکورد رو یکجا بررسی کنه؟
شما میگید برای مثال نباید کد ملی تکراری ثبت بشه. سوال من اینه. آیا شما به جای یک دستور Select ساده با چندتا شرط هر بار میای و همه داده رو از بانک داده میخونید و بعد با هم مقایسه میکنید؟
در مورد لایه تجاری میشه لطف کنید و بگید قراره این لایه کجای پروژه قرار بگیره؟ به نظر شما توی دیتابیس جای خوبیه برای این لایه؟ پس زبان های برنامه نویسی به چه درد میخورن؟ اگه صرفا قراره در حد ایجاد UI ازشون استفاده کرد که از همون HTML استفاده میکردن.
علاوه بر این اگه همون 500 کاربر شدن 5000 کاربر میدونید چه بار محاسباتی زیادی رو دارید به دوش سرور میذارید؟
در ضمن همون اندازه که امکان لو رفتن سورس برنامه هست امکان لو رفتن دیتابیس هم هست. این بستگی به محیط کار و امنیت محیطی که کار میکنید داره.
برخلاف نظر شما من میگم شما به عنوان یک برنامه نویس باید و باید نگران performance بانک داده و برنامه ای که مینویسه باشه. چون دیتابیس مهمترین منبع اشتراکی بین همه کاربران هست. درسته که بانک داده مدیر برای خودش داره ولی شما به عنوان برنامه نویس قراره پول چی رو بگیرید؟ کد نویسی برای یک بچه 10 ساله هم اینجور که شما میگید کار راحتیه. 4 تا متغییر و 2 تا حلقه و 5 تا متد ایجاد کردن کار سختی نیست.

دوتا حالت هست یا من متوجه نمیشم یا شما.(قصد بر بی احترامی نیست)

طبق فرمایش شما و برداشتی که من کردم (
پس از دوستانی که علاقه شدیدی به پردازش ها سمت دیتابیس دارن باید بخوام این دیدگاهشون رو عوض کنن) شما میگید پردازش رو بیارید سمت برنامه، خب وقتی پردازش رو میاریم سمت برنامه پس تو کوئری هم نباید از where استفاده کرد. اگه استفاده کنید در نتیجه شما به همون گونی(دیتابیس) میگید بیا و کوئری من رو پردازش کن. اگه سمت برنامه باشه باید دیتا ها رو اورد تو برنامه و با دیتاتیبل یا هرچی توشون سرچ انجام داد.
در مورد لایه ها من سه لایه رو مد نظر قرار دادم. لایه یو آی، لایه بیزینس و لایه دیتا. من شاگرد هستم و در حال یادگیری پس یه مقاله کوتاه رو معرفی میکنم بهتره یه مطالعه روش داشته باشید چون خودم خوندم گفتم به بقیه دوستان هم معرفی کنم. https://fa.wikipedia.org/wiki/%D9%85%D8%B9%D9%85%D8%A7%D8%B1%DB%8C_%DB%B3_%D9%84 %D8%A7%DB%8C%D9%87

ما منطق سه لایه رو انتخاب میکنیم تا وابستگیمون کمتر بشه. اگه کارفرما گفت من یه نسخه وب میخوام دیگه فقط لایه یو آی رو دوباره میسازیم.


علاوه بر این اگه همون 500 کاربر شدن 5000 کاربر میدونید چه بار محاسباتی زیادی رو دارید به دوش سرور میذارید؟ این پردازش ها برای پایگاه های داده عدد قابل توجهی نیست (البته اگر به چشم گونی نگاهشون نکنیم)



در ضمن همون اندازه که امکان لو رفتن سورس برنامه هست امکان لو رفتن دیتابیس هم هست. این بستگی به محیط کار و امنیت محیطی که کار میکنید داره.

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




برخلاف نظر شما من میگم شما به عنوان یک برنامه نویس باید و باید نگران performance بانک داده و برنامه ای که مینویسه باشه. چون دیتابیس مهمترین منبع اشتراکی بین همه کاربران هست.

بله پرفورمنس کوئری هایی که مینویسیم دست خود برنامه نویسه. بایدم برا بهینه بودنش تلاش کنه. در ضمن اگه قرار باشه پردازشی سمت سرور نباشه پس زیاد هم رو پرفورمنسش تاثیری نداره. یه سلکت سادس.





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


آخرش اینو میتونم بگم که به نظر شما هدف از کار روی این دیتابیس های غول پیکری که ازشون تو جاهای غول پیکر استفاده میشه چیه؟ صرفا یه گونی؟ اگه اینطوره خب همه برن سمت فایلهای متنی یا اینکه بشینن یه DBMS برا خودشون بنویسن چه لزومی داره از برنامه های مدیریت پایگاه داده استفاده کرد.!!!!!

[sds1920]

شما میگید پردازش رو بیارید سمت برنامه، خب وقتی پردازش رو میاریم سمت برنامه پس تو کوئری هم نباید از where استفاده کرد. اگه استفاده کنید در نتیجه شما به همون گونی(دیتابیس) میگید بیا و کوئری من رو پردازش کن. اگه سمت برنامه باشه باید دیتا ها رو اورد تو برنامه و با دیتاتیبل یا هرچی توشون سرچ انجام داد.

دوست عزیز شما گویا یادداشت های من رو دقیق مطالعه نمیکنید و بیشتر از خود توسعه دهندگان دیتابیس از کلمه گونی ناراحت شدید؟ من گفتم "
آیا شما به جای یک دستور Select ساده با چندتا شرط هر بار میای و همه داده رو از بانک داده میخونید و بعد با هم مقایسه میکنید؟
"
پس منظور من این نیست که شما دستور Select بدون Where بنویسید. منظور من این هست که شرایطی که در Where مشخص میشه جزء منطق تجاری برنامه هست و توی همون لایه بیزینس شما باید مشخص بشه نه اینکه بره داخل دیتابیس. شما اگه دیتابیس رو همون گونی هم در نظر بگیری وقتی بخوای چیزی از داخلش در بیاری باید یه نگاه داخلش بندازی و این میشه همون Where.



ما منطق سه لایه رو انتخاب میکنیم تا وابستگیمون کمتر بشه.

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



این پردازش ها برای پایگاه های داده عدد قابل توجهی نیست (البته اگر به چشم گونی نگاهشون نکنیم)

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



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

من در جواب به شما فقط یه جمله از خود شما رو میارم "
اگه سورس برنامه لو بره. اطلاعات جداول و ... هم بطبع لو میره.
"



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

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



آخرش اینو میتونم بگم که به نظر شما هدف از کار روی این دیتابیس های غول پیکری که ازشون تو جاهای غول پیکر استفاده میشه چیه؟ صرفا یه گونی؟ اگه اینطوره خب همه برن سمت فایلهای متنی یا اینکه بشینن یه DBMS برا خودشون بنویسن چه لزومی داره از برنامه های مدیریت پایگاه داده استفاده کرد.!!!!!


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

[c0mmander]

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

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

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

دوست من با با اطلاعات کامل پاسخ شما رو دادم.
با بانک های اطلاعاتی neo4j , کاساندارا هم بصورت خیلی جدی کار کردم.

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

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

در اخرین ریپلای تون هم این گفتید که با index کردن مشکلی ندارید. دقیقا این دوحرف در تناقض کامل هست.

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