[مهمان]

آیا در MySQL یا SQL دستوری هست که بشه به رکوردی از طریق شماره رکورد دسترسی داشت
(جدول id ندارد و از دستور WHERE نمی خوام استفاده کنم).

[jadi]

نمی دونم هست یا نه ولی اصلا منطقی نیست. شماره رکورد «اطلاعات» جدول شما نیست و ممکنه قابل اتکا نباشه.

[مهمان]

فرض میکنیم یک جدول id ندارد و جدول دو رکورد دارد که تمام فیلد های آن مثل هم هستند، چطوری میشه فقط یک رکورد را UPDATE کرد.

[jadi]

خب می تونید آخر خط آپدیت، بنویسید limit 1 تا فقط یک رکورد به روز بشه. ولی روند قشنگی نیست چون نمی دونید کدوم داره آپدیت می شه. تا جایی که من «حس» می کنم، توی یک طراحی خوب نباید اصولا همچین جریانی پیش بیاد. البته بدون شک قابل درکه که آدم خیلی وقت ها با طراحی های بد سر و کار داره. اینجا رو یک نگاه بنداز: <!-- m --><a class="postlink" href="http://dev.mysql.com/doc/refman/5.0/en/update.html">http://dev.mysql.com/doc/refman/5.0/en/update.html</a><!-- m -->

[sadeqn]

بانک‌های اطلاعات رابطه‌ای بر اساس مجموعه کار می‌کنند نه چندگانه مرتب! این یعنی اینکه علی‌القاعده امکان چنین کاری با یک بانک اطلاعات رابطه‌ای وجود ندارد. به همین خاطر است که اکیدا توصیه می‌شود برای جداول یک کلید اصلی تعریف کنید.

کلید اصلی یک یا چند فیلد از یک رکورد است که می‌تواند نماینده آن رکورد باشد.

[Folaani]

بنظرم با limit همراه با offset میتونید به هر رکوردی بطور جداگانه و بر اساس ترتیبش در جدول دسترسی داشته باشید.
اما این ترتیب بنظرم بسادگی همون ترتیب درج رکوردها هست! و بقول دوستان اینطور روشها قابل اتکا نیستن و همهء جوانب اونها روشن نیست.
چون طراحان اینطور نرم افزارها هم تعهدی برای حفظ رفتارهای داخلی اونها ندادن. مثلا وقتی جدول رو اپتیمایز یا تعمیر و یا فشرده کنید از کجا معلوم شاید رکوردها رو جابجا بکنه!
ضمنا درصورت آپدیت و حذف و اضافه شدن رکوردها هم که دیگه کاملا پا درهواست!!
خلاصه این راه درست نیست؛ کاملا غیرامن و غیراصولی.
بعدش هم نیازی نیست اینطوری عمل بکنید! چه ضرورتی هست؟ بقدر کافی امکانات کافی و راحت برای اینطور کارها دراختیار شما هست.

[کرگدن]

درود

خوبی فلانی؟


تیبلی که کلید نداره بی معنیه و تیبل نیست

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

موفق وشاد باشید

[jadi]

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

[کرگدن]

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

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

یک تیبل در بدترین شرایط all key هست پس بازم عامل کلیدی هست
و باید آپدیت و حذف و .... بر اساس عامل کلیدی صورت بگیره

وگرنه ترتیب خاصی برای رکورد ها نیست که بتونیم بهشون دسترسی داشته باشیم

[Folaani]

سلام کرگدن جان. تشکر از احوالپرسی. خودت خوبی؟

-------------------

یه سوال در ارتباط با بحث اخیر:

فرض کنید یه جدول دارم که یک فیلد (ستون) داره فقط که محتویش یک عدد تصادفی هست. این عدد هم لزوما یکتا نیست. فقط رندوم هست.
کاربردش نمیدونم مهمه یا نه ولی فرض کنید مثلا اینه که میخوام این اعداد رندوم رو ذخیره کنم و بعدا سرفرصت تحلیلشون کنم ببینم رندوم جنریتور سالم و امن کار میکنه یا نه!!
آیا این جدول نیازی به کلید داره؟ چرا باید کلید داشته باشه؟
کی گفته هر جدولی برای هر کاربردی باید کلید داشته باشه؟
بنظر من در بحث اپلیکیشن نویسی و آموزش اصولش بله میشه اینطور گفت. ولی مطلق و صددرصد نیست. میتونه ۹۹ درصد موارد درست باشه؛ ولی ۱۰۰٪ نیست.
اینطور کلی و مطلق حرف زدن و تابو درست کردن داستانش شبیه همون دستور goto و حکایت استفاده از اکانت root در لینوکس بنظر میرسه. دلیلی بر اینهمه اصرار و مطلق و کلی حرف زدن بدون منطق و استدلال لازم وجود نداره.
ضمنا فلسفه و اصول یک زبان لزوما شامل حیطه های دیگه نمیشه و قاطع و کلی و جهانشمول نیست. مسلمه که جاوا دیسیپلین سختی در این ارتباط باید داشته باشه؛ شاید چون ساختار و فلسفهء اساسی اون اصولا با غیر از این حالت مشکل داره و چندان سازگار نیست. اما این لزوما کیسی در جاهای دیگه نیست.

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

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

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

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

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

مسلما وقتی اطلاعاتی رو که در واقعیت مالکین اونها ماهیت یکتا یا ضرورتا قابل تفکیک دارن، مثل نام و نام خانوادگی اشخاص، در جدولی ذخیره میکنیم، اغلب باید کلید هم بهشون بدیم.

درک ماهیت کلید و لزوم و اهمیت و کاربردهاش اینقدری سخت نیست. دیگه برنامه نویس باید کاملا ناشی و کم دانش باشه تا جایی که واقعا کلید میخواد و در منطق برنامه ایجاد اشکال و باگ میکنه، کلید نذاره.
البته اینطور (به اصطلاح) برنامه نویسها بنظرم اصلا کم نیستن (حداقل در اینجا!!).
پس بهتره بهشون بگیم هر جدولی باید کلیدی داشته باشه تا حداقل این قضیه و ابزار جلوی دست و دیدشون باشه همیشه :wink:

[کرگدن]

سلام کرگدن جان. تشکر از احوالپرسی. خودت خوبی؟

-------------------

یه سوال در ارتباط با بحث اخیر:

فرض کنید یه جدول دارم که یک فیلد (ستون) داره فقط که محتویش یک عدد تصادفی هست. این عدد هم لزوما یکتا نیست. فقط رندوم هست.
کاربردش نمیدونم مهمه یا نه ولی فرض کنید مثلا اینه که میخوام این اعداد رندوم رو ذخیره کنم و بعدا سرفرصت تحلیلشون کنم ببینم رندوم جنریتور سالم و امن کار میکنه یا نه!!
آیا این جدول نیازی به کلید داره؟ چرا باید کلید داشته باشه؟
کی گفته هر جدولی برای هر کاربردی باید کلید داشته باشه؟
بنظر من در بحث اپلیکیشن نویسی و آموزش اصولش بله میشه اینطور گفت. ولی مطلق و صددرصد نیست. میتونه ۹۹ درصد موارد درست باشه؛ ولی ۱۰۰٪ نیست.
اینطور کلی و مطلق حرف زدن و تابو درست کردن داستانش شبیه همون دستور goto و حکایت استفاده از اکانت root در لینوکس بنظر میرسه. دلیلی بر اینهمه اصرار و مطلق و کلی حرف زدن بدون منطق و استدلال لازم وجود نداره.
ضمنا فلسفه و اصول یک زبان لزوما شامل حیطه های دیگه نمیشه و قاطع و کلی و جهانشمول نیست. مسلمه که جاوا دیسیپلین سختی در این ارتباط باید داشته باشه؛ شاید چون ساختار و فلسفهء اساسی اون اصولا با غیر از این حالت مشکل داره و چندان سازگار نیست. اما این لزوما کیسی در جاهای دیگه نیست.

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

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

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

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

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

مسلما وقتی اطلاعاتی رو که در واقعیت مالکین اونها ماهیت یکتا یا ضرورتا قابل تفکیک دارن، مثل نام و نام خانوادگی اشخاص، در جدولی ذخیره میکنیم، اغلب باید کلید هم بهشون بدیم.

درک ماهیت کلید و لزوم و اهمیت و کاربردهاش اینقدری سخت نیست. دیگه برنامه نویس باید کاملا ناشی و کم دانش باشه تا جایی که واقعا کلید میخواد و در منطق برنامه ایجاد اشکال و باگ میکنه، کلید نذاره.
البته اینطور (به اصطلاح) برنامه نویسها بنظرم اصلا کم نیستن (حداقل در اینجا!!).
پس بهتره بهشون بگیم هر جدولی باید کلیدی داشته باشه تا حداقل این قضیه و ابزار جلوی دست و دیدشون باشه همیشه :wink:

ممنون امتحانا بی چاره کرده

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

ما ریلیشن رو یک n-tuple که بدون تکرار هست تعریف می کنیم
پس نتیجه می گیریم هیچ سطر تکراری در تیبل نباید داشته باشیم
وگرنه تعریفمون رو ضایع کردیم
مثل اینکه دستگاهمون رو اعداد اول تعریف کنیم ولی در محاسبه ای عددی غیر اول استفاده کنیم


در مورد مثالی که زدی
کاملاً اشتباهه و هیچ استفاده ای نداره
شما اومدی یک سری اعداد رندم رو ( بدون اولویت و ترتیب در یک ستون ذخیره کردی)
چون اولویت خاصی ندارن => تکرار شدنشون هم معنی نداره و بی خودی چند بار در تیبل ذخیرشون کردی
چون تنها استفاده ای که می تونی از این ستون بکنی اینه که آیا این عدد در داده هات بوده یا خیر و تکرارش برات هیچ سودی نداره
پس می تونی کلیدش کنی و هر داده رو فقط یکبار ذخیره کنی
اگر تعداد تکرارشون رو بخوای => باید یه ستون دیگه اضافه کنی
اگر ترتیبشون رو بخوای => بازم باید یه ستون دیگه اضافه کنی و شماره بزنی

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

این ها همه در جبر رابطه ای وجود داره و چیزی نیست که به دلبخواه ما تغییر کنه
ریاضیه

حالا دلیل چیه؟
چون اگر عملوندی غیر عملوند های تعریف شده وارد دستگاهمون بشه ممکنه نتونیم عملگر مورد نظر رو روش انجام بدیم یا جواب خارج از دستگاه تعریف شده ما باشه
که همه اینا موجب anomaly می شه و یعنی افتضاح

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

[Folaani]

بله اینها رو که چیز پیچیده و ناگفته ای نیست اکثرا. اکثر برنامه نویسهای حداقل غیرناشی هم حداقل بخشهای مهم اون رو میدونن.
اما بازهم میگم که نظر کلی و مطلق دادن درست نیست. چون حتی خود ریاضی هم مثل سایر علوم تغییر میکنه، تئوریهای جدیدی میاد، حتی ممکنه اشتباهات و یا نقصهایی در بعضی تئوریها باشه و غیره. اما کلا ریاضی یکی از محکمترین و عالی ترینهاست که پایهء بقیهء علوم محسوب میشه و خب جایی که میتونیم همه چیز رو باهاش خوب و راحت وفق بدیم اینکار رو میکنیم. بنده هم مخالفت کلی ای با اصول طراحی دیتابیس و نرمال سازی ندارم.
اما بازم مثل شما بطور کلی نمیگم که مطلقا مجبورید برای هر جدولی در هر کاربردی کلید بذارید. دانش و تجربه بهم اینطور میگه تا حدودی.
در عمل و دنیای واقعی بعلت دخیلی بودن خیلی پارامترها دیگه که بعضی اونقدر پیچیده و غیرایدئال هستن که نمیشه همه رو با ریاضیات و فرمول محاسبه و پیش بینی و حل کرد بطور کامل و مطلق، تطابق کامل با دوتا تئوری ساده وجود نداره اغلب.
بلکه این یک تلورانس هست و یک تعادل که همیشه بنده گفتم، برنامه نویسی و اصولا زندگی واقعی برای ما بشرهای نسبی در یک دنیای نسبی، اکثرا یک تعادل بهینه هست (که البته اینهم با ریاضیات قابل محاسبه هست و ریاضیات اساس تقریبا تمام چیزهاست، حتی محاسبهء نسبیات و برایند و تعادلها).
البته در عمل خیلی تصمیم گیریها بصورت تجربی صورت میگیره. شما مثلا یک قطعه چوب رو برای یک کار ساده میخوای ببری و بکار ببری، لزوما همیشه اون رو با متر اندازه نمیگیری و روش محاسبات خیلی دقیق و همه جانبه و پیچیده نمیکنی. براحتی با چشمت نگاه میکنی و تقریبی میبری و میدونی که بخشهای دیگه بقدر کافی انعطاف دارن که کارت رو تطبیق بدی.
محاسبات رو هم میشه با دقت خیلی کم تا دقتهای بسیار بالا انجام داد. اما بازهم بستگی به کاربرد و نیاز و شرایط و منابع در دسترس هست.
بله رایانه علمی هست که پایهء ریاضی داره. اما در عمل اونقدری مثل کتاب ایدئال و مطلق و ساده نیست بسیاری کارهای عادی و در سطوح بالاتر. چون همونطور که گفتم شرایط و پارامترها و نسبیتهای زیادی خارج از کاغذ و تئوری وجود داره؛ و البته اینها هیچ منافات و تناقضی با اصول ریاضی هم نیست و بلکه خودشون با ریاضی قابل اثبات و محاسبه هستن. حال ساده یا خیلی پیچیده که در موارد پیچیده ما خیلی وقتها محاسبات مستقیم انجام نمیدیم (مثل سرعت یک سیستم عامل، برنامه، مصرف حافظه و غیره). بلکه از روشهای سریع و بقدر نیاز ما دقیق تجربی استفاده میکنیم.
همهء اینا که میگم بی ربط نیست. چون منظورم اینه که به شرایط واقعی و وجود احتمال وقوع بسیاری حالتهای خاص پیش بینی نشده در تئوریهای کلی اشاره کنم.
درواقع تئوریها رو باید اساس قرار داد؛ اما اکثرا به دلایل مختلفی تاحدی ازشون منحرف میشیم.
جای که ممکن باشه خب بدیهی هست که دقیقا ازشون پیروی میکنیم.
محدودیتهای تکنیکی یکی از عوامل هستن.
نیازهای واقعی.
فرضا بنده قبلا مقاله ای راجع به Regular Expression ها میخوندم؛ اینها یک تئوری و پایهء کاملا ریاضی دارن و درواقع ابتدا از ریاضی محض بوجود آمدن و بعدا براشون کاربردهای دیگر عملی پیش بینی و روی رایانه پیاده سازی شدن.
و آمده که اصول خود این تئوری توسط رگولار اکسپرشنهای مدرن در بعضی ابعاد کاملا نقض شده. چون نیازها اینطور اقتضا میکرده. و درواقع بخاطر این انحراف و ناسازگاری پیشنهاد کرده بودن که بجای رگولار اکسپرشن از عبارت Regex استفاده بشه (که خیلی جاها میشه).

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

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

[کرگدن]

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

هر جور راحتی
واقعاً وقت بحث کردن ندارم
فقط رو موارد زیر فکر کن

تیبلی که anomally داره به هیچ درد نمی خوره
چون در حذف ویا آپدیت یا اضافه کردن ( یا هرسه ) دچار مشکل میشه و داده هات مخدوش و بی ارزش می شن

مثالی که خودت زدی
یه ستون داری که ممکنه توش تکراری باشه

مثلاً

1 22 33 22 55 22 33 55 66 884 44 44 44 55 66

حالا می خوای 22 دومی رو آپدیت کنی به یه عدد دیگه
از کجا مشخص میکنی که بکدوم 22 آپ بشه و کدوم نشه
پس یک آپدیت همه دیتا هات رو خراب می کنه
همینطور حذف
اگر بخوای یه 44 حذف بشه چطور مشخص می کنی؟

پس از هیچ خواصیت دیتا بیس استفاده نکردی
حتی نگهداری در یک آرایه ( که ایندکس داره ) بسیار برات بهتر بود

پس این داده ها به هیچ دردت نمی خوره چون باهاش هیچ کاری نمی تونی بکنی
حتی خوندن
نمی تونی بگی داده دوم رو بخون ( چون ترتیبی ندارن)
ممکنه در یک بار خوندن ترتیبش با یک بار دیگه تفاوت کنه

کتاب هم می خوای بخونی date + هر چیزی که مربوط به جبر رابطه ای در دیتابیس میشه

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

موفق و شاد باشید

[Folaani]

حالا می خوای 22 دومی رو آپدیت کنی به یه عدد دیگه
از کجا مشخص میکنی که بکدوم 22 آپ بشه و کدوم نشه
پس یک آپدیت همه دیتا هات رو خراب می کنه
همینطور حذف
اگر بخوای یه 44 حذف بشه چطور مشخص می کنی؟

پس از هیچ خواصیت دیتا بیس استفاده نکردی
حتی نگهداری در یک آرایه ( که ایندکس داره ) بسیار برات بهتر بود

پس این داده ها به هیچ دردت نمی خوره چون باهاش هیچ کاری نمی تونی بکنی

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

شما اومدی یک سری اعداد رندم رو ( بدون اولویت و ترتیب در یک ستون ذخیره کردی)
چون اولویت خاصی ندارن => تکرار شدنشون هم معنی نداره و بی خودی چند بار در تیبل ذخیرشون کردی
چون تنها استفاده ای که می تونی از این ستون بکنی اینه که آیا این عدد در داده هات بوده یا خیر و تکرارش برات هیچ سودی نداره

چطور میگی تکرار شدن اونها معنی نداره؟ در آمار تکرار هم موثر هست و معنی داره. جاهایی هست که ترتیب و تفکیک مهم نیست؛ اما آمار تکرار مهم و معنی دار هست.

[کرگدن]

شما می تونی برای خودت یه ساختار تعریف کنی
براش مدل تعریف کنی
و استفاده خاص خودت روهم ازش بکنی

mysql بر اساس مدل ریلیشنال هست
مدل ریلیشنال تعریف و قواعد خودشو داره

می تونی هر جور هم که می خوای ازش استفاده کنی

می تونی اصلاً اطلاعات رو هم ازش نخونی

هر جور راحتی

کتاب معرفی کردم اگر دوست داشتی بخون

موفق و شاد باشی

[Folaani]

چرا مطلب رو وارونه جلوه میدی؟
من اصلا با اصول هیچ مدل و تئوری ای مخالفت نکردم.

حالا اگه دوست نداری رعایت کنی وضع همینی میشه که الان تو ایران هست

کجا چنین حرفی زدم؟!!

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

[کرگدن]

چرا مطلب رو وارونه جلوه میدی؟
من اصلا با اصول هیچ مدل و تئوری ای مخالفت نکردم.

حالا اگه دوست نداری رعایت کنی وضع همینی میشه که الان تو ایران هست

کجا چنین حرفی زدم؟!!

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

ok منم گفتم هر جور راحتی

در مدل ریلیشنال شما نباید سطر تکراری داشته باشی
حالا من چی بگم؟

مثل اینکه کارخونه سازنده می گه فلان روغن موتور رو استفاده کن
حالا شما می گی من چیز دیگه ای میریزم کار می کنه خود دانی
عواقبشم بپذیر
ولی بدون تیبل نباید سطر تکراری داشته باشه => حتماً عامل کلیدی داره

این تعریف تیبل در ریلیشنال هست

شما می تونی تو پیکان 6 نفر سوار کنی
ولی قانون می گه 4 نفر

[Folaani]

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

حالا اشکال مثال بنده در اینجا چی هست خودت حدس بزن!
البته این بازهم بستگی به هدف ما داره؛ درمورد خاص میتونه مهم نباشه.

[Folaani]

در مدل ریلیشنال شما نباید سطر تکراری داشته باشی
حالا من چی بگم؟

مثل اینکه کارخونه سازنده می گه فلان روغن موتور رو استفاده کن
حالا شما می گی من چیز دیگه ای میریزم کار می کنه خود دانی
عواقبشم بپذیر
ولی بدون تیبل نباید سطر تکراری داشته باشه => حتماً عامل کلیدی داره

این تعریف تیبل در ریلیشنال هست

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

[کرگدن]

شما می تونی تو پیکان 6 نفر سوار کنی
ولی قانون می گه 4 نفر

عواقبشم با خودته

شما تو ریاضی می گی یه معادله درجه n در یک دستگاه ممکنه کمتر از n تا جواب داشته باشه ولی در دستگاه دیگه n تا جواب


شما برای اینکه بخواید مشکلی نداشته باشید ( یا کمترین مشکل) باید قوانین اون دستگاه رو قبول کنید و بر اساس اون عمل کنید

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