ذخیره فیلدهای فرم به صورت رکورد یا درجدول جدا

[masoodinfo]

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

راه اول طراحی جداول به صورت eav هست که دراین روش با 3 4 تا جدول میشه فرم ها ،فیلد ها و مقادیر رو مدیریت کرد.
راه دوم کار با دستورات sql جهت ساخت و ویرایش جداول و ارتباطات و ازاین قبیل دستورات می باشد.

راه دوم رو بنده سختم هست چون باید این دستورات رو تولید کرد.روش اول هم اینطور که من خوندم انگار پیشنهاد نمی کنند.چون انگار در واکشی به سرور فشار میاد و با تاخیر روبه رو میشیم.


راهنمایی بفرمایید چیکار کنم؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟ ؟؟؟؟؟؟؟؟؟؟؟؟؟

[مهدی نان شکری]

با سلام

من قبلا در این مورد توضیح داده ام و دوباره مختصر توضیحی می دهم.
شما چندین روش برای این کار دارید که عبارتند از sparse table، EAV، XML، Json که البته هر کدام مزایا و معایب خودش رو دارا میباشد. (Json در MSSQL2016 اضافه شده است)
فقط نکته ی مهمی که متاسفانه در اکثر موارد نادیده گرفته میشود این است که سعی نکنید هسته اصلی سیستم شما توسط مکانیزم های دینامیک طراحی شود چرا که نگهداری آن و جستجو در آن ممکن است با مشکلاتی همراه باشد.

اگر شما فقط قصد نگهداری اطلاعات رو برای نمایش دارید و نمی خواهیدبعد ها در قسمت Where کوئری از آن استفاده کنید گزینه های XML و Json گزینه های بهتری هستند (البته برای Json کمی بحث وجود دارد که در صورت نیاز اشاره خواهم کرد)
ولی در صورت استفاده از مقادیر فیلدهای دینامیک در شرط ها بهتر است از همان EAV استفاده کنید و اگر خواستید از XML استفاده نمایید بهتر است برای افزایش سرعت کوئری ها از Typed Xml استفاده کنید در غیر این صورت با مشکل برخورد میکنید.

البته برای این کار می توانید از NoSQL بهره ببرید مانند MongoDB که برای این کار طراحی شده اند.


موفق باشید

[masoodinfo]

سلام ممنون از پاسخ شما!
محدودیت های من برابر هست با sql server 2012 , asp.net mvc !
باید بگم که بله شرط هم وجود دارد و باید کاربران بتونن براساس فیلد ها جستوجو هم بکنن!
فقط این مدل eva از لحاظ کارایی خوب هست؟سرعت و.... !
با تشکر

[مهدی نان شکری]

نخیر نگران Performance نباشید به شرطی که طراحی خود را درست انجام داده باشید.
منظورم از طراحی فقط طراحی دیتابیس نیست UI هم جزو آن می باشد. ایندکس های مناسب هم کمکتان می کند. البته باز هم باید Business رو بررسی کنید! و در نهایت بعد از 1 سال ، 2 سال و 5 سال چه تعداد رکورد در این جدول خواهید داشت؟ پاسخ همه این سوالات برای طراحی کمک می کند.
موفق باشید

[masoodinfo]

البته باز هم باید Business رو بررسی کنید!


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

از لحاظ دیتا که سوال فرمودید!
درسطح یک اداره با 60 70 پرسنل و ....
نمی دونم دیگه تعداد رکورد هارو.

طراحی:
135485

[مهدی نان شکری]

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

[masoodinfo]

سلام و عرض ادب دارم خدمت برادر خودم


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

راهنمایی بفرمایید چیکار کنم؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟ ؟؟؟؟؟؟؟؟؟؟؟؟؟

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

یک اتوماسیون اداری ! توی هر اداره ای هم ببری قابل اجراس.(فرم ها درخواست هاشون )

حالا بفرمایید قلب این سیستم که فکرکنم همین بخش فرم ها و ذخیره و نمایش هست چگونه باید طراحی بشه؟


باتشکر

[مهدی نان شکری]

با سلام

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

در ابتدا می بایست به این موضوع پرداخته شود که پایگاه داده رابطه ای به هیچ عنوان برای نگهداری داده های مدل EAV مناسب نمی باشد چرا که با چنین طراحی بسیاری از قابلیت ها و مزایای این نوع پایگاه داده ها را از دست می دهیم. به عنوان نمونه قابلیت Referential Integrity که مهمترین قابلیت پایگاه داده رابطه ای می باشد با چنین طراحی دچار مشکل خواهد شد. همچنین نوع داده ها تماما از یک جنس خواهند بود و پایگاه داده نمی تواند بر روی نوع داده محدودیتی اعمال نماید.

مشکل بعدی که همواره با آن بر خورد خواهید کرد Query واکشی داده ها می باشد به طوری که به دلیل نوع نگهداری داده ها که از توع vertical می باشد کوئری ساده واکشی داده ها به Query های پیچیده ای تبدیل خواهد شد. به عنوان مثال فرض کنید در سیستم انبار داری به دنبال کالاهایی هستید که نوع آن هارد دیسک بوده و ظرفیت آن 1 ترابایت و همچنین ضدضربه باشد همان طور که می دانید نوشتن این کوئری برای مدل EAV بسیار سخت می باشد.

مشکل دیگر این نوع مدل طراحی نگهداری داده ها می باشد به طوری که به دلیل نامشخص بودن موجودیت های سیستم و همچنین به دلیل عدم بهره گیری از خاصیت Referential Integrity که در بالا به آن اشاره کردم ممکن است داده های موجود توسط تیم پشتیبانی خراب شود و سیستم از حالت پایدار خارج گردد.

البته می بایست توضیحات را با این جمله تکمیل کنم که این نوع طراحی مزایایی هم دارد و برای برخی از شرایط کاملا مناسب می باشد. به عنوان مثال سیستمی را فرض کنید که موجودیتی دینامیک دارد به طوری که خصوصیات آن در حال تغییر میباشد. برای چنین سیستمی طراحی EAV مناسب است.

دوست عزیز، معمولا در نرم افزار هایی که شامل فرم ساز می باشند و ورود اطلاعات در آن ها صورت می گیرد سعی می کنند واسط کاربری و فرآیند ها را طوری طراحی نمایند که وابسته به خصوصیات موجودیت ها نباشد و یا کمترین وابستگی را داشته باشد. در این نوع سیستم ها، معمولا نوع موجودیت ها ملاک سیستم است نه خصوصیات آن ها. برای مثال می توانید به سیستم های BPMN موجود در بازار ایران نگاهی داشته باشید.

پس قبل از هر چیزی برای تصمیم گیری در نوع طراحی، ابتدا کلیات سیستم را تهیه نمایید و تک تک نیازمندی های آن را تهیه کنید و سپس می توانید انتخاب درستی برای معماری آن داشته باشید.

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

موفق باشید و بابت تاخیر پوزش می خواهم.

[masoodinfo]

سلام و عرض خدا قوت خدمت دوست عزیز

از مطلبتون استفاده کردم.
ممنون از پاسختون.