گفتگوی فنی : تعریف و پیاده سازی فیلدهای Dynamic در دیتابیس

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

بخش اول :
1- تعریفی از فیلدهای Dynamic
2- موارد استفاده از فیلدهای Dynamic و آیا اینکه در همه طراحی ها ما به این تکنیک نیاز خواهیم داشت؟
3- تاثیری در پیچیدگی طراحی دیتابیس ما خواهد داشت؟

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

ظاهرا دوستان کسی نمیخواد در بحث شرکت کنه.
خوب من فعلا یک توضیحی در مورد فیلدهای Dynamic میدم امیدوارم مابقی دوستان در بحث شرکت کنند.

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

امیدوارم توضیح کامل بوده باشه. ازدوستان خواهش میکنم در بحث شرکت کنید.
باتشکر.

سلام،
بحث جالبی هست، آن طوری که من برداشت کردم اضافه کردن این فیلدهای پویا از سمت برنامه صورت می گیره، در نتیجه ربطی به پایگاه داده نداره؟!! و یا اینکه اول زمینه این کار را در سمت بانک اطلاعاتی فراهم می کنیم؟ و بعد در سمت برنامه این قابلیت را به کاربر می دهیم.
اولاً نوع داده این فیلدها چی هست و اینکه این قابلیت در چه ورژنی از SQL پوشش داده شده؟

خوب ممنون که بالاخره یکی وارد بحث شد.

نقل قول:

---

آن طوری که من برداشت کردم اضافه کردن این فیلدهای پویا از سمت برنامه صورت می گیره

---

درسته

نقل قول:

---

در نتیجه ربطی به پایگاه داده نداره؟!

---

کاملا برعکس چون ما داریم امکانی رو فراهم میکنیم که کاربر بتونه بدون نیاز به برنامه نویس یک فیلد به دیتابیس اضافه کنه و ازش استفاده کنه بدون هیچ دانشی ازبرنامه نویسی.!

نقل قول:

---

اولاً نوع داده این فیلدها چی هست

---

نوع داده هارو براساس اطلاعات ورودی میتونیم تنظیم کنیم یا از روشهای دیگه نوعش رو درست کنیم.

نقل قول:

---

اینکه این قابلیت در چه ورژنی از SQL پوشش داده شده؟

---

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

منتظر نظرات مابقی دوستان هم هستم.

با سلام.
آیا منظور شما از فیلد داینامیک مثلا استفاده از alter به صورت موردی هست؟
اول حدس من رو فیلد های Calculated بود اما وقتی دیدم قراره درش داده واقعی ریخته بشه منتفی شد.
فکر می کنم که اگر یک مورد خاص رو بفرمایید تا بحث هدایت بشه بهتر باشه.

نقل قول:

---

آیا منظور شما از فیلد داینامیک مثلا استفاده از alter به صورت موردی هست؟

---

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

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

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

تقریبا منظور منم یک همچین چیزیه. میشه بیشتر درمورد کاری که انجام میدید توضیح بدین؟

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

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

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

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

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

نقل قول:

---

راهی که به نظر من می رسه، این هست که یک SP بنویسیم که نام جدول و نام فیلد را بگیره و با فراخوانی این SP که دستور Alter Table را اجرا می کنه روی آن جدول بخصوص تغییرات اعمال بشه.

---

این راه مناسب نیست به خاطر اینکه دائم جداول ما دستخوش تغییرات میشن .اینجوری مجبوریم کدهایی هم که نوشتیم رو عوض کنیم. یا ممکنه حتی داخل برنامه مون هم دچار تغییر بشه.

نقل قول:

---

آیا این روش شما قابلیت توسعه به ساپورت کردن این موارد را هم داره یا نه؟ فقط در حد فیلد هست؟؟

---

در این روش با استفاده از تکنیکهای مورد نظر ، وابستگی شما از حذف و اضافه و نگهداری دیتابیس حذف خواهد شد.

باید عرض کنم که به سادگی می شه جدول هم طراحی کرد اما در خصوص تغییر دادن اشیای ثابت (دستورات DDL) این اتفاق بعیده (ذاتا نمی خواهیم این کار رو انجام بدیم)
جناب صادقیان فکر می کنم که برای کارهای معمولی و فیلدهایی که معمولا اکثر شرکت ها نیاز دارند انجام این روش مقرون به صرفه نباشه. چه از نظر کد نویسی (UI & SQL) و چه از نظر مشتری که از سیستم داره استفاده می کنه.
مثلا اگر برای کد ملی چنین کاری کنیم ، مشتری زمینه ذهنی بدی پیدا می کنه و ممکنه این فکر رو کنه که سیستم برای ذخیره اطلاعاتی به این پرکاربردی فیلد نداره ، پس ضعف داره و تازه داره پا می گیره.
اما اگر فیلدی بخواد که خودش هم می دونه معمولا سیستم ها اون رو ندارند ، وقتی بفهمه سیستم قابلیت تعریف کاری که می خواد رو داره، به شدت طرفدار و مبلغ سیستم می شه.
در کد نویسی هم معمولا کدهایی که برای مکش دیتا از این ساختار استفاده می شه زمان بیشتری می بره و طولانی تر هست. امکان برخی کارها رو هم مثل رابطه نداره و خودمون باید دستی این کار رو انجام بدیم.
اما گاهی هم ممکنه که فیلدی که می خواد به حدی پر بازدید هست که عملا ممکنه برای حجم وسیعی از داده که در گزارشات هم شرکت می کنند ، انجام این کار باعث کندی غیر قابل قبول از نظر مدیران شرکت میزبان بشه. (مثلا فیلدی مثل کاربر ثبت کننده کالا در ریز سند فروش یا همون اقلام فاکتور در حالتی که شرکت مورد نظر هر روز 500 فاکتور در هر شعبه ثبت می کنه - مثل شرکتهای پخش)
برای این کار هم افزودن فیلد استاتیک به نظرم منطقی تر هست.

نظر شما در این باره چیه؟

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

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

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

ما یک جدول کالا داریم که مشخصات زیر رو نگهداری میکنه:

کد کالا- نام کالا- گروه کالا- مارک - شماره فنی

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

منتظر نظر دوستان هستم.

لطفا اگر جداول رو پیاده سازی میکنید با شرح کامل باشه.نحوه ارتباطات رو توضیح بدین. یک نمونه از کدهای Insert,Select,Update,Delete رو نیز براش بنویسید.
باتشکر

به نظر من تغییر تیبل کار اشتباهیه . پس باید از ترفندی استفاده کرد که بدون تغییر تیبل ها کاربر امکان اضافه کردن فیلدها رو داشته باشه !!!
اگر یه تیبل به حالت زیر داشته باشیم فکر کنم این کار محقق میشه :

fldname     fldtype    fldval

name     string   ahmad

name    string          ali 

lname     string  alizade

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

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

نقل قول:

---

نوشته شده توسط mehrzad007

به نظر من تغییر تیبل کار اشتباهیه . پس باید از ترفندی استفاده کرد که بدون تغییر تیبل ها کاربر امکان اضافه کردن فیلدها رو داشته باشه !!!
اگر یه تیبل به حالت زیر داشته باشیم فکر کنم این کار محقق میشه :

fldname     fldtype    fldval

name     string   ahmad

name    string          ali 

lname     string  alizade

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

---

ممنون.
الان از کجا بفهمیم این فیلدها به کدوم جدول ما ارتباط داره

نقل قول:

---

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

---

خوب با این روش کاربر از کجا بدونه این فیلد مربوط به کدوم فرمه؟ کجا ازش استفاده میشه؟

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

خوب چه جوری بدونیم این فیلد مربوط به چه جدولی هستش؟؟

نقل قول:

---

نوشته شده توسط achaemenianboy

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

---

سلام

به نظر من ... چون می خوایم جدول داینامیک داشته باشیم باید Query ها رو هم برای Select,insert,update,delete داینامیک بنویسیم ... پس من اول یه جدول درست می کنم به اسم FieldNames که دارای مقادیر زیر هست ...

FieldID,FieldName,FieldType,FieldSize,TableID,Tabl eName,IsActive,... و البته خیلی اطلاعات دیگه هم می شه داخلش قرار داد بسته به اینکه شما چقدر بخواهید اینکار رو جلو ببرید ... (فیلد مربوط به TableID رو فعلا در نظر نگیرید بعدا بیشتر توضیح میدم ... )
بر می گردیم سر جدول ÷رسنلی من اطلاعات فیلدهایی رو که ساختم مثل نام و نام خانوادگی رو درون این جدول می ریزم مثلا اگه جدول ÷رسنل من Personel باشه من فیلد مربوط به نام شخص رو اینجوری در این جدول وارد می کنم
name nvarchar 50 1 Personel 1
Famili nvarchar 50 1 Personel 1
PersonelID int 4 1 Personel 1

و به همین ترتیب ... اگه کاربر هم فیلدی رو خواست به این جدول اضافه کنه رکوردش رو اینجا ثبت می کنم و جدول اصلی خودم رو Alter می کنم ... اگر هم خواست حذف کنه من جدول رو Alter نمی کنم فقط اینجا IsActive رو صفر یا False می کنم

بعد من باید دستورات داینامیکم رو بسازم ... مثلا هروقت بخوام یه Insert انجام بدم لیست اسم فیلدها مورد نظر رو از این جدول می خونم بعد دستورم رو با این مقادیر و مقادیری که کاربر فرستاده درون دستور قرار میدم و EXEC می کنمش ...

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

شايد بي ارتباط نباشه
در نرم افزار دبيرخانه چاپارس كاربر قابليت تعريف پوشه و فيلدهاي اون را داره مثلا پوشه بايگاني پرسنل و ...
اومده فيلدها رو دسته بندي كرده نوع بوليين نوع عددي نوع تاريخ و نوع رشته بعد در حداكثر تعدادي كه كاربر مي تونه ايجاد كنه محدوديت گذاشته مثلا 5 تا از نوع عددي و بقيه هم يه تعداد

يه جدول هم تعريف كرده براساس حداكثر تعداد اون نوع ها و بقيه ماجرا ...

دانلود دموي اون مي تونه بهتون بيشتر كمك كنه!

اينم لينك

www.chapars.com

جناب صادقیان لطفا ادامه بدید

یک سوال! آیا کسانی هم که در این مورد اطلاعات دارند هم میتونن تو این بحث شرکت کنن؟

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

برای دوستانی که تا اینجا نظراتشون رو دادند عرض میکنم.

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

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

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

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

جناب صادقيان
بحث بسيار جالبي را مطرح نموده ايد ولي در دنبال كردن آن، جسارتآ بايد عرض كنم كه بسيار ضعيف عمل كرده ايد. چرا كه اين تاپيك در مهر ماه استارت خورده و امروز كه 20 ارديبهشت هست هنوز هيچ نتيجه اي از آن بدست نيامده بجز چندين سئوال بي پاسخ كه در ذهن خوانندگان تاپيك بوجود آمده. چه خوب بود اگر اين موضوع را با آمادگي بيشتر مطرح مي كرديد و اگر از مطالعات قبلي در اين خصوص برخورداريد ابتدا آنرا بصورت مقاله اي ارئه مي كرديد و بعد با كمك كاربران ديگر به يك راه حل اپتيمم براي پياده سازي آن دست مي يافتيد. با آنكه چندين كاربر ابراز علاقه كردن براي ادامه موضوع ولي هنوز متاسفانه هيچ پيگيري براي ادامه بحث از جانب شما انچام نشده است. اين تاپيك 1895 بازديد كننده داشته است . فكر نمي كنيد با چنين آماري بايد با مسئوليت بيشتري به اين موضوع نگاه كنيد.

نقل قول:

---

نوشته شده توسط Fahime_FM

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

---

من با نظر شما كاملآ موافق هستم . اصولآ چنين قابليت هايي بايد در اختيار برنامه نويسان يا در اصل همان اينتگريتورهاي سيستم باشد تا بتوانند براي اساس يك سيستم بيس و تعاريف اوليه سيستم هاي جديدي را در زمان كم طراحي و پياده سازي نمايند. به گمانم سيستم هاي مبتني بر business process modeling بر اساس همين قابليت و البته امكانات ديگر، زمينه توليد سريع سيستم هاي اطلاعاتي را فراهم مي كنند.

آقای صادقیان سلام
کاش بحث رو ادامه میدادید
واقعا عالیه
من خیلی به این نیاز دارم
ممنون

من همین مشکل را دارم و همه تاپیکها را خواندم در صورتی که نوع فیلدها متن ، عدد ، تاریخ باشه به راحتی همین روش جواب می دهد به جای فیلد متن و عدد یک textBox به جای فیلد که از نوع 0 یا یک است یک ChekBox
اما اگر فیلد از نوع انتخاب چند متن از پیش تعیین شده باشد که باید تبدیل به DropDownList شود چکار باید کرد؟؟؟؟؟؟؟؟؟؟؟
مثلا شما یک فیلد به اسم برند اضافه کنید و این فیلد خودش موقعی که روی فرم نشان داده می شود به صورت یک DropDownList باشد و مقادیر 1- سونی 2- ال جی 3- سامسونگ و ... را داشته باشه و کاربر نخواهد تایپ کند و فقط انتخاب نمایید را چگونه پیاده کنیم؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟؟ ؟؟؟؟؟؟

سلام.
بحث خیلی جالبیه.
من شخصاً تا الان یک روش رو بیشتر استفاده نکردم.ولی یک روش دیگه هم دارم که چند ماهه draft هست و هنوز کامل عملی نشده.
روشی که الان استفاده میکنم:
همه ی جداول ه database دارای ستون ه Guid هستن.
دو تا جدول دارم با این ساختار:

Attribute:

Guid UniqueIdentifier//even this table

name nvarchar



RowAttribute:

Guid uniqueIdentifier

AttributeGuid uniqueIdentifier

RowGuid uniqueIdentifier

value varbinary(4000)

چون از ساختار ه map در ORM ام استفاده میکنم در جدول دوم هیچ reference ای به table ندارم.(نیازی ندارم)

@صادقیان:به نظر شما ۴۰۰۰ بایت مشکلی ایجاد نمیکنه؟
چطوره؟
البته چون یه implementation ه واقعیه یه سری مشکلات داره.مثلاً محدودیت Attribute/Table نداره.چون موقع پیاده سازی اصلاً بهش دقت نکردم.
اون ستون ه varbinary هم تقریباً اینطوری de/serialize میشه:

....

        else if (PType == typeof(System.SByte?)) { bool b = pn != null; sw.Write(b); if (b) sw.Write((SByte)pn); }             else if (PType == typeof(System.Boolean?)) { bool b = pn != null; sw.Write(b); if (b) sw.Write((Boolean)pn); }             else if (PType == typeof(System.Char?)) { bool b = pn != null; sw.Write(b); if (b) sw.Write((Char)pn); }             else if (PType == typeof(System.DateTime?)) { bool b = pn != null; sw.Write(b); if (b)sw.Write(((DateTime)pn).ToBinary()); }             else if (PType.IsArray)             {                 Array A = (Array)pn;                 int R = A.Rank;                 int B;                 sw.Write(R);                 int[] indices = new int[R];                 int[] bounds = new int[R];                 int L = 1;                 for (int n = 0; n != R; n++)                 {                     B = A.GetLength(n);                     sw.Write(B);                     bounds[n] = B;                     L *= B;                 }                 for (int n = 0; n != L; n++)                 {                     object P = A.GetValue(indices);                     if (P == null)                     {                         sw.Write((byte)0);                     }                     else....

روش دوم هم در دیتابیس توزیع شده خودم هست که کلاً ساختارش متفاوته(تا یه جایی دیتابیس با ساختار ه traditional ه همه ی دیتابیس های دیگست ولی اطلاعات ه sync نشده به شکل increamental ذخیره میشن).توی اون سیستم خود کاربر میتونه در دیتابیس دست ببره بدون اینکه بتونه خرابکاری بکنه.واقعاً طراحیش سخت بود.ولی الان که بعد از حدود یک سال مرورش میکنم میبینم ارزشش رو داشته.
اگر کسی به دیتابیس توزیع شده علاقه داره بگه توضیح بدم.

سلام دوستان
من پست های قبلی رو خوندم و تاپیک تاپیک خیلی جالبیه و از آقای صادقیان هم بابت این تاپیک و سایر تاپیک های مهمشون تشکر میکنم و خواهش میکنم هر از چند گاهی تاپیک هایی مشابه این تاپیک یا درباره نقد سیستم خاصی بزارن که هم نظرات بقیه رو ببینیم و هم از تجربیات خودتون و هم تجربیات کسایی که تو اون زمینه کار کردن استفاده کنیم.
من برای پیاده سازی فیلدهای داینامیک یک ER کشیدم که مبحثی رو که در بالا بهش اشاره شده رو ساپورت میکنه . از دوستانی که درباره این تاپیک و این پست نظر میدن پیشاپیش تشکر میکنم
https://docs.google.com/open?id=0B8H...VBCaVg2Y09nZmc

من فیلدهای داینامیک را در پروژه ام اعمال کردم
جدول اول شامل اسم همه جداول در SQL است که می خواهم دارای ستون داینامیک باشد
جدول دوم شامل تعریف ستونها (اسم انگلیسی ستون،اسم فارسی ستون ،نوع ستون ،نوع کنترل ستون ،سایز ستون و اسم جدول ستون)
جدول سوم شامل مقادیر پیش فرض برای کنترل DrowpDownList یا ListBox
جدول آخر هم مقدار ستونها شامل (اسم ستون ،اسم جدول،مقدار ستون)

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

سلام،
اگه سوالی هم داشتید در مورد dynamic بودن سیستم های پیاده سازی شده توسط دیتابیس ما هستیم .
ولی بپرسید جواب بدم چون این همه موضوع رو وقت(حوصله) ندارم بخونم.

فرض کنید بخوایم یه سری محصول رو توی یه جدول بزاریم
این محصولات اگه فقط برای یه سری لوازم الکترونیکی باشه می تونیم ویژگی های خاصی براش در نظر بگیریم!
فرض کنید این فروشگاه پیشرفت کرد و خواست شروع به فروش ماشین کنه!!!!
به نظرتون فیلدهای قبلی می تونن کافی باشن؟؟؟
قطعا جواب منفیه
ولی اگه از همون اول نام ویژگی ها رو در یه جدول جدا و مقادیر اونها رو در یه جدول جدا در نظر بگیریم این امکان وجود داره که یه جدول پویا داشته باشیم

سلام
هر چند تاپيك قديميه ولي راهي هم به نظر من ميرسه

يك جدول جديد ايجاد كنيم با فيلدهاي dynamic كه مشتري مي‌خواد و يك Id

بعد اين جدول و جدول اصلي رو به صورت يك به يك به هم ارتباط بديم، و يك كوئري از اين دو جدول بسازيم و با اون كار كنيم

در طراحي فرمهاي برناممون هم فيلدهاي جدول اصلي رو كه قرار داديم و فيلدهاي جدول دوم رو هم به صورت dynamic مي‌سازيم، مي‌تونيم تو فرمهامون از كنترل Tab براي جداسازي فيلدهاي اصلي و دايناميك استفاده كنيم يا هر طور ديگه كه خودمون مي‌دونيم

اينطوري جدول اصلي ما هيچوقت تغييري نمي‌كنه و با ايجاد فيلدهاي دايناميك هم تغيير خاصي تو عملكرد جستجوي برنامه نياز نيست بديم چون مي‌تونيم از اول برنامه رو طوري تنظيم كنيم كه كل فيلدهاي جدول (همون Query بالا) رو بخونه و بر اساس اونها جستجو انجام بده و همينطور در مورد نمايش اطلاعات به صورت جدولي و گزارشات هم كه مشكل خاصي وجود نداره چون Query اشاره شده خودش فيلدهاي اضافه شده رو برمي‌گردونه، در حقيقت با اينكار نياز نيست برنامه نويسي زيادي براي كنترل فيلدهاي اضافه شده انجام بشه

خوبي ديگه اين روش اينه كه اگر ركوردهايي در جدول اصلي بودن كه به فيلدهاي جدول دوم نياز نداشتن، فقط فضايي معادل ركوردهاي جدول اصلي رو مصرف مي‌كنن و حجم ديتابيس پايين مياد، مثلا فرض كنيد شخصي مي‌خواد مشخصات يكسري كالاهاي فروشگاه موبايل رو ثبت كنه اما در مورد خود گوشي فيلد شماره سريال هم نياز داره و فقط براي ركوردهايي كه گوشي موبايل هستن فيلد شماره سريال رو در جدول دوم ثبت مي‌كنه
البته با اينكار ديگه ركوردهايي كه در جدول دوم فيلدي ندارن در Query ما ظاهر نميشن كه ميشه يك فيلد براي شناسايي اين موضوع تو جدول اصلي گذاشت و اگر مثلا مقدار اون فيلد True بود يعني اين ركورد اطلاعات اضافي داره، گذاشتن اين فيلد هم براي اينه كه جستجوي اضافي روي جدول دوم انجام نديم

اگر هم برامون صرفه جويي در حجم خيلي مهم نيست مي‌تونيم به ازاي هر ركورد در جدول اصلي حتما ركورد معادل در جدول دوم رو هم ايجاد كنيم حتي اگر در فيلدهاش چيزي ننويسيم

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

راه ساده اش اینه که 5 تا فیلد عدد و 5 تا فیلد رشته و ... هم در برخی از جداول داشته باشیم
و برای کاربر فقط فعال سازی و تغییر کپشن اون فیلد ها رو در اختیار بزاریم

من که متوجه نشدم چی گفتید:اشتباه:

من اخیرا یک روش دیگه استفاده کردم که فوق العاده جواب داده.
در فیلدهایی که نمیدونیم چی قراره ذخیره بشه یک Guid که نشان دهنده یک dll هست ذخیره میکنم. و اون dll در زمان اجرا محتوای فیلد و نمایشش به کاربر رو مدیریت میکنه.
برای وضعیت های خاص کاربران میتونن درخواست بدن که امکانات مورد نیازشون اضافه بشه. یا از dll ای که این کار رو به شکل dynamic انجام میده استفاده کنند.
خاصیت این روش اینه که میتونم از محتوای فیلدها query بگیرم و برای query یک UI زیبا به کاربر ارائه بدم که حس form های autogenerate شده رو نداره.

میشه بیشتر توضیح بدید ؟

دوستان عزیز من یه پروژه تقریبا داینامیک در رابطه با همین موضوع نوشتم
اگه مایل به بحث در این تاپیک هستید تا آپلودش کنم

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

نقل قول:

---

نوشته شده توسط FastCode

من اخیرا یک روش دیگه استفاده کردم که فوق العاده جواب داده.
در فیلدهایی که نمیدونیم چی قراره ذخیره بشه یک Guid که نشان دهنده یک dll هست ذخیره میکنم. و اون dll در زمان اجرا محتوای فیلد و نمایشش به کاربر رو مدیریت میکنه.
برای وضعیت های خاص کاربران میتونن درخواست بدن که امکانات مورد نیازشون اضافه بشه. یا از dll ای که این کار رو به شکل dynamic انجام میده استفاده کنند.
خاصیت این روش اینه که میتونم از محتوای فیلدها query بگیرم و برای query یک UI زیبا به کاربر ارائه بدم که حس form های autogenerate شده رو نداره.

---

خب در اینصورت مجبور میشین برای هر کاربر یک dll جداگانه درست کنید چون هر کاربری ممکنه فیلدهای دلخواه خودش رو بخواد اضافه کنه و اگر فرض کنیم فقط 100 کاربر داشته باشید باید 100 تا dll بسازید و آپدیت و رفع اشکال و ارتقاء و ... هم میشه مثنوی هفتاد من کاغذ...

نقل قول:

---

نوشته شده توسط vbhamed

خب در اینصورت مجبور میشین برای هر کاربر یک dll جداگانه درست کنید چون هر کاربری ممکنه فیلدهای دلخواه خودش رو بخواد اضافه کنه و اگر فرض کنیم فقط 100 کاربر داشته باشید باید 100 تا dll بسازید و آپدیت و رفع اشکال و ارتقاء و ... هم میشه مثنوی هفتاد من کاغذ...

---

بله.فرمایشتون کاملا درسته.
نکته مثبت این روش که شما ندیدین این هست که توی خیلی از برنامه های کاربردی نیازهای خاص کاربران خاص تا حد زیادی یکسان هستند که برنامه های من هم در این مورد استثنا نیستن.
مثلا بنده با چند تا شرکت توزیع شیر کار میکنم.همشون درصد چربی نیاز دارند.
پخشهای دارویی همه نیاز به فبلد boolean برای شبانه روزی بودن داروخانه ها دارند.
پخش مواد غذایی معمولا طعم و اسانس و ...
همه این ها ممکنه برای قوانین عجیب مالیاتی یا بیمه ای ای که هنوز تصویب نشدن (فرض) نیاز به فرمول خاصی داشته باشند که من پیشبینی نکردم.

از نظر من ارزش داشته حجم زیادی کد برای این موضوع بنویسم.و تا الان مدیزیتش مشکلی ایجاد نکرده

نقل قول:

---

نوشته شده توسط FastCode

من اخیرا یک روش دیگه استفاده کردم که فوق العاده جواب داده.
در فیلدهایی که نمیدونیم چی قراره ذخیره بشه یک Guid که نشان دهنده یک dll هست ذخیره میکنم. و اون dll در زمان اجرا محتوای فیلد و نمایشش به کاربر رو مدیریت میکنه.
برای وضعیت های خاص کاربران میتونن درخواست بدن که امکانات مورد نیازشون اضافه بشه. یا از dll ای که این کار رو به شکل dynamic انجام میده استفاده کنند.
خاصیت این روش اینه که میتونم از محتوای فیلدها query بگیرم و برای query یک UI زیبا به کاربر ارائه بدم که حس form های autogenerate شده رو نداره.

---

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

نقل قول:

---

نوشته شده توسط FastCode

بله.فرمایشتون کاملا درسته.
نکته مثبت این روش که شما ندیدین این هست که توی خیلی از برنامه های کاربردی نیازهای خاص کاربران خاص تا حد زیادی یکسان هستند که برنامه های من هم در این مورد استثنا نیستن.
مثلا بنده با چند تا شرکت توزیع شیر کار میکنم.همشون درصد چربی نیاز دارند.
پخشهای دارویی همه نیاز به فبلد boolean برای شبانه روزی بودن داروخانه ها دارند.
پخش مواد غذایی معمولا طعم و اسانس و ...
همه این ها ممکنه برای قوانین عجیب مالیاتی یا بیمه ای ای که هنوز تصویب نشدن (فرض) نیاز به فرمول خاصی داشته باشند که من پیشبینی نکردم.

از نظر من ارزش داشته حجم زیادی کد برای این موضوع بنویسم.و تا الان مدیزیتش مشکلی ایجاد نکرده

---

برای روش مالیات من از زبان اسکریپت استفاده می کنم که باعث میشه نیاز به لود کردن dll خاصی نمونه. نمی دونم تا چه حد امکان اینکار توی سی شارپ باشه اما میشه از زبانهای اسکریپت معروف مثل Lua و یا Python استفاده کرد.

نقل قول:

---

اگر کسی به دیتابیس توزیع شده علاقه داره بگه توضیح بدم.

---

آقا اگر توضیح بدی خیلی خوب میشه. من برای توزیع شدگی از یه متدی شبیه RPC استفاده می کنم. و برای رکوردهای جدولهام یک فیلد زمان آخرین ویرایش و ... دادم. یه چیزی که شبیه SVN. البته خب همنطور که احتمالا می دونی زمان دقیق توی سیستم های توزیع شده سخت هست و البته سختر از اون sync کردن. اگر برای sync کردن راه حل مناسبتری از RPC باشه. خیلی خوب میشه اون رو به اشتراک بگذارید.


کاری که من متوجه شدم باید ازش جلوگیری کنم برای داینامیک بودن استفاده نکردن از SP هست. برای اینکار خودم کوئری ها رو می سازم. و همون روش هوک که گفتم باعث میشه پلاگین ها بتونن روی کوئری ها دستکاری کنن و بتونن فیلدهای خودشون رو اضافه و یا کم کنن.

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

روش دیگه استفاده از مواردی مثل json برای پارامترهای اضافی هست. که میشه یه فیلد از نوع text برای هر جدول براش در نظر گرفت. ( من از MySQL استفاده می کنم که خودش نوع فیلد JSON رو پشتیبانی می کنه و همینطور عملیات مربوط به اون رو که کار رو خیلی راحت کرده نمی دونم دیتابیسهای دیگه ساپورت می کنن یا نه اما فکر کنم داخل SQLServer هم باشه. حداقل خروجی از نوع JSON رو دیدم توش)

بحث جالبی هست، آن طوری که من برداشت کردم اضافه کردن این فیلدهای پویا از سمت برنامه صورت می گیره، در نتیجه ربطی به پایگاه داده نداره؟!! و یا اینکه اول زمینه این کار را در سمت بانک اطلاعاتی فراهم می کنیم؟ و بعد در سمت برنامه این قابلیت را به کاربر می دهیم.
اولاً نوع داده این فیلدها چی هست و اینکه این قابلیت در چه ورژنی از SQL پوشش داده شده؟

آموزش خوشنویسی
آموزش ماساژ
آموزش عكاسي
پرورش مرغ
آموزش مكانيك خودرو