Printable View
سلام
من میخوام توی بانک اطلاعاتی SQL یک سری تصاویر مثل رو دخیره کنم و چون ممکنه تصاویر زیاد بشه روی حجم و سرعت بانک اطلاعات یتاثیر بزاره برای همین می خوام که تصاویر رو به صورت کد و یه جوری رمزگذاری کردم ذخیره کنم که حجم پایین تر بیاد.
ممنون می شم راهنمایی بفرمایید چه طور میشه تصاویر رو به صورت متن و مثلا از نوع ntext یا همچین چیزی ذخیره و سپس برای نمایش بازیابی کرد.
فکر نمی‌کنم با تبدیل عکس به متنِ فشرده، کاهش چندانی در حجم نهایی حاصل بشه . به نظرم بهتره تصاویر را روی هارد ذخیره کنید و مسیر قرارگیری هر یک را در پایگاه داده . در این صورت مشکلِ حجیم شدن دیتابیس و استفاده مفرط از منابع برطرف میشود.
به نظرم قطعا ذخیره به صورت متن از ذخیره به صورت عکس حجم کم تری رو داره . حالا دقیق نمیدونم . باید یه بار امتحان بشه و نتیجه رو بررسی کنیم. شما خودتون امتحان کردید؟؟!!
بله این راه رو بلد هستم ولی من مشکل جا به جایی فایل دیتا بیس و همچین مواردی رو دارم و می خوام که حتما درون دیتابیس تصاویر رو ذخیره کنم.
امتحان کردم . چند فایل عکس رو بعد از تبدیل کردن به متن با gzip فشرده کردم اما هیچ کدوم بیشتر از 1کیلوبایت فشرده نشد.نقل قول:
به نظرم قطعا ذخیره به صورت متن از ذخیره به صورت عکس حجم کم تری رو داره . حالا دقیق نمیدونم . باید یه بار امتحان بشه و نتیجه رو بررسی کنیم. شما خودتون امتحان کردید؟؟!!
تا اونجایی که من می دونم هیچ الگوریتم فشرده سازی کار با پسوند فایل نداره. یعنی چه متنی چه عکس، هر کدام که الگوی بایتی مناسب داشته باشند فشرده می شوند. این از مسئله فشرده سازی.
بحث ذخیره سازی به صورت عکس یا متن هم تفاوتی ندارد. شما اطلاعات یک عکس را مجبورید کامل ذخیره کنید و این می شود مجموعه ای از بایت ها. دوباره شما مجبورید کل یک تصویر را ذخیره کنید حالا این بار دوباره باید بایت هایی را قرار دهید که همان متن هستند و دوباره هیچ فرقی ندارند. تنها در صورتی که نوع فیلد دیتابیس قابلیت Image داشته باشد شما فضای دینامیکی برای عکس خود دارید. حال شما نوع آن را بکن متن. مثلا با 4500 طول. اگر عکس bmp باشد به ازای هر رنگ شما 1500 بایت پیکسل دارید. یعنی رزولوشنی حدود 40 در 40 !. خوب حالا آیا دیتابیس برای چنین کاری بهینه هست؟ آیا طول 4500 رشته ای منطقی است؟ اگر فضای عکس باشد 1M چه؟ یعنی طول یک رشته این قدر زیاد، اصلا طراحی دیتابیس بر این منطق اشتباه است. اصلا آیا اگر این کار صحیح بود نوع فیلد Image و یا Object در دیتابیس ها دیده می شد؟ اگر یک دیتابیس تنها کاراکترهای خاصی را به عنوان Text بگیرد و مطمئنا یک عکس کاراکترهای بی معنی دارد اگر خطا بدهد و در ذخیره سازی اطلاعات مسکل به وجود آید چه؟(احتمال از نظر جابه جایی در windows های مختلف). تکلیف نرم افزارهای جانبی اتصال به DB و datagrid ها و امکانات آن ها با توجه به استفاده غیر صحیح از یک فیلد چه می شود؟ تکلیف script های خاصی که در حین کار ممکن است لازم شود و چون نوع آن فیلد text هست در موتور db نیاز به پردازش پیدا می کنند چه؟(همه از طول بی معنی رشته شامل می شود)نقل قول:
ذخیره به صورت متن از ذخیره به صورت عکس حجم کم تری رو داره
اصلا در صورتی که حجم کار با DB بالاست خوب طبیعتا حجم آن هم بالاست(البته اصول طراحی هم سر جای خود)، مطمئنا رایانه قوی و متناسبی نیز می خواهد.
اگر دقت کرده باشید تصاویر مورد نظر برای ذخیره سازی در دیتابیس ها با یک حداکثر فضا روبه رو هستند. مثلا همین Forum ها. عکس می خواهی UP کنی می گه حداکثر 200 کیلو. شما این مورد را نیز مد نظر داشته باشید. یا اینکه عکس ها را فشرده کنید و سپس در DB ذخیره کنید. و مشکل این روش نیز در ایجاد بار پردازشی است. البته آن هم در تعداد دسترسی های پیاپی به دیتابیس. که اگر دسترسی های پیوسته نباشد قابل صرفه نظر است.
در هر صورت از نظر من هیچ منفعتی در چنین روشی وجود ندارد.
موفق باشید.
خیلی مننون از توضیحات دوست خوبمون [ برای مشاهده لینک ، با نام کاربری خود وارد شوید یا ثبت نام کنید ] که کامل بود.
با این اوصاف به نظرتون چه باید کرد؟! یعنی تصاویر رو از نوع image ذخیره کنم؟ یا روش دیگری هم سراغ دارید برای این کار ؟! البته این مورد جابه جایی اطلاعات ورو هم در نظر بگیرید که خیلی مهم هست. البته اگر ذخیره به صورت Image سرعت کار با دیتابیس رو پایین میاره و یا حجم رو خیلی خیلی بالا می بره مجبورم از این روش منصرف بشم :n27:
به نظرتون با توجه به شرایط من بهترین روش چیه؟؟
سلام
اطلاعاتی که ذات باینری دارند قطعاً با تبدیل به متن (Base-64 یا Hex) حجمشان افزایش می یابد.
هر بایت بایتری 8 بیت است و 8 بیت را در خود جای میدهد ولی در تبدیل به Base-64 هر کاراکتر (کاراکتر اسکی=یک بایت) فقط 6 بیت را در خود جای خواهد داد و این یعنی هر 6 بایت باینری 8 کاراکتر اسکی جای خواهد گرفت !
ضمن اینکه هزینه زمان و اجرایی قابل ملاحظه ای برای تبدیل دیتا بین باینری و Base-64 مدام لازم خواهید داشت.
تنها مکانی که ذخیره سازی Base-64 منطقی میشود جایی است که امکان ذخیره سازی مستقیم باینری ممکن نباشد، مانند ذخیره اطلاعات در قالب فایل های XML ...
مرسی دوست عزیز . حالا به نظرتون من چیکار کنم؟! با توجه به اینکه مشکل جا به جایی اطلاعات و تهیه نسخه پشتیبان ماهانه رو دارم.
سلام
خوب مشکل کجاست؟نقل قول:
حالا به نظرتون من چیکار کنم؟! با توجه به اینکه مشکل جا به جایی اطلاعات و تهیه نسخه پشتیبان ماهانه رو دارم.
یعنی اگر بجای 6GByte فضای هارد از 8GByte استفاده کنید مشکتان حل میشود؟
یا اگر کاری در 10 ثانیه با 1MByte حافظه RAM انجام میشود شما آن را در 15 ثانیه و مصرف دوبرابر RAM انجام دهید مشکلتان حل میشود؟
==============
به عنوان راه حل هایی که حداقل قابلیت بررسی داشته باشد و در شرایطی بتواند عملکردی با بازدهی بهتر داشته باشد دو گزینه دیگر مبتنی بر ذخیره هر فایل بطور مستقل خواهید داشت
ولی به یاد داشته باشید که این دو گذینه تازه قابل بررسی هستند، یعنی نمیتوان گفت همیشه بهتر است، بلکه باید شرایط را سنجید و با توجه به شرایط بین این دو روش و روش عادی ذخیره سازی دیتابیس برای یک پروژه خاص به بهترین شیوه دست یافت.
در پروژه های بزرگ تر و کالمتر که به صورت چندمنظره طراحی میشوند میتوان از تلفیقی از روش های مختلف استفاده کرد که مدیران مربوطه بتوانند ذخیره سازی و جریان اطلاعات را برای رسیدن به بهترین نتیجه از طریق تنظیمات خود برنامه کنترل و مدیریت کنند.
==============
اول قابلیت FileStream در SQLServer
این قابلیت اجازه میدهد فیلدی را در جدول تان برای ذخیره فایل به صورت معمول استفاده کنید ولی اطلاعات این فیلد در فایلهای mdf اصلی ریخته نشود، و هر فایل بطور مستقل در قالب یک فایل ذخیره گردد که ایجاد و حذف و بروزرسانی این فایلها را خود SQLServer انجام خواهد داد و بیشترین تاثیر خود را در شرایطی که اطلاعات شما نیاز به Update زیاد (بزرگ و کوچک شدن مدام) دارند، نشان داده و بازدهی بیشتری از خود ارائه میدهد.
==============
دوم ذخیره دستی اطلاعات بطور مستقیم و توسط خودتان در هارد
بعنوان نمونه جدولی شامل مشخصات و دیتا در دیتابیس داشته باشید و از ID کلید این جدول برای ذخیره و بازیابی فایل ها در هارد استفاده کنید.
(خواستید DLL هم برای کمک در این مورد موجود است)
در این حالت اگر پروژه شما وبی نباشد، یعنی برپایه Application های exe باشد احتمالاً مجبور خواهید شد یک برنامه کوچک Windows Service یا Web Service اضافه نوشته و در سرور نصب کنید تا خدمات امنیت اطلاعات و نقل و انتقال اطلاعات را به سایر exe های کلاینت عرضه کند.
==============
در نهایت به هر طریقی که این کار را انجام دهید استفاده صحیح از مباحث چند ریسمانی و انتقال (دانلود و آپلود) اطلاعات در قالب جریان گرا و بسته های کوچک میتواند به بازدهی کلی پروژه شما کمک بسیار زیادی کند.
در شرایط خاص میتوانید به فشرده سازی اطلاعات هم فکر کرد که اگر در سمت کلاینت ها انجام شود بهتر است.
ولی احتمال دارد روی تصاویر خیلی فایده نداشته باشد.
یا اگر با اسناد اسکن شده و مانند ان سرو کار دارید (که تصاویر متحرک نیستند و شرایطی خاصی مانند کانال آلفا ندارند)، خودتان میتوانید قبل از ذخیره سازی همه انها را به فرمتی مانند jpg تبدیل و سپس ذخیره کنید، اینطوری دیگر نیازی به فشرده سازی و از فشردگی خارج کردن هم نیاز نخواهید داشت.
و...
==============
در متن پست قبلی اشتباهی کردم و "عدد 5 بیت" را به جای "عدد 6 بیت" نوشتم که بدینوسیله اصلاح و عضرخواهی میکنم. (2 بتوان 6=64)
راستش من یکم توی درک این قضیه مشکل دارم و تا حدودی گیج شدم :n02:
راستش این برنامه کاملا محلی و فقط روی کلاینت هست و مبتنی بر وب هم نیست و توی برنامه باید مدارکی رو دریافت کنم . به عبارتی اسکن کنم و درون برنامه ذخیره کنم. اما باید همه ی این ها را در بازه ی زمانی خاص نسخه پشتیبان تهیه و به سیستم دیگری انتقال بدم و تنها مشکل من همین اسکن مدارک هست که به شکل تصویر است و می خوام ببینم اگه تصاویر را درون یک فولدر در مسیر نصب برنامه ذخیره کنم و فقط نام تصویر رو درون دیتا بیس به شکل متن ذخیره کنم بهتره و یا یک فیلد از نوع عکس توی دیتابیس بزارم و عکس رو اونجا ذخیره کنم و یا در نهایت ذخیره عکس به شکل کد هش و یا . . . .
ببخشید واقعا دچار ابهام شدم و هرکاری می کنم نمی تونم درک کنم . :n28: پیشنهاد شما چیه ؟
سلام
نظرش برای من کمی سخت است!نقل قول:
تصاویر را درون یک فولدر در مسیر نصب برنامه ذخیره کنم و فقط نام تصویر رو درون دیتا بیس به شکل متن ذخیره کنم
...
یک فیلد از نوع عکس توی دیتابیس بزارم و عکس رو اونجا ذخیره کنم
ولی بحرحال روی توضیحاتی که دادید و برای کار شما، احتمالاً ذخیره فایلها در یک پوشه، فقط بازدهی سرعتی بهتری ارائه خواهد داد، البته در این حالت پیشنهاد میکنم نام فایلها را از روی ID دیتابیس قرار دهید، اینطور یکتا بودن نام فایلها هم تضمین میشود.
و با توجه به در فقدان پشتیبانی برای شبکه و کلاینت ها احتمالاً حجم کدتان نصب به استفاده از دیتابیس فرقی زیادی نخواهد داشت.
برای پشتیبان گیری هم که خود SQLServer فرمان Backup دارد و برخلاف Restore با دنگ و فنگ کمتری قابل انجام است.
برای پشتیبان گیری پوشه ها هم میتوانید از Zip آن استفاده کنید.
اگه یک فوادر به نام هر یک از ID ایجاد کنم و تصاویر مربوط به اون ID رو توی فولدر مربوط به خودش بریزم چه طوره؟نقل قول:
البته در این حالت پیشنهاد میکنم نام فایلها را از روی ID دیتابیس قرار دهید، اینطور یکتا بودن نام فایلها هم تضمین میشود.
در این مورد کمی توضیح میدید . متوجه منظورتون نشدم؟نقل قول:
برای پشتیبان گیری پوشه ها هم میتوانید از Zip آن استفاده کنید.
سلام
اینها دیگر جزئیات پیاده سازی هستند و شما میتوانید بسته به شرایط روی آنها تصمیم گیری کنید.نقل قول:
اگه یک فوادر به نام هر یک از ID ایجاد کنم و تصاویر مربوط به اون ID رو توی فولدر مربوط به خودش بریزم چه طوره؟
ولی من اگر بودم ترجیح میدادم روابط و وابستگی ها را از طریق جداول دیتابیس نگه داری کنم.
البته، یادش بخیر! برنامه دبیرخانه بود! حدود 10 سال پیش با نسخه های اولیه VB.Net برای نگه داری پیوست های یکسری سند همچین کاری کردم (یعنی برای هر سند یک پوشه می ساختم) و نتیجه اش بد نبود و مشکلی پیش نیامد ولی شما به کسی نگویید:n02: دیگر با اعتقادات نرم افزاری فعلی ام زیاد جور در نمی آید!
کل پوشه را zip میکنید، اسمش میشود backupنقل قول:
... zip ... متوجه منظورتون نشدم؟
[ برای مشاهده لینک ، با نام کاربری خود وارد شوید یا ثبت نام کنید ]
[ برای مشاهده لینک ، با نام کاربری خود وارد شوید یا ثبت نام کنید ]
[ برای مشاهده لینک ، با نام کاربری خود وارد شوید یا ثبت نام کنید ]
[ برای مشاهده لینک ، با نام کاربری خود وارد شوید یا ثبت نام کنید ]
و...