نحوه طراحی جدولی با ردیف های فوق العاده زیاد

[jaza_sa]

سلام
فرض کنید یک قسمت از پروژه ،
ترجمه یک کتاب به زبان های مختلف باشه (فارسی ، انگلیسی ، عربی ، روسی و ...) ، تقریبا 12 ترجمه
در هر صفحه از این کتاب چند جمله نوشته شده و در کل حدود 5000 هزار جمله داره
حالا سوال :
من برای ذخیره همچین چیزی در دیتابیس ، باید چیکار کنم
1- آیا ستون های جدول ، باید به صورت زیر باشه :
کد ترجمه ، کد جمله ، زبان ، متن ترجمه
که در اینصورت ، تعداد ردیف های این جدول فوق العاده زیاد میشه (حدود 60,000 ردیف و 4 ستون)
2- یا اینکه باید حداکثر ستون ها را حساب کنم ، یعنی :
کد ترجمه ، کد جمله ، متن ترجمه 1 ، متن ترجمه 2 ، ... ، متن ترجمه 12
که کاربر محدود میشه (حداکثر 5000 ردیف و 14 ستون)
کدوم یکی از روش های بالا رو باید پیاده سازی کنم ؟؟؟
یا اینکه روش دیگری رو بهتره ؟؟؟

[oVERfLOW]

روش اول بهتره و روش دوم اصلا منطقی نیست
چون ممکنه تمام ترجمه‌ها نباشه و بی دلیل حجم بانک رو اشغال کردید

به علاوه حجم یه رکورد هم خیلی سنگین می‌شه و ممکنه موقع خوندش با مشکل مواجه بشید

[Microsoft.net]

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

[mehdi.mousavi]

سلام
فرض کنید یک قسمت از پروژه ،
ترجمه یک کتاب به زبان های مختلف باشه (فارسی ، انگلیسی ، عربی ، روسی و ...) ، تقریبا 12 ترجمه
در هر صفحه از این کتاب چند جمله نوشته شده و در کل حدود 5000 هزار جمله داره
حالا سوال :
من برای ذخیره همچین چیزی در دیتابیس ، باید چیکار کنم
1- آیا ستون های جدول ، باید به صورت زیر باشه :
کد ترجمه ، کد جمله ، زبان ، متن ترجمه
که در اینصورت ، تعداد ردیف های این جدول فوق العاده زیاد میشه (حدود 60,000 ردیف و 4 ستون)
2- یا اینکه باید حداکثر ستون ها را حساب کنم ، یعنی :
کد ترجمه ، کد جمله ، متن ترجمه 1 ، متن ترجمه 2 ، ... ، متن ترجمه 12
که کاربر محدود میشه (حداکثر 5000 ردیف و 14 ستون)
کدوم یکی از روش های بالا رو باید پیاده سازی کنم ؟؟؟
یا اینکه روش دیگری رو بهتره ؟؟؟


سلام.
من روش دوم رو توصیه میکنم، البته بعد از اعمال یه تغییر کوچک، به این ترتیب که جای نگه داشتن هر ترجمه در یک ستون، کلیه ترجمه ها رو بر اساس یه Xml Schema تو یه فیلد از نوع XML در بانک ذخیره میکنم. اینطوری اگه فردا یه زبان جدید اضافه بشه، Schema تغییر نمیکنه. ضمن اینکه با Support خوبی که در بانکهای اطلاعاتی امروزی وجود داره، براحتی میشه این ستون رو مدیریت کرد.

[jaza_sa]

حالا اگر به جای یک جدول با حداقل 60000 رکورد ، چند جدول با این تعداد رکورد وجود داشت
و فرض کنید به جای ترجمه یک جمله ، یک تحقیق مثلا 20 صفحه ای وجود داشت
بازم همچین کاری میکردید ؟

تمامی این احتمالات در پروژه من اتفاق افتاده ، و من دنبال بهترین و سریعترین راه حل هستم
و درضمن ، برای کاربران هم سرعت بسیار اهمیت داره و من از این بابت نگرانم

اگر امکان داره بیشتر توضیح بدید ، (شاید بایت یکمی خصوصیات و ویرایش های مختلف SQL Server رو بهتر بشناسم)
خیلی ممنون میشم

[jaza_sa]

سلام.
من روش دوم رو توصیه میکنم، البته بعد از اعمال یه تغییر کوچک، به این ترتیب که جای نگه داشتن هر ترجمه در یک ستون، کلیه ترجمه ها رو بر اساس یه Xml Schema تو یه فیلد از نوع XML در بانک ذخیره میکنم. اینطوری اگه فردا یه زبان جدید اضافه بشه، Schema تغییر نمیکنه. ضمن اینکه با Support خوبی که در بانکهای اطلاعاتی امروزی وجود داره، براحتی میشه این ستون رو مدیریت کرد.

سلام مهدی جان
میشه یکم بیشتر درباره نحوه استفاده از این روش توضیح بدید؟
من تا حالا با DataType های XML در SQL Server کار نکردم
درضمن ، نحوه کدنویسی در لایه ها هم نمیدونم (نحوه خواندن و نوشتن)

اگر امکان داره بیشتر توضیح بدید

[ASKaffash]

سلام
فرض کنید یک قسمت از پروژه ،
ترجمه یک کتاب به زبان های مختلف باشه (فارسی ، انگلیسی ، عربی ، روسی و ...) ، تقریبا 12 ترجمه
در هر صفحه از این کتاب چند جمله نوشته شده و در کل حدود 5000 هزار جمله داره
حالا سوال :
من برای ذخیره همچین چیزی در دیتابیس ، باید چیکار کنم

1- آیا ستون های جدول ، باید به صورت زیر باشه :
کد ترجمه ، کد جمله ، زبان ، متن ترجمه
که در اینصورت ، تعداد ردیف های این جدول فوق العاده زیاد میشه (حدود 60,000 ردیف و 4 ستون)
2- یا اینکه باید حداکثر ستون ها را حساب کنم ، یعنی :
کد ترجمه ، کد جمله ، متن ترجمه 1 ، متن ترجمه 2 ، ... ، متن ترجمه 12
که کاربر محدود میشه (حداکثر 5000 ردیف و 14 ستون)
کدوم یکی از روش های بالا رو باید پیاده سازی کنم ؟؟؟
یا اینکه روش دیگری رو بهتره ؟؟؟

سلام
1- شما به 60000 رکورد میگوئید زیاد ؟ اگر ایندکس های مناسب براساس PK و FK جداول ایجاد کنید مثل موشک عمل میکند در ضمن برای جستجو های زیاد ایندکس های مناسب را هم پیش بینی کنید .
2- روش دوم اصلا نه منطقی است نه علمی . درضمن در ستورات Select روش دوم سرعت مناسبی را برایتان ایجاد میکند یاددتان باشد تعداد رکورد اگر ایندکسهای مناسب پیاده سازی شده باشند خیلی اهمیت ندارد دلایل اصلی را دوستان گفتند.

[jaza_sa]

سلام
اگر ایندکس های مناسب براساس PK و FK جداول ایجاد کنید مثل موشک عمل میکند در ضمن برای جستجو های زیاد ایندکس های مناسب را هم پیش بینی کنید .


میشه بیشتر راجع به Index گزاری توضیح بدید؟
و اینکه چه نسخه ای از SQL Server برای اینکار مناسبتره؟ (Express , Standard)

[ASKaffash]

سلام
نسخه SQLServer خیلی مهم نیست ولی :
اگر ساختار جدول الی اصلی شما به این شکل باشد:
جدول زبانها :(T1)
*LID و LText
جدول کلمات کلیدی ترجمه :(T2)
TID* و *LID کلید و TText لغت کلیدی

ودرجدول اصلی :(T3)
ID* , TID , LID , ...... باشد :
ایندکس LID در T1 که کلید است
ایندکس TID , LID که در T2 کلید است

درجدول T3 اگر قرار باشد کلمات کلیدی در یک زبان خاص یا در هر زبانی را جستجو کنید این ایندکس متناسب با Where شما در Select سرعت را افزایش میدهد:
IDX=TID,LID دقت شود ترتیب مهم است

مثل :

Select * From T3 Where TID=1 and ....
Select * From T3 Where TID=1 and LID=3 and ...