دوستان سلام
اگه در MsAccess دیده باشید فیلدهای از نوع Text حداکثر شامل 255 کاراکتر است و برای متن های بزرگ باید از فیلدهای Memo و اگه دیگه خیلی گردن کلفت باشه از فیلدهای Ole استفاده کرد.
اما ظاهرا Ado.net هیچ کدوم از این دو فرمت را ساپورت نمیکنه. اگه فیلد رو Ole بذاریم، یه پیغام میده که Ole و Memo ساپورت نمیشن و اگه فیلد رو Memo بذاریم، ظاهرا فیلد را میاره ولی فقط 255 کاراکتر اولش رو میاره. یعنی یه جورایی اونو به عنوان یه فیلد Text میبینه.
آیا کسی راهی به نظرش میرسه؟
ممنون
دوباره سلام
ظاهرا Ado.Net فیلد Memo را ساپورت میکنه اما مشکل از یه جای دیگه بود. کوئری ای که من انجام میدادم دارای Group By بود و وقتی یک فیلد Memo گروپ میشه نمیدونم چرا خود به خود 255 کاراکتری (یعنی مثل Text میشه)
در واقع اگه فیلد از نوع Memo در Group By شرکت کنه دیگه نمیشه بیش از 255 تاش رو دید.
از دوستان کسی نظری داره؟
آخرین ویرایش به وسیله niloufar : دوشنبه 14 فروردین 1385 در 19:13 عصر
بخاطر سنگین بودن فیلد Memo نمیشه یه سری اعمال رو روش انجام داد. خود SQL Server برای ساختن Index ها محدودیت گذاشته. این که دیگه Access هستش.
سلام
کار ADO.NET کاملا درست است.نوشته شده توسط niloufar
شما میخواهید فیلد Memo رو که بیش از 255 کاراکتر است رو GROUP BY کنید؟
بنظرم کوئریتونو اشتباه نوشتید. چون GROUP BY برای فیلدهایی عددی و نیز فیلدهای کوتاه، معمولا انجام میشه.
در پناه حق موفق باشید و پرتوان
حامد جان کاملا با نظرت موافقم. بهتره که ما تو کارهامون یه سری استانداردها رو رعایت کنیم.
سلام
1- البته تجربه من از همه دوستان کمتره
2- آقای محمدی کوئری که غلط نیست فرض کن یکی از فیلدهای جدول Master از نوع Memo است و می خواهیم آن را در کنار مثلا تعداد رکوردهای جدول Detail که به هر یک از این رکوردها ربط دارد نمایش دهیم (مثلا برای دادن پیام مبنی بر نیاز به Cascade Delete در هنگام Delete و ...) مسلما اگه فیلدمون Memo نبود باید از Group By استفاده میکردیم. حال اینکه با فیلد Memo (که به قول دوستمون سنگینه) نمیشه این کار را کرد و باید دو کوئری جدا بزنیم یه حرف دیگه ایه...
3- حالا خارج از اینکه این MsAccess یا حتی به قول دوستمون SqlServer (چون من امتحان نکردم) نمیتونن این کار را بکنن یا به خاطر سنگینی اون صلاح نمیدونن، این استاندارد که نباید این کار رو کرد از کجا اومده؟
سلام
من منظورم ساختار دیتابیست بود که مجبور شدی یک فیلد Memo رو GROUP BY کنی.
گفتم که طراحی دیتابیست احتمالا اشتباست چون هیچ موقع یک فیلد Memo رو PK نمیکنند.
اگه میخواهی نحوه کار برنامتو همینجا بگو تا اگه بشه دیتابیستو طراحی کنم. البته مجبوری اون موقع پروژه رو از اول بنویسی.
در پناه حق موفق باشید و پرتوان
سلام
حامد دقیقا درست میگه . معمولا GROUP BY را با کلیدهای اصلی میزنند . حتی اگر بخواهید اطلاعات یک جدول رو در کنار اطلاعات جدول دیگه ای بیارید باید از کلید اصلی دو جدول استفاده کنید .
یا در مورد کوئری اشتباه میکنی و یا اینکه ساختار جدولت مشکل داره . شخصا احتمال اولی رو قویتر میدونم . چون مطمئنا شما فیلد Memo رو کلید اصلی نکردید .
سلام
1- آقای محمدی، اگه یه ذره از حافظتون بیشتر استفاده کنید و یه ذره سابقه من را (که البته مسلما از همه کمتره) لااقل تو این فروم و فروم خدابیامرز VB6 به یاد بیارید، بعید می دونم دیگه هر چه قدر هم کوچیک فرضم کنید، بازم بگید احتمالا فیلد Memo را PK گرفته اید :- ( همانطور که آقای عابدی جو فکر کنم بیشتر یادشون بوده و گفته اند: "چون مطمئنا شما فیلد Memo رو کلید اصلی نکردی"
2- اما بریم سراغ توضیح چیزی که میخوایم بهش برسیم. نیازی هم به بانک ما نیست که بخوایم به هم بریزیمش، همین الان یه بانک میسازیم:
الف - یه جدول داریم که توش اطلاعات کتابها رو ریختیم. اسمشو میذاریم Books که خیلی چیزا داره. یکیش همون BookId باشه که شما خودتون اینو PK بگیرید و نام کتاب و خیلی چیزای دیگه. یکیش هم فیلد Comment باشه که از نوع Memo است و قراره توضیحاتی در مورد هر کتاب (که البته بیش از 255 کاراکتره) توش ریخته بشه (ما هم بخاطر شما اینو یه وقت PK نمیگیریم).
ب - یه جدول هم داریم مثلا به نام BookIndexes که توش قراره فهرست کتابها و اطلاعات اون (مثل BookIndexId که شما PK میگیریدش و BookId که شما FK میگیرید و عنوان هر فهرست و ترتیبش و والدش و ...
ج - حالا میخوایم تو یه کوئری (نگید خوب دو کوئریش کن که شاکی میشم چون خودم تو پست های قبل گفتم و شما مرا متهم به PK قرار دادن فیلد Memo کردید) تمام اطلاعات کتاب ها را در کنار تعداد (Sum) فهرست های مرتبط با هر کتاب بگیریم (تا مثلا اونا رو در یه گرید نشون بدیم). شما کوئریش رو بنویسید.
د- ممنون
آخرین ویرایش به وسیله niloufar : دوشنبه 21 فروردین 1385 در 17:33 عصر
نمی دونم !!! شاید درست نباشه من این طوری بپرم وسط بحث.
اما یه نکته در مورد طراحی دیتابیس ....
البته این نکته رو که می گم جدا از بحث Memo و مشکلته اما خوب...
اگه جدول BookIndexes مربوط به موضوعات کتب است فیلد BookIndexId رو باید تو جدول Books به عنوان FK قرار بدی نه اینکه فیلد BookId رو بذاری تو این جدول. ( یعنی یه جورایی به نظر من برعکس عمل کردی)
اگه هم جدول BookIndexes مربوط به چیزهای دیگس خواهش می کنم بگین چون همون طور که گفتم تاپیک رو دنبال می کنم و دوست دارم کاملا در جریان اون باشم.
باتشکر
سلامنمی دونم !!! شاید درست نباشه من این طوری بپرم وسط بحث.
اما یه نکته در مورد طراحی دیتابیس ....
البته این نکته رو که می گم جدا از بحث Memo و مشکلته اما خوب...
اگه جدول BookIndexes مربوط به موضوعات کتب است فیلد BookIndexId رو باید تو جدول Books به عنوان FK قرار بدی نه اینکه فیلد BookId رو بذاری تو این جدول. ( یعنی یه جورایی به نظر من برعکس عمل کردی
اگه هم جدول BookIndexes مربوط به چیزهای دیگس خواهش می کنم بگین چون همون طور که گفتم تاپیک رو دنبال می کنم و دوست دارم کاملا در جریان اون باشم.
باتشکر
اگه یه کم دقت کنید میبینید که یه کتاب میتونه n تا فهرست کتاب داشته باشه. درواقع رابطه بین کتاب به اندیس، رابطه یک به n است. لذا اگه به قول شما BookIndexId رو در جدول Books به عنوان یه فیلد بذاریم، این یعنی رابطه دقیقا برعکس. ولی اگر BookId رو در BookIndexes بگذاریم یعنی می توانیم n رکورد داشته باشیم (در جدول فهرست) که یک کتاب باشند اما مشخصات فهرستشان متفاوت باشد...
خوب بالاخره کوئری ما چی شد!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
یکی میخواد بدون استفاده از Group By بنویسه و ما هم یاد بگیریم(دوستانی که ...) یا خودم با Group Byش رو بنویسم و یه نتیجه گیری اخلاقی هم تهش بندازیم و تاپیک رو خاتمه بدیم!!!!!
سلام
خودتون از این جمله چیزی میفهمید:
منظورت از فهرست کتابها چیه؟
میتونی 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 تحویل بگیریم (آقا شهریار هم دیدم تو یه تاپیک دیگه یه همچین چیزی رو خواسته بودند، نمیدونم به اینجا ربط داشته یا نه!!)
همین.
دوستان دیگه هم اگه نظری در مورد بحث "علمی" در این تاپیک دارن، خوشحال میشیم وارد بحث شوند.
آخرین ویرایش به وسیله niloufar : شنبه 19 فروردین 1385 در 18:11 عصر
سلام
(منظورش منم)
ببین این حرفو من به هیچ نیتی نگفتم من فقط قصد کمک داشتم (من اگه نیتی جز کمک به دیگران داشتم که با این همه کار روزی nبار به این سایت سر نمیزدم. من که بیکار نیستم. یکی میگفت حامد تو که این قدر به این سایت سر میزنی، حتما خیلی وقت خالی داری (دیگه به این آدم چی میشه گفت...))اصلا انتظار نداشتم از حرفم ناراحت بشید. ببین در یادگیری باید پررو بود. اگه از در انداختند بیرون باید از پنجره وارد بشی (من خودم برای یادگیری خیلی پررو هستم، حتی حاضرم بهم توهین بشه ولی به اون پاسخی که دنبالشم برسم).
ولی بهر حال عذرخواهی منو بپزیرید.
باید دوتا SELECT تو در تو بنویسی. همین.
SELECT بیرونی برای اطلاعات کتاب، SELCET درونی هم برای محاسبه تعداد (COUNT) رکوردهایی که با PK جدول Books در ارتباط هستند.
همین
در پناه حق موفق باشید و پرتوان
آخرین ویرایش به وسیله Hamedm : یک شنبه 20 فروردین 1385 در 16:49 عصر
با اجازه ...
منظورتون از "فهرست" همون "فهرست مندرجات کتاب" است؟
اگه آره :
آخه واسه چی فهرست کتب رو تو بانک ذخیره می کنی؟
سلام
جناب نیلوفر ازتون خبری نیست، مشکلتون حل شد؟
در پناه حق موفق باشید و پرتوان
سلام
خواهش میکنم!!
فرمایش شما کاملا منطقیه و من هم الان همین کار رو انجام میدم. اما قرار بود با یه select این کار را انجام بدیم که در اونصورت نیاز به Group By پیدا میکردیم. توجه داریم که ایجاد دو کوئری نسبت به یه کوئری در سرعت اجرا تاثیر گذار میباشد. بازم توجه داریم که با ایجاد SubQuery و یا Query های حلقه ای در هر دو صورت باعث کندتر شدن عملیات می شویم که همین باعث شده بود که ابتدا بخواهم آنها را طی یک کوئری پیاده سازی کنم که با آن مشکل برخوردم. در واقع اگر فیلد Memo نبود منطقی ترین راه (پر سرعت ترین راه) استفاده از Group By بود
بازم ممنون و اگه شما هم (یا خصوصا آقای عابدی جو به دلایل نامعلوم) و یا دیگر دوستان از من ناراحت شدید بنده هم عذرخواهی میکنم
آخرین ویرایش به وسیله niloufar : یک شنبه 20 فروردین 1385 در 18:01 عصر
پس جواب من چی شد؟
مثل اینکه من یه سوال پرسیده بودم.
دوست عزیز نیلوفر سلام
ببین اینکه میخوای لیست فهرستها را در یک رکورد داشته باشی به نظر من جالب نیست و فکر کنم نشدنیه . آخه از اونجایی که لیست هر کتاب ممکنه متفاوت باشه نمیشه که در یک کوئری رکوردهای با طول متفاوت داشته باشه . شما به نظر من این کار رو بکن . یک InnerJoin بزن . و ابتدا تمامی اطلاعات هر کتاب به همرا فهرست اونا رو یک جا جمع کن . ( مثلا یک جدول موقت )
اگر لازمه تا دستور InnerJoin رو هم بنویسم .
سلامپس جواب من چی شد؟
مثل اینکه من یه سوال پرسیده بودم.
منظور از سوال شما اینه؟
اگه بله، باید عرض کنم که این بستگی به کار بنده و شما داره که چه چیزهایی را باید ذخیره کنیم. این هم یه مثال ساختگی بود تا در مورد موضوع روش بحث کنیم. اما چیز عجیب و غریبی هم نیست، مثلا فرض کنید قراره با انتخاب هر عنوان کتاب، فهرست اون در یه TreeView نمایش داده بشه تا کاربر هر کدومشو که انتخاب کرد، متن اونو ببینه. در اینصورت دیگه برنامه نمیتونه بره و اصل کتب را باز کنه و ازش اطلاعات در بیاره، مجبوره یه جایی (مثل همین بانک یا XML File یا ...) اینا رو نگداری کنده تا موقع لزوم بارگذاریشون کنه.منظورتون از "فهرست" همون "فهرست مندرجات کتاب" است؟
اگه آره :
آخه واسه چی فهرست کتب رو تو بانک ذخیره می کنی؟ آخه به چه درد می خوره؟
سلام
اگه منظورتون از "اینکه میخوای لیست فهرستها را در یک رکورد داشته باشی به نظر من جالب نیست" همون سوال دوستمونه که در اینصورت در پست قبلی جواب دادم.
اما اگه منظورتون به قرینه "فکر کنم نشدنیه. آخه از اونجایی که لیست هر کتاب ممکنه متفاوت باشه نمیشه که در یک کوئری رکوردهای با طول متفاوت داشته باشه" اینه که نمیشه اونا رو با هم گرفت چون مثلا هر رکورد از جدول 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 کاراکتر اول تحویل گرفته میشد که مجبورم کرد برم و از راه دوم استفاده کنم.
ممنون
راستی! ممنون Inner join هم بلدم :- (
اگه میخواید من هر دو کوئری رو (با روش اول و دوم) بنویسم تا نتیجه تاپیک بشه (البته اگه دوستان نظر دیگه ای ندارند)
فکر کنم مثالت یک کمی منو گیج کرد . به خاطر همین هم ممکنه جواب بی ربط داده باشم . به هر حال اگر بتونی یه نمایی از بانک واقعیت رو بزاری و کوئری هات رو هم بنویسی که مرجع خوب بشه واسه دیگران
با تشکر
سلام
چرا سخت میگیرید. من نمی فهمم کجای مباحث مفهوم نیست!! این یه دیاگرام از اون مثال:
اینم کوئری از طریق 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
روشون یه کمی فکر کنید ایشاالله هر دوشونو متوجه میشید. بازم اگه نشد بفرمایید تا هرجاش ابهام بود توضیح دهم
موفق باشید و به قول آقای محمدی پرتوان
سلام
جدا یه نفر از افرادی که تو این بحث بودند، نظری موافق یا مخالف، اشکال، یا هر چیز دیگه ای نداره!!!!!!!
سلام
این کوئری کاملا درسته و بهتر از کوئری زیر است.
در پناه حق موفق باشید و پرتوان
سلام
آقای محمدی خوشحالم که در ته ته تاپیک به سر سر تاپیک برگشتیم :- )
آخه همون زمانها که یادش بخیر هم بنده عرض کردم که باید از Group By استفاده کنیم و بهتره و شما فرمودید: بیکلاس!! آخه کسی فیلد Memo رو PK میکنه (که البته ما هیچ وقت از این غلطا نمیکنیم، یا لااقل غلط به این افتضاحی دیگه نمکنیم).
بی خیال.
فرمایش شما کاملا صحیحه. بنده هم اول همون نظر رو داشتم. فقط وقتی دیدم فیلد Memo در Group By تبدیل میشه به Text ساده 255 کاراکتری، مجبور شدم از راه دوم را پیشنهاد کنم تا هم جواب بگیرم و هم اطلاعات از بین نره.
راستی، ممنون که اظهار نظر کردید. کلی حالم گرفته بود که اینهمه پست تو این تاپیک رد و بدل شد، هیشکی تو نتیجه تاپیک اظهاری از نظر نکرد :- (
سلام
من الان هم میگم کسی MEMO رو GROUP BY نمیکنه.
ببین گروپ کردن بخاطر 2منظور استفاده میشه:
من فکر کردم جنابعالی منظورتون مورد دومی است.
- GROUP BY بخاطر استفاده از Aggregate Function
- GROUP BY بخاطر دسته بندی کردن رکوردها
در پناه حق موفق باشید و پرتوان
سلام
بازم ممنون. ولی:
البته این کاملا فرق داره با:
ضمن اینکه بنده هم کوئری دوم را بر پایه همین که "فیلد Memo را نمیشه Group By کرد" نوشتم (که البته نباید با "فیلد Memo را نمیشه PK کرد" خلطش کرد)
بازم ممنون
سلام
من 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- امیدواریم همیشه از حضور علمی شما در این تالار سود ببریم.
سلام
برای محاسبه یک فیلد که اطلاعاتش از فیلدهای دیگر است چه کار باید کرد ؟
قوانین ایجاد تاپیک در تالار
پاسخ با نقل قول