نحوه ایجاد جدول و Unique کردن فیلدها

[هزاره سوم]

سلام
دوستان میشه در مورد ایجاد یه table جدید و مخصوصا unique کردن پارامتر هاش
توضیح بدید؟؟

CREATE TABLE Persons
(
P_Id int NOT NULL,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Address varchar(255),
City varchar(255),
UNIQUE (P_Id)
)



CREATE TABLE Persons
(
P_Id int NOT NULL,
LastName varchar(255) NOT NULL,
FirstName varchar(255),
Address varchar(255),
City varchar(255),
CONSTRAINT uc_PersonID UNIQUE (P_Id,LastName)
)

پیشاپیش ممنون

[sohil_ww]

CREATE TABLE Persons
(

این دستور می گه من 1 جد.ل می خوام ایجاد کنم به نام persons


P_Id int NOT NULL,

و این خط کد میاد 1 ستون به نام p_ID نوع int و اینکه این فیلد نمی تواند خالی باشد و باید مقدار بگیره

LastName varchar(255) NOT NULL,

اینم به همون صورت بالا ولی با نوع Varchar


FirstName varchar(255),
Address varchar(255),
City varchar(255),

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

و حالا دستور
UNIQUE (P_Id)

این دستور میاد فیلد (p_ID) از نوع UNIQUE تعریف می کنه و حالا این کد چی هست

UNIQUE به معنی منحصر به فرد است و حالا توضیحش

دقیقا مثل pirimery key یعنی 1 محدویت برای فیلد ایحاد می کنن یعنی این که این فیلد نمی تونن مقدار های یکسان داشته باشن ما تو جدول فقط 1 perimery key می تونیم داشته باشیم ولی تا دلت می خواد unique تعریف کن حالشو ببر

[مهدی هادیان2]

بسم الله الرحمن الرحیم
با سلام

ما تو جدول فقط 1 perimery key می تونیم داشته باشیم ولی تا دلت می خواد unique تعریف کن حالشو ببر
معمولا چه موقع هایی استفاده میشه.
با سپاس

[محمد سلیم آبادی]

معمولا چه موقع هایی استفاده میشه.
یک نمونه بسیار ساده شماره دانشجویی هست. زمانی که این خصیصه در جدول به عنوان کلید اولیه نیست بهتر است یک قید UNIQUE روی آن ایجاد کنیم تا تکراری نبودنش تضمین بشه.

[f.beigirad]

یک نمونه بسیار ساده شماره دانشجویی هست. زمانی که این خصیصه در جدول به عنوان کلید اولیه نیست بهتر است یک قید UNIQUE روی آن ایجاد کنیم تا تکراری نبودنش تضمین بشه.

با سلام

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

پس باید خطا های دیتابیس رو هندل کنیم دیگه!!

من همین کار رو انجام دادم.از نظر سرعت ، مدیریت خطا ها یا هندل کردن خطا های دیتابیس 5 برابر مدت زمان چک کردن و درج رکورد طول کشید!!!!

برا خودمم این نتیجه جالب بود.

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


.......................................
لازم دونستم بگم جدولی که من این تست رو روش انجام دادم حدود 25 هزار رکورد داشت .و تمامی دستورات برای درج و چک کردن دستورات T-SQL بودن.

[sohil_ww]

با سلام

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

پس باید خطا های دیتابیس رو هندل کنیم دیگه!!

من همین کار رو انجام دادم.از نظر سرعت ، مدیریت خطا ها یا هندل کردن خطا های دیتابیس 5 برابر مدت زمان چک کردن و درج رکورد طول کشید!!!!

برا خودمم این نتیجه جالب بود.

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


.......................................
لازم دونستم بگم جدولی که من این تست رو روش انجام دادم حدود 25 هزار رکورد داشت .و تمامی دستورات برای درج و چک کردن دستورات T-SQL بودن.


یک نمونه بسیار ساده شماره دانشجویی هست. زمانی که این خصیصه در جدول به عنوان کلید اولیه نیست بهتر است یک قید UNIQUE روی آن ایجاد کنیم تا تکراری نبودنش تضمین بشه.

دوست عزیز همون طوری که آقا/خانم msalim (http://barnamenevis.org/member.php?108959-msalim) گفتن و مثالی که خودتون زدید اگه بخوایم چک کنیم که داده موجود هست یا نه باید کل داده های موجود در فیلد مورد نظر سرچ بزنیم و ببینیم مقدار ما موجود هست یا نه ،ولی اگه بخوایم که خودمون چک کنیم با در نظر گرفتن زمانی که صرف نوشتن کویری برای سرچ می شه(منظورم همون زمان کم برای تایپه) به نظر شما تایپ کردن دستورات آسون تره با ا فیلد در موقع طراحی از نوع unique قرار دادن

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

[f.beigirad]

طاعات قبول.

برای من مهم اصولی بودن مهمه.

نه تایپ کردن 10 - 20 خط کد.
هنوزم معتقدم کوئری زدن برای چک کردن یک کار اضافس.
چون این امکان رو خود SQL Server تو خودش قرار داده.ولی در عجبم چرا نتیجه ای که گرفتم خلافه این قضییس.

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

دارم کم کم هنگ میکنم:گیج:

[sohil_ww]

طاعات قبول.

برای من مهم اصولی بودن مهمه.

نه تایپ کردن 10 - 20 خط کد.
هنوزم معتقدم کوئری زدن برای چک کردن یک کار اضافس.
چون این امکان رو خود SQL Server تو خودش قرار داده.ولی در عجبم چرا نتیجه ای که گرفتم خلافه این قضییس.

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

دارم کم کم هنگ میکنم:گیج:

من حقیقتا تا حالا رو این موضوع استوار بودم ولی چیزی که شما می گید(البته خودم چک نکردم)منم به شک انداخت تو این قضیه ممنون میشم اساتید 1 جواب منطقی برای این سئوال بدن

[مهدی هادیان2]

بسم الله الرحمن الرحیمم
با سلام
دوستان اگر بخواهیم خطاهای دیتابیس در سطح DL چک کنیم؛ چه کار باید کنیم و چه جوری بایستی انجام داد؟
با سپاس

[مهدی هادیان2]

بسم الله الرحمن الرحیم

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

[sohil_ww]

بسم الله الرحمن الرحیم

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

عزیز اون فقط 1 مثال بود، ولی به نظر من کلید اصلی تو همه ی دیتابیس های ثبت اطلاعات فردی بهتر کلید اصلی کد ملی باشه و شماره دانشجویی یا شماره پرسنلی و ... به صورت unique تعریف بشن

[محمد سلیم آبادی]

بسم الله الرحمن الرحیم

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

اجازه بدین یک مثال دیگر بیاورم. ما یکسری اشیاء داریم و یکسری افراد. جدول داریم که مالکیت افراد را نسبت به اشیاء مشخص می کند. مثلا علی دارای کامپیوتر است. خب در اینجا ما تنها نیاز به یک بار تعیین کردن این مالکیت داریم و ایجاد یک سطر دیگر با همین مقادیر کار اشتباهی است. در نتیجه می توانیم ترکیب این دو ستون را کلید اولیه در نظر بگیریم. اما گزینه ی دیگری نیز برای انتخاب PK وجود دارد یعنی ایجاد یک کلید جانشین(surrogate) یا مصنوعی به این معنا که یک ستون دیگر به این جدول اضافه نموده و آن را PK تعیین میکنیم (که استفاده از ویژگی IDENTITY بسیار متعارف است). و ترکیب آن دو ستون را به عنوان کلید کاندید ( Candidate Key) بپذیریم. و بایستی یک قید ترکیبی یکتا (Composite Unique Constraint) ایجاد کنیم تا یکتایی آن کلید تضمین شود. اگر اینکار را نکنیم درست است که هیچگاه دو سطر با مقادیر کاملا یکسان در جدول نخواهیم داشت (به واسطه ی PK) اما ممکن است یک مالکیت در جدول چند بار اعلام شده باشد. مثلا دو سطر غیر تکراری زیر معنایی ندارند چرا که مالکیت یک فرد نسبت به یک شی ء را دو بار بیان کرده است که لزوم و ضروریتی نداشت:

کلید اولیه - نام فرد - نام شیء
1 علی کامپیوتر
2 علی کامپیوتر

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

[2012ramin]

با پیگیری این موضوع به نتیجه جدیدی نرسیدید؟ هنوز از کوئری استفاده می‌کنید؟