مزایا و مضرات ذخیره داده های باینری در جدول SQL در مقابل یک درایو شبکه چیست؟[کپی]

من در حال خواندن "کد فریم ورک برنامه نویسی ابتدا" (http://www.amazon.com/programming-entity-framework-code-first/dp/1449312942). چندین مثال وجود دارد که اطلاعات مربوط به شخص خاص در یک جدول SQL ذخیره می شود ، از جمله عکس شخص (یک تصویر دیجیتالی که در یک قسمت لاک ذخیره شده است). در تمام سیستمهایی که من روی آن کار کرده ام ، هر نوع پرونده مرتبط با یک رکورد در SQL در یک درایو شبکه معمولی ذخیره می شود. نه در SQL. من تصور می کنم که باید دلایلی برای این امر وجود داشته باشد ، بنابراین سؤال من در اینجا وجود دارد: مزایا و مضرات ذخیره داده های باینری در یک جدول SQL در مقابل ذخیره همان داده های باینری در یک درایو شبکه چیست. ضبط در SQL؟

• طراحی پایگاه داده

دنبال کردن از 28 ژانویه 2013 در 15:05 پرسید رودخانه ویویان رودخانه ویویان 151 1 1 نشان طلا 1 1 نشان نقره 5 5 نشان برنز

3 پاسخ 3

مرتب شده توسط: تنظیم مجدد به طور پیش فرض

یک مزیت این است که اگر برنامه ای که نیاز به دسترسی به داده ها دارد به سیستم فایل دسترسی نداشته باشد ، مشکلی نیست! اگر به پایگاه داده توسط چندین برنامه در سیستم های مختلف دسترسی داشته باشد ، احتمالاً آنها نباید از سیستم فایل به سرور پایگاه داده شما دسترسی داشته باشند. شما همیشه می توانید یک مسیر را ذخیره کنید و آنها یک سرویس وب ایجاد کنید تا این برنامه ها بتوانند پرونده را در یک مسیر خاص درخواست کنند ، اما این کار کمی بیشتر است ، بنابراین بهتر است مطمئن باشید که ارزش آن را دارد. نگه داشتن داده های باینری در پایگاه داده و بازگشت آن در مجموعه ضبط ساده تر است.

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

دنبال کردن 28 ژانویه 2013 در 15:10 پاسخ داد DesportwithFormSdesigner DespurdWithFormSdesigner 3،327 17 17 نشان نقره 20 20 نشان برنز

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

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

حال پس ، چه زمانی این رویکرد معتبر است؟برای حباب های عمدتا فقط خواندنی ، و به ویژه هنگامی که شما قادر به استراتژی هستید که آنها را در حافظه ذخیره می کنید به گونه ای که به حداقل می رسد چند بار از دیسک خوانده می شود ، به خصوص اگر هر نوع بار جدی وجود داشته باشد. به عنوان مثال ، اگر این یک سرور وب است ، بیشتر وب سایت ها برای انجام این کار با داده های استاتیک متداول که فقط باید برای URL روشن کنید ، برای URL که این حباب ها از آن استفاده می کنید ، در استراتژی های تنظیم شده ساخته شده اند.

در هر دو سناریو ، محل شبکه پایگاه داده و یا پرونده های مربوط به پایگاه داده باید یکسان باشد: با تمام شدن همه قفل شده است. شما اجازه دسترسی به این منابع را نمی دهید زیرا شخصی ممکن است پایگاه داده شما را از بین ببرد ، یا آن دسته از پرونده هایی که مربوط به پایگاه داده است و بنابراین بخشی از پایگاه داده در حقیقت است. جابجایی/حذف/تغییر نام/تغییر آنها همان انجام این کار در یک رکورد پایگاه داده است. بر این اساس با امنیت رفتار کنید.

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

توجه داشته باشید جانبی ، هنگام ذخیره حباب ها در پایگاه داده ، هر کدام از میزها را در آن قرار دهید ، ایده خوبی است که در گروه های فایل جداگانه از سایر بخش های پایگاه داده قرار دهید تا بتوانند به مرور زمان به LUN های بزرگتر منتقل شوند زیرا رشد آنها از بقیه شما فراتر می رودبانک اطلاعاتی ، و برای کمک به آنها در عدم مداخله در عملکرد IO یا پرس و جو بقیه پایگاه داده خود.