مشکل با تصاویر در بانک اطلاعاتی

[Harry]

سلام دوستان .
من یه بانک اطلاعاتی دارم که سه تا فیلد داره .
ID = Integer
Name = String
اولی که واضحه . دومی هم که نام کشور هستش و فیلد سوم هم (که ننوشتم)تصویر پرچم های کشورها داخلش هست .
خوب مشکل من با فیلد سومه که داخل آن تصویر هستش که تصاویر به صورت باینری ذخیره شده و پسوند تصاویر داخلش هم WMF هست ، به همین دلیل توی دلفی که می خوام از این فیلد برروی یک DBImage استفاده کنم با پیغام "Bitmap Image is not valid" روبرو می شوم . حالا می خواستم ببینم آیا راهی وجود داره تا به وسیله اون بتونم پسوند عکسهای داخل این فیلد رو به BMP تغییر بدم یا نه ؟ یا به هر طریقی از این عکسها در دلفی استفاده کنم ؟
Please Help Me AS SOON AS Possible :( .

ذخیره کردن عکس توی بانک اصلا کار درستی نیست شما جای اینکه عکس رو توی بانک نگه داری یه دایرکتوری کنار برنامه درست کن عکس ها رو بریز اونتو بعد جای خود عکس توی بانک مسیر اون رو ذخیره کن ضمنن کامپوننت image با فایلهای wmf.* مشکل نداره احتیاج به تبدیل هم نیست

[Harry]

ضمنن کامپوننت image با فایلهای wmf.* مشکل نداره احتیاج به تبدیل هم نیست

پس این پیغام برای چیه؟

من نمیدونم تو چیکار کردی
ولی این عکسی که میبینی عکس پنجره load picture کامپوننت image هست میبینی که با *.wmf مشکل ندراه
توضیح بده چیکار کردی این پیغام رو داد

[Kambiz]

ذخیره کردن عکس توی بانک اصلا کار درستی نیست شما جای اینکه عکس رو توی بانک نگه داری یه دایرکتوری کنار برنامه درست کن عکس ها رو بریز اونتو بعد جای خود عکس توی بانک مسیر اون رو ذخیره کن ضمنن کامپوننت image با فایلهای wmf.* مشکل نداره احتیاج به تبدیل هم نیست

اتفاقا کار درستیه. :wink:

یکی از هدفهای اصلی استفاده از بانکهای اطلاعاتی ایجاد یکپارچگی (Consistency) و تشخیص روابط بین موجودیتهاست و به همین منظور هم در بانکهای اطلاعاتی فیلدهای Blob (یا مشابه اون) وجود دارند. علاوه بر این وقتی که تصاویر رو در فایل بگذاریم مثل این می‌مونه که از دو تا بانک اطلاعاتی استفاده کردیم، یکی بانک اطلاعاتی برنامه و دیگری File System سیستم عامل. پس نه تنها چیزی به دست نیاوردیم٬ بلکه چیزهایی هم از دست دادیم.

[Kambiz]

بجای TDBImage از TDBPicShow استفاده کن و اگر تمام تصاویری که داری Metafile هستند، در رویداد OnGetGraphicClass این کامپوننت کد زیر رو بنویس:

procedure TForm1.DBPicShow1GetGraphicClass(Sender: TObject;

  var GraphicClass: TGraphicClass);

begin

  GraphicClass := TMetafile;

end;

یکی از هدفهای اصلی استفاده از بانکهای اطلاعاتی ایجاد یکپارچگی (Consistency) و تشخیص روابط بین موجودیتهاست و به همین منظور هم در بانکهای اطلاعاتی فیلدهای Blob (یا مشابه اون) وجود دارند. علاوه بر این وقتی که تصاویر رو در فایل بگذاریم مثل این می‌مونه که از دو تا بانک اطلاعاتی استفاده کردیم، یکی بانک اطلاعاتی برنامه و دیگری File System سیستم عامل. پس نه تنها چیزی به دست نیاوردیم٬ بلکه چیزهایی هم از دست دادیم.

میشه بگین چه چیزی رو از دست میدیم؟

[Kambiz]

یکی از هدفهای اصلی استفاده از بانکهای اطلاعاتی ایجاد یکپارچگی (Consistency) و تشخیص روابط بین موجودیتهاست و به همین منظور هم در بانکهای اطلاعاتی فیلدهای Blob (یا مشابه اون) وجود دارند. علاوه بر این وقتی که تصاویر رو در فایل بگذاریم مثل این می‌مونه که از دو تا بانک اطلاعاتی استفاده کردیم، یکی بانک اطلاعاتی برنامه و دیگری File System سیستم عامل. پس نه تنها چیزی به دست نیاوردیم٬ بلکه چیزهایی هم از دست دادیم.

میشه بگین چه چیزی رو از دست میدیم؟

گفتم که! یکپارچگی، روابط بین موجودیتها، و تا حدودی سرعت.

یکی از هدفهای اصلی استفاده از بانکهای اطلاعاتی ایجاد یکپارچگی (Consistency) و تشخیص روابط بین موجودیتهاست و به همین منظور هم در بانکهای اطلاعاتی فیلدهای Blob (یا مشابه اون) وجود دارند. علاوه بر این وقتی که تصاویر رو در فایل بگذاریم مثل این می‌مونه که از دو تا بانک اطلاعاتی استفاده کردیم، یکی بانک اطلاعاتی برنامه و دیگری File System سیستم عامل. پس نه تنها چیزی به دست نیاوردیم٬ بلکه چیزهایی هم از دست دادیم.

میشه بگین چه چیزی رو از دست میدیم؟

گفتم که! یکپارچگی، روابط بین موجودیتها، و تا حدودی سرعت.

منظورمو متوجه نشدین
میخام بگم اگه غیر از سرعت اون دوتای دیگه رو از دست بدیم چه اتفاقی میافته؟؟؟؟؟؟؟؟؟؟

[Kambiz]

بگذار با یک مثال این مسئله رو پیگیری کنیم تا ببینیم دو حالت استفاده از فایل تصویر و فیلد تصویر چه مزایا یا معایبی دارند.

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

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

با این فرضیات٬ بطور متوسط تعداد نقشه‌های موجود در بانک می‌شه:

10,000 * 50 * 20 = 10,000,000

اگر نقشه‌ها رو بصورت فایل داشته باشیم باید تعداد ده میلیون نقشه رو تو File System قرار بدیم. یعنی ده میلیون مشخصه اضافی شامل نام فایل٬ تاریخ ایجاد٬ تاریخ اصلاح٬ تاریخ دستیابی ٬ خصوصیات٬ سطح دسترسی٬ و غیره. با فرض اینکه برای هر فایل این مشخصات تنها پنجاه بایت رو اشغال کنند٬ کل حجم اشغال شده و بیمصرف برای ما عبارت است از:

10,000,000 * 50 Bytes = 500,000,000 Bytes ~ 0.5 GB

جدا از این هیچ سیستم عاملی دارای یک چنین File System پیشرفته‌ای نیست که قادر باشه این تعدا فایل رو مدیریت کنه. حتی با داشتن تعداد چند هزار فایل در یک دایرکتوری٬ زمان مورد نیاز برای دستیابی به فایلها به شدت افزایش پیدا می‌کنه.

حال اگر اندازه هر نقشه رو بطور متوسط صد کیلو بایت بگیریم، اندازه کل نقشه‌ها می‌شه:

10,000,000 * 100 KB = 1,000,000,000 KB ~ 1,000,000 MB ~ 1,000 GB ~ 1 TB

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

علاوه بر این وقتی که نقشه‌ها بر روی فایل قرار داشته باشند٬ ابتدا باید نام فایل رو از بانک اطلاعاتی بازیابی کنیم و دوباره یک بار دیگه یک جستجو در دایرکتوری (که توسط File System انجام می‌شه) بکنیم تا بتونیم تصویر رو تو حافظه بخونیم. اگر تصویر در بانک اطلاعاتی قرار داشته باشه تنها به یک بار بازیابی نیاز هست نه دو بار.

---------------------------------

حالا فرض رو بر این بگذاریم که یک File System معرکه داریم که هیچکدوم از مشکلات بالا رو نداره. خوب٬ دیگه چه مشکلی ممکنه پیش بیاد؟

تصمیم گرفته می‌شه که برنامه روی شبکه (محلی یا اینترنت) قرار بگیره. اگر نقشه‌ها رو بصورت فایل داشته باشیم دست کم تو بانک اطلاعاتی باید نام تمام فایلها رو تغییر بدیم و نام ماشین رو هم بهش اضافه کنیم.

حالا می‌گیم دو خط برنامه کار تغییر فیلد نام فایل رو انجام می‌ده. اما مشکل اصلی چیز دیگه هست: برنامه‌های Client باید به فایلها دسترسی مستقیم داشته باشند و اگر قرار بر اینه که رکوردی رو اضافه و اصلاح هم بکنند٬ به دسترسی نوشتنی نیاز دارند. به عبارتی یا باید یک دایرکتوری رو تو شبکه در اختیار همه قرار داد و به همه هم اعتماد کرد که دستی فایلی رو حذف نکنند یا تغییر نام ندن٬ یا اینکه برنامه رو انداخت دور. حتی اگر تو مدینه فاضله باشیم و به همه هم بشه اعتماد کرد باز باید یک فکری برای Lock کردن فایلها بکنیم تا اگر چند نفر با هم همزمان خواستند نقشه‌ای رو تغییر بدن مشکلی ایجاد نشه.

اگر فایلها در بانک اطلاعاتی ذخیره شده بود چه مشکلی پیش می‌آمد و چه تغییری نیاز بود؟ واقعا" هیچی.

باز فرض می‌کنیم که شبکه‌ای در کار نیست و این مشکل بالا هیچوقت برامون پیش نمیاد. یک داستان دیگه: کارفرما تصمیم می‌گیره که قطعات مربوط به یک هواپیما رو فوق سری اعلام کنه و از این به بعد فقط گروهی از کاربران می‌تونند به این اطلاعات محرمانه دسترسی داشته باشند. اگر تصاویر در بانک اطلاعاتی بودند تنها با گرفتن دسترسی از بقیه کاربران مشکل حل بود٬ ولی برای تصاویری که در فایل هستند باید برنامه رو تغییر داد و کلی کار کرد تا شاید به نتیجه دلخواه رسید. در نظر داشته باش که در این حالت باید یک بار برای بانک اطلاعاتی سطح دسترسیها رو مشخص کرد و یک بار هم برای File System.

باز اگر فرض رو بر این بگذاریم که هیچوقت مشکل بالا پیش نمیاد٬ هنوز یک مشکل دیگه پیش رومون هست که هیچ ارتباطی هم به کارفرما نداره. مشکل قضا و قدر! هین کار برق می‌ره یا کامپیوتر خراب می‌شه. حالتی رو در نظر بگیر که اطلاعات مربوط به یک قطعه رو وارد کردیم و یک سری از نقشه‌های مربوطه رو هم اصلاح و در دایرکتوری ذخیره کردیم٬ اما قبل از (Commit) ثبت شدن بقیه اطلاعات برق می‌ره. اطلاعات اون رکورد قدیمه اما برخی نقشه‌ها به روز شده‌اند. با این وضعیت به اطلاعات موجود در بانک اطلاعاتی نمی‌شه صد در صد اعتماد داشت.

اگر بانک اطلاعاتی از ارتباط موجود بین تک تک اطلاعات (شامل نقشه‌ها) خبر داشت٬ کل اطلاعات رو یکجا ثبت می‌کرد و اگر در هین کار مشکلی پیش میامد٬ کل اطلاعات مرتبط به هم و هر چند قدیمی رو (Roll Back) برمی‌گردوند. نصفه نیمه بروز شدن برخی اطلاعات برای ارتباطات Master/Detail پیچیده ممکنه اصلا" قابل تشخیص نباشه.

---------------------------------

در قسمت اول صحبتم دلایلی از بهینه بودن (حجم و سرعت) استفاده از فیلد تصویر به جای فایل تصویر رو گفتم و در ادامه هم برخی مزایای در نظر گرفتن یکپارچگی و روابط بین اطلاعات رو در نگهداری و توسعه یک سیستم اطلاعاتی. امیدوارم با این مثالها چراها بی‌جواب نمونده باشند.

واقعا عالی بود سنگ تموم گذاشتین
مرسی
دستتون درد نکنه :wink:
الهی شامپو هیچ وقت تو چشم اقای خجسته نره :)

[Inprise]

من با توضیحات شما در مورد بخش "سرعت" چندان موافق نیستم . دلائل رو ذکر خواهم کرد ( الان موقعیتش نیست ) اما بخش دوم رو بسیار عالی توضیح دادید , ممنون :oops:

[majid_n]

کامبیز جان مرسی کلی چیز یاد گرفتم .
وجود افرادی مثل شما توی این سایت واسه ما غنیمته . :oops:

[Harry]

سلام .
آقا کامبیز نمی دونم اشکال کارم از کجاست چون از کامپوننت شما هم که استفاده کردم با یکی از سه پیغام زیر روبرو می شدم .
"Bitmap Image is not valid"
"Read Stream Error"
"Tmetafile is not valid"


:( :( :( :(

تشکر

[Kambiz]

سلام .
آقا کامبیز نمی دونم اشکال کارم از کجاست چون از کامپوننت شما هم که استفاده کردم با یکی از سه پیغام زیر روبرو می شدم .
"Bitmap Image is not valid"
"Read Stream Error"
"Tmetafile is not valid"


:( :( :( :(

تشکر

به نظر میاد که تصاویر رو درست داخل فیلد نریختی.


از همه دوستانی که منو مورد لطفشون قرار دادند تشکر می‌کنم.

[Kambiz]

بجای TDBImage از TDBPicShow استفاده کن و اگر تمام تصاویری که داری Metafile هستند، در رویداد OnGetGraphicClass این کامپوننت کد زیر رو بنویس:

procedure TForm1.DBPicShow1GetGraphicClass(Sender: TObject;

  var GraphicClass: TGraphicClass);

begin

  GraphicClass := TMetafile;

end;

کامپوننت رو تغییر دادم و تو ویرایش جدید دیگه برای Metafile نیازی به استفاده از رویداد OnGetGraphicClass نیست.

[jirjirakk]

تشکر آقا کامبیز ::‌خیلی حال دادی ::

[Kambiz]

من با توضیحات شما در مورد بخش "سرعت" چندان موافق نیستم . دلائل رو ذکر خواهم کرد ( الان موقعیتش نیست ) ...

اینپرایز جان ما رو که فراموش نکردی؟

تشکر آقا کامبیز ::‌خیلی حال دادی ::

خواهش می‌کنم٬ قابلی نداشت.

[SReza1]

بابا این آقا کامبیز سلطانه دلفیه!!خیلی کارش درسته!!

[Kambiz]

آقا رضا قرار نبود شرمندم کنی. :oops:
می‌دونی، اگر تو این حرفه کارم درست بود، باید وضع جیبم هم درست بود که نیست! :(