هل هو جيد لتخزين سلاسل طويلة في قاعدة البيانات؟
https://stackoverflow.com/questions/1438471
-
08-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
Russianسؤال
وأحتاج لتخزين السلاسل الطويلة في قاعدة بيانات. قد تكون سلسلة 5 أو 6 جمل طويلة. هل تعتقد أن هذا هو استراتيجية التصميم الجيد. أو ينبغي أن تخزين معرف لهذه السلسلة ومن ثم إنشاء علاقة مع جدول آخر الذي يحتوي على موقع الملف تخزين السلسلة. هل يمكن أن يرجى إعطاء مزايا وعيوب كل من.
تم preprocessedوالجمل وتخزينها في قاعدة البيانات. إن أي تعديل قراءة السلسلة بأكملها، ويحل محله تماما. لذلك يمكنك أن تفترض أن السلسلة لا تتجزأ.
المحلول
وينبغي أن يكون على ما يرام لتخزين السلسلة في قاعدة البيانات. إذا قمت بتخزين مؤشر ملف بدلا من ذلك، وهذا يعني أنك بحاجة إلى القيام ملف I / O في كل مرة كنت تريد أن تقرأ السلسلة. وبعض الجمل ليست طويلة بشكل رهيب، ويمكنك دائما استخدام حقل بيانات longtext إذا كنت في حاجة إليها. من الواضح ستكون قاعدة البيانات الخاصة بك أكبر قليلا لأن لديك النص، ولكن هذا على ما يرام. فمن المؤكد أنها بديل أفضل من الحاجة إلى تخزين الملفات.
نصائح أخرى
والسلاسل التي ذكرتها ليست على الإطلاق منذ فترة طويلة.
عند يشار إلى سلاسل "طويلة"، وأنا أفكر في 32KB فما فوق - بعض الجمل هي <1KB - أن لا شيء اليوم
وخدعة لديك، تخزين معرف يجعل الأمور أبطأ لأن لديك لجعل الوصول غير المباشر.
والشيء الوحيد الذي أود أن يوصي، عند الحاجة أقصى قدر من الأداء، يجب عليك فقط تحديد هذه الأعمدة التي تحتاجها (حذف SELECT *) - لذلك بحذف عمود نص، عند عدم الحاجة إليها، منذ نقل سلسلة من خادم لتطبيق تكاليف معظم الوقت. وهو التطبيق العملي الجيد، وليس للمس الأعمدة لا حاجة (وخاصة عندما قد تحتوي على بيانات كثيرة).
والسبب الوحيد الذي أود أن إنشاء جدول منفصل إذا كانت هذه السلاسل الطويلة سوف تكون هي نفسها بالنسبة للعديد من السجلات. وإلا لمجرد المضاعفات الإضافية التي ليس من المرجح أن تقدم أي الاسترداد.
وخمسة أو ستة جمل ليست لDBMS الحديثة! تخزين النص مباشرة في قاعدة البيانات.
(التقنية الأخرى التي ذكرها - تخزين المرجع إلى جدول آخر الذي في حد ذاته لديه المرجع إلى ملف خارجي عقد النص - ستكون أكثر تعقيدا بكثير لاستخدام ويكون الأداء أكثر فقرا)
والجواب يعتمد حقا على حجم سلاسل كنت تنوي تخزين، وما DB كنت تنوي استخدام لتخزينه. إذا كنت لا تخزين العديد من سلاسل، قد ترغب في النظر في تخزينها في ملف XML أو الموارد، وتحميل هذا في التطبيق الخاص بك في خط الهجوم. إذا كان لديك الكثير من البيانات سلسلة الرغم من ذلك، سوف تكون على الأرجح أفضل حالا memorywise قراءة سلسلة، وعندما كنت في حاجة إليها، بدلا من أخذ فرصة قراءة سلسلة إلى الذاكرة التي لا ينتهي باستخدام.
وقاعدة البيانات نفسها ليس لديها مشكلة حقيقية مع تخزين السلاسل الطويلة. تطبيق بعض القيود (مثل الحد 8K حجم قياسي على SQL Server)، ولكن حتى ذلك الحين يمكن تخزين نص طول التعسفي في قاعدة بيانات، وذلك لأن جميع تلك المناسبة تدعم أنواع البيانات BLOB / TEXT مع عدم وجود الحد الأعلى تقريبا.
وخمسة إلى ستة الجمل ليست طويلة حقا. إذا كانوا ينتمون معا، والمقصود المراد استردادها والتلاعب ككل، يمكنك ان تمضي قدما وتخزينها في حقل CHAR نوع بيانات أبعاد مناسبة.
سؤال عما إذا كان للفصل بينهما وإرفاق ID لهم ينشأ إلا إذا كانت المنافع التطبيق / نموذج البيانات الخاصة بك مباشرة من هذا النهج، أي في الواقع هم أشياء منفصلة. في حالتك يبدو أن هناك أي سبب للذهاب إلى هذا الطريق.
لقد ذكر الجميع الأداء، ولكن أثار أحد السبب الرئيسي الآخر لماذا تخزين مؤشرات إلى ملفات نظام التشغيل هو فكرة سيئة: النسخ الاحتياطي والاسترداد. إذا كان كل شيء في قاعدة البيانات ثم لدينا آلية واحدة لعمل نسخ احتياطية من البيانات وآلية واحدة لتحقيق الانتعاش. بينما مع الملفات على نظام التشغيل لدينا اثنين من آليات احتياطية مختلفة، وربما على اثنين من الحبيبات مختلفة، والانتعاش يصبح كابوسا التزامن.
وهناك عدد قليل من الحالات التي يكون فيها هذا لا ينطبق، مثل مستودعات البيانات، والتي لها معاملات نادرة جدا وحتى يمكن البقاء على قيد الحياة دون إعادته أو معاملة السجلات.
وفيما عدا في حالات خاصة، وأود أن مغادرة الملعب حيث هو.
والخيار الآخر الوحيد سيكون لوضع السلاسل في جدول مختلف (وضع سلاسل الفعلية في هناك) ... وضعها في ملفات منفصلة سوف تقتل أدائك.
