گرفتن فیلد Memo از MsAccess با ADO.Net [بایگانی]

niloufar

دوشنبه 14 فروردین 1385, 16:48 عصر

دوستان سلام
اگه در MsAccess دیده باشید فیلدهای از نوع Text حداکثر شامل 255 کاراکتر است و برای متن های بزرگ باید از فیلدهای Memo و اگه دیگه خیلی گردن کلفت باشه از فیلدهای Ole استفاده کرد.
اما ظاهرا Ado.net هیچ کدوم از این دو فرمت را ساپورت نمیکنه. اگه فیلد رو Ole بذاریم، یه پیغام میده که Ole و Memo ساپورت نمیشن و اگه فیلد رو Memo بذاریم، ظاهرا فیلد را میاره ولی فقط 255 کاراکتر اولش رو میاره. یعنی یه جورایی اونو به عنوان یه فیلد Text میبینه.
آیا کسی راهی به نظرش میرسه؟
ممنون

niloufar

دوشنبه 14 فروردین 1385, 18:32 عصر

دوباره سلام

ظاهرا Ado.Net فیلد Memo را ساپورت میکنه اما مشکل از یه جای دیگه بود. کوئری ای که من انجام میدادم دارای Group By بود و وقتی یک فیلد Memo گروپ میشه نمیدونم چرا خود به خود 255 کاراکتری (یعنی مثل Text میشه)
در واقع اگه فیلد از نوع Memo در Group By شرکت کنه دیگه نمیشه بیش از 255 تاش رو دید.

از دوستان کسی نظری داره؟

meh_secure

دوشنبه 14 فروردین 1385, 21:47 عصر

بخاطر سنگین بودن فیلد Memo نمیشه یه سری اعمال رو روش انجام داد. خود SQL Server برای ساختن Index ها محدودیت گذاشته. این که دیگه Access هستش.

Hamedm

دوشنبه 14 فروردین 1385, 22:03 عصر

سلام

دوباره سلام

ظاهرا Ado.Net فیلد Memo را ساپورت میکنه اما مشکل از یه جای دیگه بود. کوئری ای که من انجام میدادم دارای Group By بود و وقتی یک فیلد Memo گروپ میشه نمیدونم چرا خود به خود 255 کاراکتری (یعنی مثل Text میشه)
در واقع اگه فیلد از نوع Memo در Group By شرکت کنه دیگه نمیشه بیش از 255 تاش رو دید.

از دوستان کسی نظری داره؟کار ADO.NET کاملا درست است.
شما میخواهید فیلد Memo رو که بیش از 255 کاراکتر است رو GROUP BY کنید؟ :متعجب:
بنظرم کوئریتونو اشتباه نوشتید. چون GROUP BY برای فیلدهایی عددی و نیز فیلدهای کوتاه، معمولا انجام میشه.

در پناه حق موفق باشید و پرتوان

meh_secure

دوشنبه 14 فروردین 1385, 22:24 عصر

حامد جان کاملا با نظرت موافقم. بهتره که ما تو کارهامون یه سری استانداردها رو رعایت کنیم.

niloufar

سه شنبه 15 فروردین 1385, 19:36 عصر

سلام
1- البته تجربه من از همه دوستان کمتره
2- آقای محمدی کوئری که غلط نیست فرض کن یکی از فیلدهای جدول Master از نوع Memo است و می خواهیم آن را در کنار مثلا تعداد رکوردهای جدول Detail که به هر یک از این رکوردها ربط دارد نمایش دهیم (مثلا برای دادن پیام مبنی بر نیاز به Cascade Delete در هنگام Delete و ...) مسلما اگه فیلدمون Memo نبود باید از Group By استفاده میکردیم. حال اینکه با فیلد Memo (که به قول دوستمون سنگینه) نمیشه این کار را کرد و باید دو کوئری جدا بزنیم یه حرف دیگه ایه...
3- حالا خارج از اینکه این MsAccess یا حتی به قول دوستمون SqlServer (چون من امتحان نکردم) نمیتونن این کار را بکنن یا به خاطر سنگینی اون صلاح نمیدونن، این استاندارد که نباید این کار رو کرد از کجا اومده؟

Hamedm

سه شنبه 15 فروردین 1385, 21:00 عصر

سلام

2- آقای محمدی کوئری که غلط نیستمن منظورم ساختار دیتابیست بود که مجبور شدی یک فیلد Memo رو GROUP BY کنی.

فرض کن یکی از فیلدهای جدول Master از نوع Memo است و می خواهیم آن را در کنار مثلا تعداد رکوردهای جدول Detail که به هر یک از این رکوردها ربط داردگفتم که طراحی دیتابیست احتمالا اشتباست چون هیچ موقع یک فیلد Memo رو PK نمیکنند :متعجب:.

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

در پناه حق موفق باشید و پرتوان

habedijoo

چهارشنبه 16 فروردین 1385, 09:07 صبح

سلام

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

niloufar

چهارشنبه 16 فروردین 1385, 18:28 عصر

سلام
1- آقای محمدی، اگه یه ذره از حافظتون بیشتر استفاده کنید و یه ذره سابقه من را (که البته مسلما از همه کمتره) لااقل تو این فروم و فروم خدابیامرز VB6 به یاد بیارید، بعید می دونم دیگه هر چه قدر هم کوچیک فرضم کنید، بازم بگید احتمالا فیلد Memo را PK گرفته اید :- ( همانطور که آقای عابدی جو فکر کنم بیشتر یادشون بوده و گفته اند: "چون مطمئنا شما فیلد Memo رو کلید اصلی نکردی"
2- اما بریم سراغ توضیح چیزی که میخوایم بهش برسیم. نیازی هم به بانک ما نیست که بخوایم به هم بریزیمش، همین الان یه بانک میسازیم:
الف - یه جدول داریم که توش اطلاعات کتابها رو ریختیم. اسمشو میذاریم Books که خیلی چیزا داره. یکیش همون BookId باشه که شما خودتون اینو PK بگیرید و نام کتاب و خیلی چیزای دیگه. یکیش هم فیلد Comment باشه که از نوع Memo است و قراره توضیحاتی در مورد هر کتاب (که البته بیش از 255 کاراکتره) توش ریخته بشه (ما هم بخاطر شما اینو یه وقت PK نمیگیریم).
ب - یه جدول هم داریم مثلا به نام BookIndexes که توش قراره فهرست کتابها و اطلاعات اون (مثل BookIndexId که شما PK میگیریدش و BookId که شما FK میگیرید و عنوان هر فهرست و ترتیبش و والدش و ...
ج - حالا میخوایم تو یه کوئری (نگید خوب دو کوئریش کن که شاکی میشم چون خودم تو پست های قبل گفتم و شما مرا متهم به PK قرار دادن فیلد Memo کردید) تمام اطلاعات کتاب ها را در کنار تعداد (Sum) فهرست های مرتبط با هر کتاب بگیریم (تا مثلا اونا رو در یه گرید نشون بدیم). شما کوئریش رو بنویسید.
د- ممنون

MMAASS

چهارشنبه 16 فروردین 1385, 22:13 عصر

نمی دونم !!! شاید درست نباشه من این طوری بپرم وسط بحث.
اما یه نکته در مورد طراحی دیتابیس ....

الف - یه جدول داریم که توش اطلاعات کتابها رو ریختیم. اسمشو میذاریم Books که خیلی چیزا داره. یکیش همون BookId باشه که شما خودتون اینو PK بگیرید و نام کتاب و خیلی چیزای دیگه. یکیش هم فیلد Comment باشه که از نوع Memo است و قراره توضیحاتی در مورد هر کتاب (که البته بیش از 255 کاراکتره) توش ریخته بشه (ما هم بخاطر شما اینو یه وقت PK نمیگیریم).
ب - یه جدول هم داریم مثلا به نام BookIndexes که توش قراره فهرست کتابها و اطلاعات اون (مثل BookIndexId که شما PK میگیریدش و BookId که شما FK میگیرید و عنوان هر فهرست و ترتیبش و والدش و ...

البته این نکته رو که می گم جدا از بحث Memo و مشکلته اما خوب...
اگه جدول BookIndexes مربوط به موضوعات کتب است فیلد BookIndexId رو باید تو جدول Books به عنوان FK قرار بدی نه اینکه فیلد BookId رو بذاری تو این جدول. ( یعنی یه جورایی به نظر من برعکس عمل کردی :متفکر: )
اگه هم جدول BookIndexes مربوط به چیزهای دیگس خواهش می کنم بگین چون همون طور که گفتم تاپیک رو دنبال می کنم و دوست دارم کاملا در جریان اون باشم.

باتشکر

niloufar

پنج شنبه 17 فروردین 1385, 16:14 عصر

نمی دونم !!! شاید درست نباشه من این طوری بپرم وسط بحث.
اما یه نکته در مورد طراحی دیتابیس ....

البته این نکته رو که می گم جدا از بحث Memo و مشکلته اما خوب...
اگه جدول BookIndexes مربوط به موضوعات کتب است فیلد BookIndexId رو باید تو جدول Books به عنوان FK قرار بدی نه اینکه فیلد BookId رو بذاری تو این جدول. ( یعنی یه جورایی به نظر من برعکس عمل کردی :متفکر: )
اگه هم جدول BookIndexes مربوط به چیزهای دیگس خواهش می کنم بگین چون همون طور که گفتم تاپیک رو دنبال می کنم و دوست دارم کاملا در جریان اون باشم.

باتشکر
سلام
اگه یه کم دقت کنید میبینید که یه کتاب میتونه n تا فهرست کتاب داشته باشه. درواقع رابطه بین کتاب به اندیس، رابطه یک به n است. لذا اگه به قول شما BookIndexId رو در جدول Books به عنوان یه فیلد بذاریم، این یعنی رابطه دقیقا برعکس. ولی اگر BookId رو در BookIndexes بگذاریم یعنی می توانیم n رکورد داشته باشیم (در جدول فهرست) که یک کتاب باشند اما مشخصات فهرستشان متفاوت باشد...

niloufar

پنج شنبه 17 فروردین 1385, 16:20 عصر

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

Hamedm

جمعه 18 فروردین 1385, 00:33 صبح

سلام

خودتون از این جمله چیزی میفهمید:

اگه یه کم دقت کنید میبینید که یه کتاب میتونه n تا فهرست کتاب داشته باشه.

الف - یه جدول داریم که توش اطلاعات کتابها رو ریختیم. اسمشو میذاریم Books که خیلی چیزا داره. یکیش همون BookId باشه که شما خودتون اینو PK بگیرید و نام کتاب و خیلی چیزای دیگه. یکیش هم فیلد Comment باشه که از نوع Memo است و قراره توضیحاتی در مورد هر کتاب (که البته بیش از 255 کاراکتره) توش ریخته بشه (ما هم بخاطر شما اینو یه وقت PK نمیگیریم).
ب - یه جدول هم داریم مثلا به نام BookIndexes که توش قراره فهرست کتابها و اطلاعات اون (مثل BookIndexId که شما PK میگیریدش و BookId که شما FK میگیرید و عنوان هر فهرست و ترتیبش و والدش و ...
ج - حالا میخوایم تو یه کوئری (نگید خوب دو کوئریش کن که شاکی میشم چون خودم تو پست های قبل گفتم و شما مرا متهم به PK قرار دادن فیلد Memo کردید) تمام اطلاعات کتاب ها را در کنار تعداد (Sum) فهرست های مرتبط با هر کتاب بگیریم (تا مثلا اونا رو در یه گرید نشون بدیم). شما کوئریش رو بنویسید.منظورت از فهرست کتابها چیه؟
میتونی Diagram این دو جدولتو اینجا قرار بدی (خیلی کلی توضیح دادی).

در پناه حق موفق باشید و پرتوان

niloufar

شنبه 19 فروردین 1385, 17:53 عصر

سلام

خودتون از این جمله چیزی میفهمید:

اگه یه کم دقت کنید میبینید که یه کتاب میتونه n تا فهرست کتاب داشته باشه.

منظورت از فهرست کتابها چیه؟
میتونی Diagram این دو جدولتو اینجا قرار بدی (خیلی کلی توضیح دادی).

سلام
چیز عجیبیه؟!
دو تا جدول بکشید تو یه کاغذ. اسم یکیش Books اسم یکیش BookIndexes
اولی شامل این فیلدها باشه: BookId و BookName و BookAuthor و ... و BookComment که اولی از نوع AutoNumber و آخری Memo و بقیه Text.
جدول دومی هم شامل این فیلدها باشه: BookIndexId و BookId و BookIndexName و ... که اولی ازنوع AutoNember و دومی Number و سومی Text
یه Relation هم بین BookId های دو جدول بکشید (یک به n از Books به سوی BookIndexes)

حالا:
جدول اول مشخصات کتاب های سیستم رو وارد میکنیم. اما میدونیم که هر کتابی رو باز کنید یه چند صفحه ای داره به نام "فهرست" 10تا 20تا یا Nتا از این فهرست ها داریم که برای هر کتاب میخوایم با ذکر Id اون کتاب، هر کدوم از این Nتا فهرست در یه رکورد از جدول BookIndexes ذخیره شوند (حال معلوم شد منظور از "اگه یه کم دقت کنید میبینید که یه کتاب میتونه n تا فهرست کتاب داشته باشه" چیه؟!)

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

همین.
دوستان دیگه هم اگه نظری در مورد بحث "علمی" در این تاپیک دارن، خوشحال میشیم وارد بحث شوند.

Hamedm

شنبه 19 فروردین 1385, 20:14 عصر

سلام

حتی دوستی گفت که "گفتم که طراحی دیتابیست احتمالا اشتباست چون هیچ موقع یک فیلد Memo رو PK نمیکنند" و من تا این حد پایین آمدم (هر چند خود را پایین تر از همه دوستان میدونم)(منظورش منم :اشتباه:)
ببین این حرفو من به هیچ نیتی نگفتم من فقط قصد کمک داشتم (من اگه نیتی جز کمک به دیگران داشتم که با این همه کار روزی nبار به این سایت سر نمیزدم. من که بیکار نیستم. یکی میگفت حامد تو که این قدر به این سایت سر میزنی، حتما خیلی وقت خالی داری (دیگه به این آدم چی میشه گفت...))اصلا انتظار نداشتم از حرفم ناراحت بشید. ببین در یادگیری باید پررو بود. اگه از در انداختند بیرون باید از پنجره وارد بشی (من خودم برای یادگیری خیلی پررو هستم، حتی حاضرم بهم توهین بشه ولی به اون پاسخی که دنبالشم برسم).

ولی بهر حال عذرخواهی منو بپزیرید.

حالا:
جدول اول مشخصات کتاب های سیستم رو وارد میکنیم. اما میدونیم که هر کتابی رو باز کنید یه چند صفحه ای داره به نام "فهرست" 10تا 20تا یا Nتا از این فهرست ها داریم که برای هر کتاب میخوایم با ذکر Id اون کتاب، هر کدوم از این Nتا فهرست در یه رکورد از جدول BookIndexes ذخیره شوند (حال معلوم شد منظور از "اگه یه کم دقت کنید میبینید که یه کتاب میتونه n تا فهرست کتاب داشته باشه" چیه؟!)

خوب:
حالا میخوایم همانطور که گفتم لیست کتابها و تعداد فهرستهای هر کتاب رو در یه Query تحویل بگیریم (آقا شهریار هم دیدم تو یه تاپیک دیگه یه همچین چیزی رو خواسته بودند، نمیدونم به اینجا ربط داشته یا نه!!)
باید دوتا SELECT تو در تو بنویسی. همین.
SELECT بیرونی برای اطلاعات کتاب، SELCET درونی هم برای محاسبه تعداد (COUNT) رکوردهایی که با PK جدول Books در ارتباط هستند.
همین

در پناه حق موفق باشید و پرتوان

MMAASS

شنبه 19 فروردین 1385, 20:16 عصر

دوستان دیگه هم اگه نظری در مورد بحث "علمی" در این تاپیک دارن، خوشحال میشیم وارد بحث شوند.
با اجازه ...

جدول اول مشخصات کتاب های سیستم رو وارد میکنیم. اما میدونیم که هر کتابی رو باز کنید یه چند صفحه ای داره به نام "فهرست" 10تا 20تا یا Nتا از این فهرست ها داریم که برای هر کتاب میخوایم با ذکر Id اون کتاب، هر کدوم از این Nتا فهرست در یه رکورد از جدول BookIndexes ذخیره شوند

منظورتون از "فهرست" همون "فهرست مندرجات کتاب" است؟
اگه آره :
آخه واسه چی فهرست کتب رو تو بانک ذخیره می کنی؟ :متعجب: آخه به چه درد می خوره؟ :متعجب: :متعجب: :متعجب: :متعجب:

Hamedm

یک شنبه 20 فروردین 1385, 16:51 عصر

سلام

جناب نیلوفر ازتون خبری نیست، مشکلتون حل شد؟

در پناه حق موفق باشید و پرتوان

niloufar

یک شنبه 20 فروردین 1385, 17:53 عصر

سلام

ولی بهر حال عذرخواهی منو بپزیرید.

خواهش میکنم!!

باید دوتا SELECT تو در تو بنویسی. همین.
SELECT بیرونی برای اطلاعات کتاب، SELCET درونی هم برای محاسبه تعداد (COUNT) رکوردهایی که با PK جدول Books در ارتباط هستند.

فرمایش شما کاملا منطقیه و من هم الان همین کار رو انجام میدم. اما قرار بود با یه select این کار را انجام بدیم که در اونصورت نیاز به Group By پیدا میکردیم. توجه داریم که ایجاد دو کوئری نسبت به یه کوئری در سرعت اجرا تاثیر گذار میباشد. بازم توجه داریم که با ایجاد SubQuery و یا Query های حلقه ای در هر دو صورت باعث کندتر شدن عملیات می شویم که همین باعث شده بود که ابتدا بخواهم آنها را طی یک کوئری پیاده سازی کنم که با آن مشکل برخوردم. در واقع اگر فیلد Memo نبود منطقی ترین راه (پر سرعت ترین راه) استفاده از Group By بود
بازم ممنون و اگه شما هم (یا خصوصا آقای عابدی جو به دلایل نامعلوم) و یا دیگر دوستان از من ناراحت شدید بنده هم عذرخواهی میکنم

MMAASS

یک شنبه 20 فروردین 1385, 21:07 عصر

پس جواب من چی شد؟ :عصبانی: :عصبانی++:
مثل اینکه من یه سوال پرسیده بودم.

habedijoo

دوشنبه 21 فروردین 1385, 08:49 صبح

niloufar

دوشنبه 21 فروردین 1385, 17:44 عصر

پس جواب من چی شد؟ :عصبانی: :عصبانی++:
مثل اینکه من یه سوال پرسیده بودم.
سلام
منظور از سوال شما اینه؟

منظورتون از "فهرست" همون "فهرست مندرجات کتاب" است؟
اگه آره :
آخه واسه چی فهرست کتب رو تو بانک ذخیره می کنی؟ آخه به چه درد می خوره؟

اگه بله، باید عرض کنم که این بستگی به کار بنده و شما داره که چه چیزهایی را باید ذخیره کنیم. این هم یه مثال ساختگی بود تا در مورد موضوع روش بحث کنیم. اما چیز عجیب و غریبی هم نیست، مثلا فرض کنید قراره با انتخاب هر عنوان کتاب، فهرست اون در یه TreeView نمایش داده بشه تا کاربر هر کدومشو که انتخاب کرد، متن اونو ببینه. در اینصورت دیگه برنامه نمیتونه بره و اصل کتب را باز کنه و ازش اطلاعات در بیاره، مجبوره یه جایی (مثل همین بانک یا XML File یا ...) اینا رو نگداری کنده تا موقع لزوم بارگذاریشون کنه.

niloufar

دوشنبه 21 فروردین 1385, 17:55 عصر

دوست عزیز نیلوفر سلام

ببین اینکه میخوای لیست فهرستها را در یک رکورد داشته باشی به نظر من جالب نیست و فکر کنم نشدنیه . آخه از اونجایی که لیست هر کتاب ممکنه متفاوت باشه نمیشه که در یک کوئری رکوردهای با طول متفاوت داشته باشه . شما به نظر من این کار رو بکن . یک InnerJoin بزن . و ابتدا تمامی اطلاعات هر کتاب به همرا فهرست اونا رو یک جا جمع کن . ( مثلا یک جدول موقت )
اگر لازمه تا دستور InnerJoin رو هم بنویسم .

سلام
اگه منظورتون از "اینکه میخوای لیست فهرستها را در یک رکورد داشته باشی به نظر من جالب نیست" همون سوال دوستمونه که در اینصورت در پست قبلی جواب دادم.
اما اگه منظورتون به قرینه "فکر کنم نشدنیه. آخه از اونجایی که لیست هر کتاب ممکنه متفاوت باشه نمیشه که در یک کوئری رکوردهای با طول متفاوت داشته باشه" اینه که نمیشه اونا رو با هم گرفت چون مثلا هر رکورد از جدول Books شامل N تا رکورد از جدول BookIndexes است، خوب باید عرض کنم که اصلا و اساسا و نمیدونم دیگه چی چیا این Group By بنده خدا را برای همین ساخته اند که اگه مثل صورت مساله ما یه Master-Detail داشتیم (که قائداتا باید یک به n هم باشه) و خواستیم هر رکورد از جدول Master را با یه Expersion از جدول Detail (مثل Sum, Qount, ...) ببینیم بیایم و فیلدهای مورد نیاز جدول Master را Group By کنیم و در کنار اون Expersion شده رکوردهای متناسب از جدول Detail (که با اون رابطه ریاضی الان اون هم یه رکوردی شده) کنار هم نشون بدیم
این یه راهشه و یه راه دیگش هم استفاده از دو کوئری است (یا همون SubQuery) که میاد و به ازای هر رکورد یه بار یه نیمچه Selectای انجام میده تا یه جوابکی (البته باز یه تک رکوردی) تحویل بگیره و کنار فیلدهای دیگه نشون بده.
پس اصلا نشدنی نیست و اتفاقا Nتا راه داره که دوتاش رو عرض کردم. اصل و اساس این تاپیک هم سر نشدنش شکل نگرفت. بلکه سر این بود که اگه یکی از فیلدهایی که قراره تو Group By شرکت کنند از نوع Memo بود، فقط 255 کاراکتر اول تحویل گرفته میشد که مجبورم کرد برم و از راه دوم استفاده کنم.
ممنون

niloufar

دوشنبه 21 فروردین 1385, 17:57 عصر

راستی! ممنون Inner join هم بلدم :- (
اگه میخواید من هر دو کوئری رو (با روش اول و دوم) بنویسم تا نتیجه تاپیک بشه (البته اگه دوستان نظر دیگه ای ندارند)

habedijoo

سه شنبه 22 فروردین 1385, 07:27 صبح

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

با تشکر

niloufar

سه شنبه 22 فروردین 1385, 16:55 عصر

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

با تشکر

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

niloufar

سه شنبه 22 فروردین 1385, 16:59 عصر

اینم کوئری از طریق Group By:

SELECT Books.BookId, Books.Name, Books.Author, Books.Comment, Count(BookIndexes.BookId) AS CountOfBookId
FROM Books LEFT JOIN BookIndexes ON Books.BookId = BookIndexes.BookId
GROUP BY Books.BookId, Books.Name, Books.Author, Books.Comment

niloufar

سه شنبه 22 فروردین 1385, 17:00 عصر

و اینم کوئری از طریق SubQuery:

SELECT books.BookId, books.Name, books.Author, books.Comment, SubQuery.BookIndexesCount
FROM books INNER JOIN
[SELECT Books.BookId, Count(BookIndexes.BookIndexId) AS BookIndexesCount FROM Books LEFT JOIN BookIndexes ON Books.BookId = BookIndexes.BookId GROUP BY Books.BookId]. AS SubQuery
ON books.BookId = SubQuery.BookId

niloufar

سه شنبه 22 فروردین 1385, 17:02 عصر

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

موفق باشید و به قول آقای محمدی پرتوان

niloufar

چهارشنبه 23 فروردین 1385, 17:21 عصر

سلام
جدا یه نفر از افرادی که تو این بحث بودند، نظری موافق یا مخالف، اشکال، یا هر چیز دیگه ای نداره!!!!!!!

Hamedm

چهارشنبه 23 فروردین 1385, 17:58 عصر

سلام

اینم کوئری از طریق Group By:

SELECT Books.BookId, Books.Name, Books.Author, Books.Comment, Count(BookIndexes.BookId) AS CountOfBookId
FROM Books LEFT JOIN BookIndexes ON Books.BookId = BookIndexes.BookId
GROUP BY Books.BookId, Books.Name, Books.Author, Books.Comment

این کوئری کاملا درسته و بهتر از کوئری زیر است.

و اینم کوئری از طریق SubQuery:

SELECT books.BookId, books.Name, books.Author, books.Comment, SubQuery.BookIndexesCount
FROM books INNER JOIN
[SELECT Books.BookId, Count(BookIndexes.BookIndexId) AS BookIndexesCount FROM Books LEFT JOIN BookIndexes ON Books.BookId = BookIndexes.BookId GROUP BY Books.BookId]. AS SubQuery
ON books.BookId = SubQuery.BookId

در پناه حق موفق باشید و پرتوان

niloufar

پنج شنبه 24 فروردین 1385, 17:28 عصر

سلام
آقای محمدی خوشحالم که در ته ته تاپیک به سر سر تاپیک برگشتیم :- )
آخه همون زمانها که یادش بخیر هم بنده عرض کردم که باید از Group By استفاده کنیم و بهتره و شما فرمودید: بیکلاس!! آخه کسی فیلد Memo رو PK میکنه (که البته ما هیچ وقت از این غلطا نمیکنیم، یا لااقل غلط به این افتضاحی دیگه نمکنیم).
بی خیال.
فرمایش شما کاملا صحیحه. بنده هم اول همون نظر رو داشتم. فقط وقتی دیدم فیلد Memo در Group By تبدیل میشه به Text ساده 255 کاراکتری، مجبور شدم از راه دوم را پیشنهاد کنم تا هم جواب بگیرم و هم اطلاعات از بین نره.

niloufar

پنج شنبه 24 فروردین 1385, 17:29 عصر

راستی، ممنون که اظهار نظر کردید. کلی حالم گرفته بود که اینهمه پست تو این تاپیک رد و بدل شد، هیشکی تو نتیجه تاپیک اظهاری از نظر نکرد :- (

Hamedm

پنج شنبه 24 فروردین 1385, 20:34 عصر

سلام

آخه همون زمانها که یادش بخیر هم بنده عرض کردم که باید از Group By استفاده کنیم و بهتره و شما فرمودید: بیکلاس!! آخه کسی فیلد Memo رو PK میکنه (که البته ما هیچ وقت از این غلطا نمیکنیم، یا لااقل غلط به این افتضاحی دیگه نمکنیم)من الان هم میگم کسی MEMO رو GROUP BY نمیکنه.

ببین گروپ کردن بخاطر 2منظور استفاده میشه:

GROUP BY بخاطر استفاده از Aggregate Function
GROUP BY بخاطر دسته بندی کردن رکوردهامن فکر کردم جنابعالی منظورتون مورد دومی است.

در پناه حق موفق باشید و پرتوان

niloufar

شنبه 26 فروردین 1385, 18:52 عصر

سلام
بازم ممنون. ولی:

من الان هم میگم کسی MEMO رو GROUP BY نمیکنه.

البته این کاملا فرق داره با:

هیچ موقع یک فیلد Memo رو PK نمیکنن

ضمن اینکه بنده هم کوئری دوم را بر پایه همین که "فیلد Memo را نمیشه Group By کرد" نوشتم (که البته نباید با "فیلد Memo را نمیشه PK کرد" خلطش کرد)

بازم ممنون

Hamedm

شنبه 26 فروردین 1385, 21:38 عصر

سلام

سلام
بازم ممنون. ولی:

البته این کاملا فرق داره با:

ضمن اینکه بنده هم کوئری دوم را بر پایه همین که "فیلد Memo را نمیشه Group By کرد" نوشتم (که البته نباید با "فیلد Memo را نمیشه PK کرد" خلطش کرد)

بازم ممنونمن DESING دیتابیسو بصورت تخصصی پیش اساتید این زمینه یادگرفتم. الآن هم میگم، هرگز فیلد MEMO رو PK نمیکنند. اگه باورتون نمیکنید، مشابه همین سوال رو در بخش SQL SERVER از آقای ثباتی بپرسید تا خود ایشون به شما توضیح بدند.
البته میشه PK در نظر گرفت ولی طبق اصول طراحی دیتابیس این کار اشتباه است (امیدوارم دیگه بهتون برنخوره که میگم اشتباهه).

در پناه حق موفق باشید و پرتوان

niloufar

دوشنبه 28 فروردین 1385, 16:41 عصر

سلام
من DESING دیتابیسو بصورت تخصصی پیش اساتید این زمینه یادگرفتم. الآن هم میگم، هرگز فیلد MEMO رو PK نمیکنند. اگه باورتون نمیکنید، مشابه همین سوال رو در بخش SQL SERVER از آقای ثباتی بپرسید تا خود ایشون به شما توضیح بدند.
البته میشه PK در نظر گرفت ولی طبق اصول طراحی دیتابیس این کار اشتباه است (امیدوارم دیگه بهتون برنخوره که میگم اشتباهه).

در پناه حق موفق باشید و پرتوان
سلام
آقای محمدی
1- بنده بهم هیچوقت بر نمیخوره که اشتباه کرده باشم، چون خودم باورمه که هنوز هیچی بلد نیستم. بلکه اگه بازم یکی بهم بگه "الآن هم میگم، هرگز فیلد MEMO رو PK نمیکنند" بهم برمیخوره. بنده که عرض کردم دیگه انقدر گیج تشریف ندارم که فیلد Memo رو Pk کنم!!!!!
2- حالا که شما طراحی (همون فارسی رو پاس بداریم Design) رو تخصصا یاد گرفتید، ان شاء الله ما هم از کمک های شما بهره خواهیم برد.
3- بنده هم تو کل این تاپیک عرض نکردم باید فیلد Memo رو Pk کرد که حالا بخوام از اساتید بپرسم میشه یا نه (اونم وقتی خودم میدونم منطقی نیست این کار رو کرد) بلکه فقط میخواستم یه Group By ساده (به همون دلایل که 4 صفحه در موردش بحث کردم: اینو گفتم که دوباره نگید نباید Goup By کرد که عرض کنم حتی کوئری بدون Group Byش رو هم تو همین تاپیک نوشته ام) بزنم که فهمیدم برای فیلد بالای 255 کاراکتر حضرات RDBMS انجامش نمیدن و لذا رفتیم سراغ کوئری دومی که توضیحش قبلا آمد.
4- امیدواریم همیشه از حضور علمی شما در این تالار سود ببریم.