PDA

View Full Version : طراحی پایگاه داده ای که در آن فاکتور زمان ،نقش مهمی دارد!!



*shidrokh*
شنبه 11 خرداد 1392, 02:35 صبح
سلام
میخواستم بدونم برای اینکه زمان رو بتونیم تو پایگاه داده ای که برای برنامه مون مینویسیم در نظر بگیریم باید چیکار کنیم؟
مثلا سیستم هتل که بر اساس زمان و تاریخ کار میکنه در زمان جاری یه فیلد(اتاق) تو یه تاریخ ،پر ،تو یه تاریخ دیگه همون اتاق در حالت رزرو و... نشون داده بشه؟ چطوری این چند وجهی رو باید درنظر گرفت؟:افسرده:

majidrezaei2007
شنبه 11 خرداد 1392, 10:40 صبح
توی بحث پایگاه داده های پیشرفته یک نوع از مدل های دیتابیس ، دیتابیس های temporal هستند که به پایگاه داده های زمانمند معروف هستند . در این پایگاه داده ها زمان نقش بسیار مهمی دارد . به عنوان مثال کلیه تغییرات بانک بر اساس زمان قابل بازیابی هستند و پایه پرس و جو گرفتن فاکتو زمان می باشد . راجع به temporal database تحقیق کنید مطالب مفیدی پیدا خواهید کرد . مثلا یکی از پرکاربرد ترین موارد استفاده از این پایگاه داده ها ، اطلاعات مربوط به سیستم های پیش بینی وضعیت هوا می باشد که زمان در آنها نقش مهمی دارد . لینک های زیر برای شروع کمکتان خواهد کرد

http://en.wikipedia.org/wiki/Temporal_database
http://www.timeconsult.com/TemporalData/TemporalDB.html

موفق باشید

*shidrokh*
دوشنبه 20 خرداد 1392, 17:13 عصر
بخاطر اینکه از این روش استفاده نکنم و جداولم معمولی باشن
یه جدول رزرو در نظر گرفتم که اطلاعات هر رزرو در اون درج میشه. و برای جستجو هنگام رزرو دوباره از همین جدول استفاده میشه. و براش دو فیلد: "از تاریخ "و "تا تاریخ" هم گذاشتم . مثلا وقتی یه نفر برای روز چهارم تا هشتم ماه خرداد یه اتاق رزرو میکنه ،اگه کس دیگه ای بخواد برای روز پنجم تا هفتم خرداد همون اتاق رو رزرو کنه،(که نمیشه) سیستم از کجا باید متوجه بشه؟ منظورم اینه که تابعی داریم که توی تاریخ جستجو کنه و بفهمه، نه اینکه فقط تطبیق text _box ها رو بررسی کنه؟راستی من نوع این فیلد ها رو nvarchar تعریف کردم برا تاریخ.

veniz2008
دوشنبه 20 خرداد 1392, 18:12 عصر
سلام.
برای افزایش سرعت یکسری نکات رو مد نظر قرار بدید:
1. کلید جدول رو که معمولا جستجوهای زیادی بر پایه اون انجام میشه، حتی الامکان int در نظر بگیرید. چراکه سرعت در جستجوی فیلدهای عددی نسبت به غیر عددی بیشتر هست.
2. کلید رو تا حد امکان ساده بگیرید و از ابرکلید(کلید ترکیبی) استفاده نکنید.
3. تا حد امکان از nvarchar استفاده نکنید چراکه دو برابر varchar فضای دیتابیس رو اشغال میکنن. به نظر میرسه تاریخ رو میشه varchar گرفت.
4. تا حد امکان جداول رو به گونه ای بسازید که نیاز به join های بی مورد بین جداول نباشه.
5. به غیر از فیلد کلید که خود sql بصورت اتومات یک clustered index براش میسازه. خودتون با توجه به نیاز پروزتون یک یا چند non clustered index برای جداولتون ایجاد کنید. البته در ایجاد تعداد زیاد این ایندکس ها زیاده روی نکنید. یکی از راه های تشخیص اینکه چه فیلدی رو non clusterd index قرار بدید اینه که روی چه فیلدی بیشتر عملیات جستجو رو انجام می دید. البته معیارهای دیگه ای هم هست که توصیه میکنم حتما درباره ایندکس ها مطالعه بفرمایید. چون ایندکس مناسب بر روی سرعت جستجوها (در تعداد رکوردهای زیاد) قدرت خودش رو به معرض نمایش میزاره.
6. استفاده از کوئری های بهینه. فرض کنید بخوایم بفهمیم که آیا یک شماره شناسایی (کلید) که توسط کاربر وارد شده است در جدولی با تعداد رکوردهای خیلی زیاد وجود داره یا نه. برای این کار دو کوئری زیر رو در نظر بگیرید :
1. استفاده از دستور EXISTS :

if(EXISTS(select UserID from TblUser where UserID = @userid))
2. استفاده از count :

select count(UserID) from TblUser where UserID = @userid
کوئری اول (دستور EXISTS ) به محض پیدا کردن رکورد، دیگه جستجو رو ادامه نمیده ولی کوئری دوم (دستور count) تا آخرین رکورد جدول رو پیمایش میکنه. این فقط یک مثال ساده بود. این مطلب رو در کنار ایندکس مناسب، بسیار جدی در نظر بگیرید.
7. سخت افزار قدرتمند. بدون شک شما برای محاسبه و جابه جایی اطلاعات به cpu و رم مناسب نیاز خواهید داشت.
گذشته از این موارد، طراحی درست و سبک کدنویسی شما میتونه اهمیت زیادی داشته باشه. مثلا استفاده از stored procedure ها در مقایسه با روش های معمولی بسیار کارآمدتر خواهد بود.
موفق باشید.

*shidrokh*
چهارشنبه 22 خرداد 1392, 19:11 عصر
بخاطر اینکه از این روش استفاده نکنم و جداولم معمولی باشن
یه جدول رزرو در نظر گرفتم که اطلاعات هر رزرو در اون درج میشه. و برای جستجو هنگام رزرو دوباره از همین جدول استفاده میشه. و براش دو فیلد: "از تاریخ "و "تا تاریخ" هم گذاشتم . مثلا وقتی یه نفر برای روز چهارم تا هشتم ماه خرداد یه اتاق رزرو میکنه ،اگه کس دیگه ای بخواد برای روز پنجم تا هفتم خرداد همون اتاق رو رزرو کنه،(که نمیشه) سیستم از کجا باید متوجه بشه؟ منظورم اینه که تابعی داریم که توی تاریخ جستجو کنه و بفهمه، نه اینکه فقط تطبیق text _box ها رو بررسی کنه؟راستی من نوع این فیلد ها رو nvarchar تعریف کردم برا تاریخ.

با تشکر از veniz2008 ولی من هنوز جواب سوالم (تابعی برای چک کردن تاریخ)رو پیدا نکردم! ممنون میشم اگه جواب بدین چون فوریه.

tooraj_azizi_1035
چهارشنبه 22 خرداد 1392, 20:17 عصر
سلام نه تاریخ شروع (sDate) و نه تاریخ پایان (eDate) نباید در رنج تاریخ رزرو شده ای مانند "روز چهارم تا هشتم ماه خرداد" بیفتد:


SELECT * FROM `test_table`
WHERE sDate NOT BETWEEN start_date AND end_date
AND
eDate NOT BETWEEN start_date AND end_date

البته ID اتاق هم باید در WHERE به شکل AND RoomID=@RoomID اضافه بشه.
و مسئله بعدی تاریخ شمسی هست که فکر می کنم کار کنه چون مقایسه رشته ای در مورد BETWEEN و رشته جواب میده.