DISTINCT روی image , ntext , text کار نمیکنه. چیزی هست که کارش رو انجام بده؟

[MMAASS]

سلام دوستان
من می خوام یه view داشته باشم که از چند تا جدول است حالا بعضی از رکوردها تکراری میشن. با کمک DISTINCT رکوردهای تکراری نشون داده نمیشن اما یکی از فیلدهای من از جنس ntext است و DISTINCT‌ روی image , ntext , text کار نمیکنه!!!!!!!!!!!!
البته من فعلا برای رسیدن به جواب view رو شکستم و به دو تا view تبدیل کردم و کاملا هم جواب میگیرم.
می خواستم ببینم که آیا راهی داره؟

[MMAASS]

سلام
واقعا از راهنماییتون ممنونم.
آقای ثباتی کم لطفی نفرمایین. :ناراحت:

[AminSobati]

سلام،
عجیبه که این سوال از چشم من دور مونده!
اینکه روی فیلدهای text, ntext, image نمیشه کارهایی مثل distinct, group by, order by انجام داد، یک منطق داره:
این فیلدها میتونن اطلاعاتی با حجم حداکثر 2 گیگابایت داشته باشند. فرض کنید شما جدولی دارید که هر رکوردش اطلاعات مربوط به یک کتاب رو نگه میداره و مثلا یکی از فیلدها هم متن خود کتاب رو. متن خود کتاب در فیلدی از جنس text نگه داری میشه و حالا شما میخواهید روی این فیلد distinct بگیرید! حدودا چند صد هزار کاراکتر باید بین تمام رکوردها مقایسه بشن تا حاصل distinct بدست بیاد؟!
میبینید که اساسا این کار اگر هم انجام پذیر باشه، بسیار کند خواهد بود. منطقا اگر شما نیاز به انجام چنین کارهایی پیدا کنید، در طراحی دیتابیس مشکلی وجود داشته.

[MMAASS]

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

[AminSobati]

تصور من بر این بود که فیلد متن، به غیر از جدول اصلی، در جدول دیگری هم نگهداری میشه و این یعنی افزونگی اطلاعات. و یا کاربرها یک اطلاعات مشترک رو، از دو منبع مختلف وارد جداول میکنند. اینجا به سناریوی شما بستگی داره.
ولی اگر به خاطر Join به ناچار رکورد حاوی متن بیش از یکبار در نتیجه ظاهر میشه و میبایست distinct بگیرید، بله حق با شماست، این اشکال در طراحی محسوب نمیشه.
روش صحیح اینه که ابتدا فیلدهای سبک رو که distinct پذیر هم هستند انتخاب کنید و distinct بگیرید، حالا IDهای باقیمانده رو با جدول اصلی Join کنید تا متنهای مورد نظر استخراج بشن.
با توجه به توضیحی که در مورد استفاده از دو View ارائه کردید، تصور میکنم همین روش مورد استفاده قرار گرفته باشه

[MMAASS]

تصور من بر این بود که فیلد متن، به غیر از جدول اصلی، در جدول دیگری هم نگهداری میشه و این یعنی افزونگی اطلاعات. و یا کاربرها یک اطلاعات مشترک رو، از دو منبع مختلف وارد جداول میکنند. اینجا به سناریوی شما بستگی داره.
ولی اگر به خاطر Join به ناچار رکورد حاوی متن بیش از یکبار در نتیجه ظاهر میشه و میبایست distinct بگیرید، بله حق با شماست، این اشکال در طراحی محسوب نمیشه.
روش صحیح اینه که ابتدا فیلدهای سبک رو که distinct پذیر هم هستند انتخاب کنید و distinct بگیرید، حالا IDهای باقیمانده رو با جدول اصلی Join کنید تا متنهای مورد نظر استخراج بشن.
با توجه به توضیحی که در مورد استفاده از دو View ارائه کردید، تصور میکنم همین روش مورد استفاده قرار گرفته باشه
با کمال تشکر از توجه شما
بله من برای گرفتن جواب دقیقا همین کار رو کردم و از یک view استفاده کردم.
اما همون طور که قبلا هم عرض کردم می خواستم ببینم آیا راه دیگه ایی نداره؟ که ظاهرا خیر.

[AminSobati]

در SQL Server 2005 فیلد nvarchar و varchar و varbinary تا 2GB مثل ntext و text و image میتونه ساپورت کنه. امکان distinct هم وجود داره. اما برای حجم اطلاعات بالا طبیعتا توصیه نمیشه. و یا برای Query شما، چون فیلد حجیم رو از ابتدا از جدول برمیداره و به Intermediate Result میبره در طول اجرای Query، باز هم روش View بسیار ایده آل تره.

[MMAASS]

در SQL Server 2005 فیلد nvarchar و varchar و varbinary تا 2GB مثل ntext و text و image میتونه ساپورت کنه. امکان distinct هم وجود داره. اما برای حجم اطلاعات بالا طبیعتا توصیه نمیشه. و یا برای Query شما، چون فیلد حجیم رو از ابتدا از جدول برمیداره و به Intermediate Result میبره در طول اجرای Query، باز هم روش View بسیار ایده آل تره.
از راهنمایی ارزشمندتون مچکرم.