محل Insert رکورد جدید

[nokhod]

سلام.

من وقتی یه Record رو تو جدول Insert می کنم، این معلوم نیست کجا Insert می شه! منظورم اینه که یا انتهای جدول یا وسط جدول یا هر جایی که دلش بخواد Insert می شه ولی من می خوام این Record به انتها اضافه بشه. چکار باید کنم؟

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

[حمیدرضاصادقیان]

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

[nokhod]

من کلیدم دارم ولی کلیدم Uniqueidentifier هست. حالا چی کار کنم؟

[titbasoft]

من کلیدم دارم ولی کلیدم Uniqueidentifier هست. حالا چی کار کنم؟یه شوخی : جمع ضدین عقلا محال است.
وقتی که یک (یا چند) فیلد رو کلید یا اصطلاحا Primary Key می کنید ، روی اون Clustered Index ساخته میشه. این به این معناست که رکوردهای شما به صورت فیزیکی بر اساس کلید ذخیره می شن. عبارت ذخیره سازی فیزیکی Sort شده هم در مقابل ذخیره سازی منطقی به صورت Sort شده استفاده. ذخیره سازی منطقی هم به معنای بوجود آمدن یک جدول واسط به نام Hash Table است که در حقیقت رکودها اونجا به صورت فیزیکی ذخیره می شن و نه در جدول اصلی.

[nokhod]

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

حالا کسی یه راه حل نداره؟

[اَرژنگ]

منظور از اینکه در انتها باشه چیه، مشکل اصلی چیه؟
اینکه رکورد کجا وارد شده باشه فاید‌ای نداره، شما مشکل اساسیتون چیه؟

[nokhod]

یعنی من باید هر رکوردی که اضافه می کنم، به انتهای جدول افزوده بشه نه وسطش! که البته فکر کنم اگه کلید رو Long Int و Auto Increasement بذارم درست بشه. من رفتم امتحان کنم.

از همتون ممنونم که جواب دادین.

[nokhod]

:گریه: یکی به من کمک کنه!!!!!

اینکه Long Int نداره! یه int داره و بس. خوب اینکه محدودییت داره (تا حدود دو میلیارد).
پس من چکار کنم؟:گریه:

[titbasoft]

با تشکر از پاسخ شما. ولی با عرض معذرت من که چیزی نفهمیدم!خوب شاید انشاء خوبی ندارم، به زبان ساده اینکه:
1) اگر یک فیلد رو کلید کنید معنی اون اینه که شما می خواهید با استفاده از اون به رکورد خودتون برسید
2) بدیهی است اگر یک سری اطلاعات به صورت Sort شده ذخیره بشن پیدا کردن اونها خیلی سریعتر میشه
1و2 => پس SQL Server تصمیم میگیره برای دسترسی سریع به هر رکورد ، رکوردها رو به ترتیب کلید اونها ذخیره کنه => اگر کلیدتون رو GUID بزارید رکوردها بر اساس ترتیب GUID ذخیره میشن => چون GUID مقدار تصادفی داره پس رکوردها هم با ترتیب تصادفی ذخیره می شوند

نتیجه گیری اخلاقی => راهی که خودتون پیشنهاد کردید درسته.


اینکه Long Int نداره! یه int داره و بس. خوب اینکه محدودییت داره (تا حدود دو میلیارد).
پس من چکار کنم؟و عمو بیلی Bigint را آفرید

[nokhod]

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

[AminSobati]

ضمنا یادتون باشه که الزاما PK نباید Clustered باشه. شما میتونین PK از نوع GUID داشته باشید اما یک فیلد Identity داشته باشید که همیشه مقدارش رو به افزایشه و Clustered Index رو روی اون بسازید. حالا اگر نحوه Sort در ایندکس شما Ascending باشه، همیشه جدیدترین رکورد، در پایین قرار میگیره.

[titbasoft]

آخ آخ یه مشکل کوچیک:

PRIMARY KEY constraints create clustered indexes automatically if no clustered index already exists on the table and a nonclustered index is not specified when you create the PRIMARY KEY constraint.

و این به این معناست که راه حل دومی هم وجود داره و اون اینه که Primary key رو Non Clustered تعریف کنیم و اون هم بعید می دونیم توی چنین موردی کار درستی باشه.

به هر حال من از if به بعد جمله بالا رو نمی دونستم و اون هم یه جورایی تقصیر خودم نیست و این رو سر کلاس به عنوان یک نکته شنیده بودم که روی PK همیشه C Index ساخته میشه

[AminSobati]

این رو سر کلاس به عنوان یک نکته شنیده بودم که روی PK همیشه C Index ساخته میشه

سر کلاس من؟ غیر ممکنه!

[titbasoft]

سر کلاس من؟ غیر ممکنه!بنده هیچ وقت چنین جسارتی نکردم استاد گرامی، سر کلاس SQL Server 2K Design که در خدمت یکی دیگر از همکاران شما بودم.