ذخيره value به طور جداگانه؟

[bftarane]

سلام.
آيا جمله زير براي شما مفهومي داره؟
ذخيره نام فيلد در يک جدول و ذخيره value در جدول ديگر.
من با asp.net کار کردم و هميشه هم جدولهام خيلي ساده بوده يعني مثلاً
نام نام خانوادگي
زهرا محمدي
برداشت من از جمله بالا اينه که کلمه نام و نام خانوادگي در يک جدول ذخيره بشن
و در جدول ديگه کلمات زهرا و محمدي. آيا برداشتم به نظرتون درسته؟
آيا اين مسئله مربوط به MVC هست؟

[bftarane]

سلام. راستش من اون جمله بالا رو در حين صحبت دو نفر شنيدم و چون ديدم هيچي سر در نمي يارم نتونستم وارد بحث بشم و سوالي بپرسم.
منتها الآن که بيشتر فکر کردم يه چيزي به ذهنم رسيد که در پست 4 اين تاپيک نوشتم
http://barnamenevis.org/showthread.php?393465
حالا به نظرتون چه دليلي مي تونه داشته باشه که value بخواد جداگانه در يه جدول ديگه ثبت بشه و اسم property در يه جدول ديگه؟

[mo.esmp]

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

[hakim22]

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

میشه بجای اینکار با استفاده از چند حلقه و جستجو در میان collection های Columns و Rows در یک متغیر DataTable به راحتی هر نوع اطلاعاتی در مورد فیلدها بدست آورد.

[bftarane]

ممنون. فکر می کنم این طوری به ازای هر فیلد باید یه id منحصر به فرد هم در جدول ذخیره بشه که به وسیله اون یک ارتباط یک به یک هم بین اسم فیلد و value برقرار بشه درسته؟

[Saeed_m_Farid]

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

میشه بجای اینکار با استفاده از چند حلقه و جستجو در میان collection های Columns و Rows در یک متغیر DataTable به راحتی هر نوع اطلاعاتی در مورد فیلدها بدست آورد.
صحبت توجیه نیست، این یک نیاز هست که باید بصورتی بالاخره هندل بشه؛ اکثراً هم در سیستمهای مختلف برای من نوعی پیش اومده و نشده که صورت مساله رو پاک کنیم! پس باید نسبت به نیاز سیستم، بین راهکارهای مختلف سوئیچ میکردیم (تو شرکتهای متفاوت برای دوستانی که میخوان بخندن!!!).
*********************************
صورت مسئله رو من میگم، تا براش راه حل پیدا کنیم:
مسئله: فرض کنید سیستمی داریم که کارفرما میخواد فیلدهای سفارشی براش داشته باشه (که کم هم نیستند)، مثلاً برای موجودیت مشتری: ما که همه چی رو نمی تونیم پیش بینی کنیم، یه روز میخواد شماره کفش مشتری رو اضافه کنه، یه روز رنگ مو، قد، سن، وزن، نام پسرعموی ناتنی و ...
یا در برنامه های حسابداری، انبارداری و فروشگاه، آیتمهای مختلف و جدیدی که بعنوان نیاز ضروری برای موجودیت های فاکتور، سند، انبار، کالا و ... پیش میان (تخفیف دوره ای، درصد متفاوت مالیات، جنس و ابعاد قاب تلویزیون! و الخ).
راهکاری که پیشنهاد میدین چی هست؟

راه حل ها: چیزایی که به ذهن آدم خطور میکنه:

بیایم در جدول موجودیت (مثلاً مشتری) n تا فیلد خالی بذاریم، مثلاً field1, field2 , field3 , ... , fieldn و هرکدوم رو با توجه به نیاز به فیلد جدیدی (مثلاً فیلد درصد سلامتی) که درخواست مشتری هست اختصاص بدیم (خنده دار نیست! بعضی وقتا که فقط سرعت ملاک هست، شاید راهی جز این نداشته باشیم)
تنها یک فیلد برای چنین نیازهایی درست کنیم و اون رو به یک سیستم خارجی ذخیره سازی وصل کنیم، مثلاً بگیم اطلاعات اضافی در یک فایل XML با این آدرس ذخیره شده و فقط آدرس فایل رو بذاریم تو اون فیلد (که اینکار هم مسلماً دنگ و فنگ های خودش رو داره، سیستم با فایل سیستم درگیر میشه و نگهداری و پیاده سازی نسبتاً پیچیده ای داره، معمولاً درگیر با refractor و ...)
یه جدول CustomFieldValues برای مشتری ها درست کنیم، که شامل: Id مشتری، CustomFieldID و Value هست؛ CustomFieldID هم Id فیلد ما در یه جدول دیگه (بنام مثلاً CustomField) است که نام فیلد (مثلاً "شماره کفش مشتری") و نوع اون فیلد رو مشخص میکنه (مثلاً رشته، عدد، تاریخ و ...) که بعداً با نوع فیلد به مشکل نخورید. (این روش علیرغم زیبایی طراحی مشکل واکشی کند فیلدها و مقادیر و کوئری های پیچیده رو خواهد داشت و سرعت فدای طراحی صحیح میشه!)
همون حالت قبلی با این تفاوت که تمام حالات ممکن نوع فیلد رو در جدول CustomFieldValues لحاظ کنیم، مثلاً یه فیلد برای رشته، یکی عدد، یکی تاریخ و اعشاری و ... (یکم سریعتر ولی باز هم طراحی برمیگرده مثل بند اول!)
و در نهایت حالتی رو در نظر بگبرید که فقط برای یه موجودیت چنین قابلیتی نیاز نباشه، باید بتونیم Design pattern ای داشته باشیم که برای موجودیت های مختلف جوابگو باشه! تقریباً میشه یه فریمورک که Custom entity field رو باید باهاش پیاده سازی کرد؛ خوب فریمورک های آماده ای برای اینکار در زبانهای مختلف هست ولی اگه بخوایم خودمون پیاده اش کنیم، میشه با ترکیبی از دو بند قبل، چنین کاری کرد. مثلاً در جدول CustomField یه فیلد هم برای Entity ID داشته باشیم (مثلاً Id موجودیت مشتری -نه Id مشتری- یا Id موجودیت فاکتور، سند و فروشنده و ...) که بالطبع باید یه حدولی هم برای موجودیت ها درست کنیم و ...

*************
برای اینکه به MVC هم بیربط نباشه، بعنوان نمونه ای که در MVC چنین چیزی لازم میشه، فرمهایی هستند که شما به کاربر اجازه میدین خودش فیلدهایی بسازه و سپس با استفاده از اون فیلدها مقادیر رو ورد کنه؛ برای اینکار شما نیاز به مدلهایی برای اینکار خواهید داشت که Custom Field رو پیاده سازی کنن، یه حالتی مدلهای زیر :

public class CustomFormModel
{
public string FormId { get; set; }
public string Label { get; set; }
public CustomFieldModel[] Fields { get; set; }
}
public class CustomFieldModel
{
public DataType DateType { get; set; } // System.ComponentModel.DataAnnotations
public string FormKey { get; set; }
public string Label { get; set; }
public object Value { get; set; }
}
public class CustomFieldModel<T> : CustomFieldModel
{
public new T Value { get; set; }
}


برای طراحی صحیح هم برای اینکار از Composite pattern (http://en.wikipedia.org/wiki/Composite_pattern) استفاده میشه، مثلاً یک اینترفیس درست میکنن که موارد بالا رو پباده سازی کرده باشه و شما کلاسهای فرمهاتون رو از اون به ارث ببید : نمونه » اینجا (http://stackoverflow.com/questions/4412279/asp-net-mvc-posting-a-form-with-custom-fields-of-different-data-types)
______________
مطالعه بیشتر: The Entity Design Pattern (http://www.codeproject.com/Articles/4293/The-Entity-Design-Pattern)