گفتگو و سوال : تعیین نوع یک فیلد بانک SQL

[Pr0grammer]

سلام....

برای یک برنامه که توش ممکنه سالانه بیشتر از 2000 تا عکس اسکن بشه، اگه بخوام توی بانکم (SQL 2005) یک فیلد تعریف کنم! به نظرتون کدوم راه رو انتخاب کنم :

1- یه فیلد از نوع image و ذخیره عکس ها در این فیلد
2- یه فیلد از نوع مثلاً nvarchar و موقع ذخیره سازی اطلاعات عکس رو در یه مسیر ذخیره کنم و فقط مسیر فایل رو در فیلد ثبت کنم! موقع نمایشش هم مسیر رو از بانک بخونم و توی TImage نشون بدم!

راستش خودم فکر می کنم روش دوم بهتر باشه! اما مسئله اصلی اینه که موقع BackUp گرفتن اطلاعات اگه از Table بک آپ بگیرم، عکس های توی پوشه رو چی کنم!؟

[saed2006]

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

[Pr0grammer]

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

سعید جان، 100% باید Backup داشته باشه! خب، اگه راه اول رو انتخاب کنم، بعد از 2، 3 سال که تعداد اطلاعات رفت بالای 10000 ، سرعت پایین نمی یاد!!؟ :متفکر:

[Mahmood_M]

سلام
2000 رکورد برای SQL زیاد نیست اما چون تمام رکوردهات دارای عکس هستن ، پس می تونه حجم بانک رو زیاد کنه ، اگه سرعت واست مهمه و کم بودن حجم کارایی برنامت رو زیاد میکنه که حتما همینطوره ، می تونی فقط آدرس عکسها رو ذخیره کنی ، اما یک مشکلی که توی این روش هست اینه که اگه تعداد فایلها در یک پوشه بیشتر از چند هزار باشه ، وقتی پوشه رو باز میکنی ، Explorer ویندوز نمی تونه جوابگو باشه ( بدون در نظر گرفتن این که مشخصات سخت افزاری سیستم چی هست ) و سیستم هنگ می کنه ، این موضوع میتونه برای کاربر برنامه آزار دهنده باشه ، باید سعی کنی تا حد امکان پوشه رو در دسترس کاربر نزاری ، یا اینکه عکسهات رو گروه بندی کنی و برای هر گروه یک پوشه بسازی تا عکسها تقسیم بشن ( مثلا می تونی بر اساس تاریخشون تقسیم بندی کنی ، یعنی مثلا عکسهای هر ماه رو توی یک پوشه بزاری ) ...
نکته دیگه این که امکان حذف کردن عکسها توسط کاربر یا هر کس دیگه ای هست ...
و ...
این موارد رو می تونی به کاربر اطلاع بدی ...

اگه این موضوعات مشکلی ایجاد نمی کنه می تونی فقط آدرس رو ذخیره کنی ...

اما مسئله اصلی اینه که موقع BackUp گرفتن اطلاعات اگه از Table بک آپ بگیرم، عکس های توی پوشه رو چی کنم!؟
برای BackUp هم می تونی همه عکسها رو در یک فایل ذخیره کنی ، از کامپوننتهای فشرده ساز ، مثل Zip یا Rar استفاده کن ... ، یعنی :
ابتدا رکوردها و سایر اطلاعات جدول رو در یک فایل قرار بده ، بعد فایل ایجاد شده رو همراه با عکسها در یک پوشه قرار بده ، و بعد همشون رو با هم در یک فایل ذخیره کن ( با کامپوننتهای فشرده ساز (http://www.google.com) )
باید سعی کنی حجم عکسها رو قبل از ذخیره کم کنی ، مثلا عکسها با فرمت Gif باشن یا JPG ...

یک کامپوننت دیگه هم در سایت آقای خیلیل زاده هست (http://www.salarsoft.somee.com/all_downloads.htm) که کارش ترکیب چند فایل با هم هست ، می تونه برای ذخیره فایلهای عکس و جداول در یک فایل کمک کنه ( اسم فایل AnyFileCollector هست ) ...

موفق باشی ...

[m-khorsandi]

بهترين و مطمئن‌ترين راه استفاده از يك فيلد Image در كنار ساير فيلدها هست،
مهمترين نكته‌ای كه اين مسئله داره، يكپارچگی اطلاعاتت هست، در عوض ميتونی از File Groupهای SQL Server استفاده كنی كه برای قرار دادن فيلدهای Image (و كلاً حجيم) روی يك فايل ديگه كه به SQL Server متصل هست.
قبلاً در مورد اين موضوع صحبت شده.

[Pr0grammer]

دوستان من بعد از اینکه تمام تاپیک هایی که در این مورد مطرح شده بود مطالعه کردم! به این نتیجه رسیدم! میشه بگید چطوره؟!

من میگم :
یه فیلد تعریف کنم که خوده فایل عکس توش ذخیره بشه! و یه فیلد دیگه برای یه مسیر!
حالا موقع ذخیره سازی اطلاعات، عکس رو توی یه فولدر کپی کنم و مسیرش رو توی فیلد دومی ذخیره کنم! خوده عکس رو هم توی فیلد اولی!

موقع استفاده از عکس، اول چک کنم که فایل (در مسیری که از فیلد دومی خونده میشه) وجود داره یا نه!؟
اگه بود که از همونجا عکسو نشون بدم! اگه نبود (مثلاً حذف شده بود)، عکس رو از فیلد اولی توی مسیر کپی کنم و دوباره از اونجا نشون بدم!

اما راستش این سوال برام مطرح شده :
ذخیره سازی عکس ها به چه علتی باعثه کاهش سرعت میشه؟!
یعنی اگه مثلاً 10000 تا عکس توی بانک ذخیره بشه! ولی عملاً برای نشون دادنشون ازشون استفاده نشه ممکنه باز سرعت کند بشه؟!
در واقع کند شدن بانک، به حجم جدول بستگی داره یا موقع بارگذاری عکس توی برنامه اتفاق می افته؟! (چون ذخیره عکس خب، حجم بانک رو خیلی بالا می بره دیگه!)

[Pr0grammer]

بهترين و مطمئن‌ترين راه استفاده از يك فيلد Image در كنار ساير فيلدها هست،
مهمترين نكته‌ای كه اين مسئله داره، يكپارچگی اطلاعاتت هست، در عوض ميتونی از File Groupهای SQL Server استفاده كنی كه برای قرار دادن فيلدهای Image (و كلاً حجيم) روی يك فايل ديگه كه به SQL Server متصل هست.
قبلاً در مورد اين موضوع صحبت شده.

در مورد Fie Group هم یه بررسی توی سایت کردم، اما خب، من خیلی حرفه ای نیستم، و احتیاج به یه Sample یا یه Help خوب در مورد به کارگیری File Group در دلفی دارم :ناراحت:

[saed2006]

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

[vcldeveloper]

شما با ذخیره عکس توی دیتا بیس سرعت رو کاهش میدین حالا چه اطلاعات از فیلد تصویر خونده بشه چه نشه
نه، SQL Server داده های فیلدهای باینری و Image را جدای از سایر فیلدها نگهداری میکنه. اگر کوئری شما کاری به کار فیلدهای باینری و Image نداشته باشه، وجودشان تاثیری بر سرعت کوئری شما نداره. اما اگر قرار باشه چندین کلاینت به سرور وصل باشند، و بعضی از کوئری ها نیاز به فیلدهای باینری داشته باشند، و بعضی نداشته باشند، اگر کل داده ها روی یک هارد دیسک باشند، و درخواست ها تقریبا همزمان - یا به تعداد زیاد - باشند، کوئری هایی که نیاز به فیلدهای باینری ندارند هم باید معطل کوئری هایی که نیاز به فیلد باینری دارند بشند، چون هد هارد نمیتونه در یک لحظه دو جای مختلف باشه.

اگر در کوئری های خودتان باید داده های فیلدهای باینری و Image را هم واکشی کنید، اون وقت File Group مطرح میشه. می تونید از دو هارد دیسک استفاده کنید، و داده های موجود در هر File Group را روی یکی از این دیسک ها قرار بدید، تا حجم بالای داده های باینری و کندی خواندن محتوای آنها تاثیر منفی چندانی روی کوئری هایی که نیازی به فیلدهای باینری ندارند، نذاره.

[saed2006]

جالبه یعنی اگر فیلد عکس داخل اطلاعات پرسنلی باشه واسه جستجوی اطلاعات هر پرسنل زمان زیادی تلف نمیشه؟؟!!!!!!!!
به نظر من شما بهتره فیلد عکستون رو توی جدول جدا ذخیره کنید تا سرعت دسترسی به اطلاعات پرسنلی رو بالا ببرید.

[m-khorsandi]

جالبه یعنی اگر فیلد عکس داخل اطلاعات پرسنلی باشه واسه جستجوی اطلاعات هر پرسنل زمان زیادی تلف نمیشه؟؟!!!!!!!!


نه، اگر فيلد تصوير داخل جدول اطلاعات پرسنلی باشه و اون رو با استفاده از FileGroupها روی فايل ديگه‌ای قرار بديد سرعت جستجو‌ كم نميشه.



به نظر من شما بهتره فیلد عکستون رو توی جدول جدا ذخیره کنید تا سرعت دسترسی به اطلاعات پرسنلی رو بالا ببرید.



اگر در کوئری های خودتان باید داده های فیلدهای باینری و Image را هم واکشی کنید، اون وقت File Group مطرح میشه. می تونید از دو هارد دیسک استفاده کنید، و داده های موجود در هر File Group را روی یکی از این دیسک ها قرار بدید، تا حجم بالای داده های باینری و کندی خواندن محتوای آنها تاثیر منفی چندانی روی کوئری هایی که نیازی به فیلدهای باینری ندارند، نذاره.


در ضمن استفاده از دو هاردديسك به دليل اينكه عمليات واكشی‌ و جستجو به صورت موازی انجام ميشه و وقفه‌ای بين انجام پيش نمياد، تاثير مثبتی روی سرعت واكشی ميگذاره.

[vcldeveloper]

نه، اگر فيلد تصوير داخل جدول اطلاعات پرسنلی باشه و اون رو با استفاده از FileGroupها روی فايل ديگه‌ای قرار بديد سرعت جستجو‌ كم نميشه.
محمد جان، فکر کنم اگر روی FileGroup دیگه ایی هم قرار نده، تاثیر چندانی روی سرعت واکشی سایر فیلدها نداشته باشه؛ چون فیلدهای باینری در همون ساختاری که سایر فیلدها قرار دارند، و SQL Server روی آن جستجو انجام میده، قرار نمیگیرند، بلکه SQL Server یک Pointer در ساختار مربوطه قرار میده که به داده های اصلی باینری اشاره میکنه. به این ترتیب، اگر نیاز باشه ساختار مربوطه پیمایش بشه، SQL Server داده های باینری را پیمایش نمیکنه. در واقع میشه گفت که حداقل دو لیست نگهداری میشه: یک لیست شامل فیلدهای معمولی و اشاره گرهای مربوط به فیلدهای باینری، یک لیست هم مربوط به فیلدهای باینری.

البته درباره اینطور جزئیات مربوط به چگونگی کارکرد SQL Server، آقای امین ثباتی در بخش SQL Server بهتر می تونند توضیح بدند.