بهینه سازی دیتابیس طراحی شده
سلام
دوستان میشه در مورد درستی این طراحی راهنمایی کنید؟ مثلا جدول کاربر و یوزر فیلدهای مشترک دارن... جدول سمت شخص(persontype) هم فقط یه سری مقادیر ثابت داخلش هست...
شرکت company
شناسه ملی
تاریخ تأسيس
تاريخ ثبت
نام
نوع شرکت (ثابت) : بامسئوليت محدود – سهامی خاص – سهامی عام – شرکت تعاونی – شرکت تضامنی
شماره ثبت
اداره کل استان
واحد ثبتی
کد پستی
آدرس
کف تعداد هیات مدیره
سقف تعداد هیات مدیره
سرمایه شرکت – ریال
تعداد سهام
ارزش هر سهم
نوع سهام (ثابت): بی نام عادی – با نام عادی
شخص person
کدملی
نام
نام خانوادگی
شماره شناشنامه
تاریخ تولد
موبایل
ایمیل
استان محل صدور
شهرستان محل صدور
نام پدر
شخص شرکت personCompany (جدول واسط )
شناسه شخص
شناسه شرکت
سمت – چند انتخابی است شامل یک یا چند مورد از: رییس هیات مدیره – نایب رییس هیات مدیره – عضو هیات مدیره – مدیر عامل – سهامدار – بازرس اصلی – بازرس علی البدل
میزان سهام
تاریخ انتصاب
تاریخ اتمام عضویت
حق امضا دارد؟ - 0 یا 1
سمت persontype (ثابت)
ID
عنوان
سمت شرکت PersonTypeInCompany (جدول واسط )
شناسه سمت
شناسه شخص شرکت
استان Province
ID
نام
واحد ثبتی registrationUnit
ID
ID استان
نام
شهرستان City
ID
ID استان
نام
11 پاسخ
با سلام و تشکر. فقط در مورد جدول شخص و کاربران هم میشه راهنمایی بفرمایید که با توجه به اینکه تعدادی فیلد مشترک دارن بهتر نیست یه جدول پایه ای ایجاد بشه و فیلدهای مشترک جدول شخص و کاربران داخل اون قرار بگیره و رفرنس جدول فوق به جدول شخص و کاربران اضافه بشه؟
فقط ادغام جدول استان و شهرستان،ادغام بخاطر گزارش گیری هست؟ اینو بیشتر برای افزایش اطلاعات خودم میپرسم چون فکر کنم خیلی از دیتابیس ها شامل این دو مورد هستن
در مورد سمت هم بخاطر گزارش گیری میفرمایید که دو تا فیلد سمت در نظر گرفته بشه و جدول واسط طراحی نشه؟
اینها نظرات بنده است و ممکن است دوستان دیگر با من موافق نباشند
۱- id را از جداول Company , PersonCompany , PersonTypeInCompany حذف کنید.
۲- اگر سیستم شما گزارشهای زیادی هم دارد سعی کنید خیلی Normalize نکنید به این صورت که جداول Province , City با یکدیگر الحاق شوند و جداول RegistrationUnits , StocksType با جدول Company الحاق شوند.
با سلام و تشکر. برای ادغام استان و شهرستان منظورتون این هست که یه جدول recursive در نظرگرفته بشه که دارای فیلد parentId هست که برای استان ها null قرار میگیره؟
جدول PersonTypeInCompany رو برای این در نظر گرفتم که شاید شخصی داخل یک شرکت بیش از یک نقش داشته باشه که این رو شما میفرمایید لازم نیست چون چنین حالتی نمیتونه اتفاق بیفته
جدول registrationUnit هم برای این در نظر گرفتم که هر اداره ثبت اسناد و املاک استان دارای تعدادی مرجع ثبت شرکت و موسسه غیر تجاری هست:
http://irsherkat.ssaa.ir/Design/SearchCompanyPublicInfo.aspx
حالا این مورد رو هم به نظرم میشه حذف کرد و از جدول شهرستان خوند؟
ممنون دوستان من تصویر رو اصلاح کردم و توضیحان رو هم اضافه کردم
فقط اینو بگم که سیستم هنوز طراحی نشده و تازه میخواد پیاده سازی بشه
سلام
1-نه نیازی نیست کار رو برای خودتون سخت کنید فقط یک جدول داشته باشید که شامل کد، نام استان ، نام شهرستان باشه.
2-البته دیروز من فراموش کردم یک مطلبی رو خدمتتون عرض کنم!در مواقعی هم میتونه این امکان وجود داشته که یک مدیر عامل میتونه یکی از اعضای هیئت مدیره هم باشه که این مورد در مواقعی اتفاق می افته که تعداد اعضاء هیئت مدیره کم باشه و یک شخص بخواد 2 سمت داشته باشه.
برای رفع این موضوع هم میتونید 2 فیلد به نام های سمت اول و سمت دوم درنظر بگیرید.
3-بله مشکلی نداره چون طبق همون لینکی که شما فرستادید در نهایت در قسمت واحد ثبتی داره به خود همون شهر اشاره می کنه.
مثلا استان قزوین- واحد ثبتی هم میشه مرجع ثبت شرکت ها و موسسات غیر تجاری قزوین.
که این موضوع رو می تونید از همون جدول استان-شهرستان بخونید.
باز اگه سئوالی بود بنده در خدمتم.
خوب باشید.
سلام
اجازه بدید من با یک سناریو خدمتتون عرض کنم!
برای یک مجموعه ای ما اومدیم یک نرم افزاری نوشتیم!
قسمت اطلاعات شخصی این اشخاص با اطلاعات شغلی آنها دقیقا 67 ستون می شد. و هیچ کدام از این موارد تکراری نبودند که بخواهیم بگوییم بحث افزونگی پیش خواهد آمد. و در جدول کاربران هم از نام کاربری گرفته تا آیپی سیستم همه باید ذخیره میشد. که این جدول هم شامل 17 ستون می شد.
حالا شما در نظر بگیرید اگر ما می خواستیم همه ی این موارد رو در یک جدول ذخیره کنیم چه می شد؟84 ستون در یک جدول!!!
البته باز هم هیچ کدام از این ستونها تکراری نبود.
ما این 84ستون رو بسته به اطلاعاتی که به ما داده بودند تفکیک کردیم و در نهایت بین 4 جدول تقسیم کردیم.
و اما چند نکته:
تعداد اشخاص این مجموعه حدود 360 نفر بودند(تعداداشخاص عر روز رو به افزایش بود) که از این 360 نفر عده ای هم نقش اجرایی داشتند و برخی هم نداشتند و همینطور باید گزارشات متنوعی ارائه میشد.
اگر ما میخواستیم این 84 ستون رو در یک جدول ذخیره کنیم برای بحث گزارشگیری و مسائل دیگر به مشکل بر می خوردیم چون می بایست حدود 12 تا 13 ایندکس در این جدول ایجاد می کردیم. که در این صورت عملیاتی همچون Insert،,Update با کندی صورت می گرفت و حجم لاگ فایل بخاطر همین موضوع افزایش پیدا میکرد.
در ثانی می بایست تاریخچه ی هر کدام از این اطلاعات در صورت تغییر کردن در جدول دیگری ذخیره میشد!
حالا به نظر شما بهتر بود این 84 ستون رو یک جدول می گرفتیم یا چند جدول؟
و اینجاست که همیشه یک قاعده جوابگو نیست و باید شما جداولتون رو بر مبنای نیاز اون مجموعه طراحی کنید.
در پایان باید خدمتتون عرض کنم شما هم به تعداد کاربرانتان و همینطور تعداد ستون های جداولتون نگاه کنید اگر جزئیات اطلاعات ذخیره شده کم باشد و همینطور تعداد کاربران سیستم، میتونید این جداول رو با هم ادغام کنید.از بابت فنی هم مشکلی ایجاد نخواهد شد در غیر اینصورت باید نرمال سازی انجام دهید.
موفق باشید.
سلام
خواهش می کنم.
1-برای بحث کاربران و همینطور سطح دسترسی به این لینک مراجعه کنید.(اگر نیازتون رو مرتفع نکرد، بفرمایید تا توضیح بدم)
2-همونطور که مطلع هستید در بحث طراحی دیتابیس یکسری قواعد وجود داره و باقی موارد بصورت سلیقه ای انجام می شود.
در زمانی که تعداد گزارش گیری ها بالا باشد و این جداول پایه با چند جدول دیگر درگیر باشند برای بالا بردن سرعت واکشی اطلاعات معمولا از روش Denormal استفاده می کنند. که این قضیه هم باید با احتیاط انجام بشه.
فرض کنید هر استان به طور میانگین شامل 10 شهرستان باشد در آن صورت ما 31 استان و برای هرکدام 10 شهرستان داریم که در مجموع 310 رکورد خواهیم داشت.پس با این وجود می تونیم از این تکنیک استفاده کنیم و سطرهای مورد نظرمون رو بدون نیاز به Join واکشی کنیم!البته در مواقعی هم که تعداد سطرها زیاد باشد می تونید جداولتون رو در سطح Row یا Page فشرده کنید،تا میزان IO کمتر و همینطور سرعت واکشی بالا رود.
3-بله درسته.در واقع ما برای مواردی از جداول واسط استفاده می کنیم که واقعا ارزشش رو داشته باشد! به طور مثال در نظر بگیرید در یک هیئت مدیره که از 5 نفر تا 9 نفر متغییر می باشد. چند نفر در نهایت می تونند 2 سمت اجرایی داشته باشند؟ نهایت 2 تا 3 نفر!
پس برای راحتی کار و همینطور سرعت واکشی، بهتر است از این روش استفاده کنید.
موفق باشید
تشکر فراوان از راهنمایی خوب و کاملتون
سلام
لطف کنید عکس رو جای دیگری آپلود کنید و لینک رو در اینجا قرار بدید.
تصویر واضح نیست.
در ضمن یک توضیحی هم در مورد جداولتون ارائه کنید.
صحبت هایی که شما عنوان کردید خیلی کلی است.
سلام. بسیار سپاسگذارم. فقط در مورد جداول شخص و کاربر، افزونگی مدنظرم هست که نیازی هست مثلا یه جدول بیس درنظر گرفته بشه؟
سلام
در جدول "شخص-شرکت" فیلدی دارید به نام سمت که برای این فیلد یک جدول جداگانه در نظر گرفته شده است.
در قوانین هیئت مدیره اون چیزی که مرسوم است کسی بیشتر یک سمت نمیتواند داشته باشد.
پس با این وجود شما می تونید جدول سمت رو حذف کنید و در همان جدول "شخص-شرکت" لحاظ کنید.
در مورد استان وشهرستان، بنده با حمید عزیز موافقم،می تونید این 2 جدول رو با هم ادغام کنید.
این دو جدول برای چه منظوری در نظر گرفته شده؟
:"سمت شرکت PersonTypeInCompany (جدول واسط )"
"واحد ثبتی registrationUnit"