کار با فیلدهای DateTime با دقت میلی ثانیه

[omid_Ahmadi]

سلام
توی Help مربوط به SQL Server نوشته بود که فیلدهای DateTime دارای دقت یک در سه هزارم ثانیه هستن، پس می تونن دقت یک دسی ثانیه که مد نظر هست رو ذخیره کنن.
وقتی یه دستور اینسرت با مقدار "2006/08/04 16:56:26:300" (بر عکس بخونید تا درست بشه:لبخند: ) رو فرستادم، تونست اون رو ذخیره کنه. اما وقتی رفتم توی بانک و نگاه کردم با دقت ثانیه ذخیره شده بود. چرا؟

[AminSobati]

create table t1(c1 datetime)
insert t1 values ('2006/08/04 16:56:26:300')
select * from t1

مشکل کجاست؟

[omid_Ahmadi]

خیلی ممنون مشکل این بود که وقتی همین دستور رو اجرا می کردم میلی ثانیه رو توی Enterprise Manager نشون نمی داد. اما توی Query Analyzer درست دیتاها رو نشون میده.

اما حالا یه سوال دیگه دارم. یه جدولی با دو ستون، یکی از نوع DateTime و یکی دیگه از نوع bit دارم این جدول اطلاعاتی مشابه زیر داره:



2006-08-05 12:31:28.643 1
...
2006-08-05 12:45:28.643 1
2006-08-05 12:45:38.643 1
2006-08-05 12:45:48.643 1
2006-08-05 12:45:53.143 0
2006-08-05 12:45:58.643 0
...
2006-08-05 12:58:38.643 0
2006-08-05 12:58:48.643 0
2006-08-05 12:58:58.643 0
2006-08-05 12:59:05.043 1
2006-08-05 12:59:08.643 1
2006-08-05 12:59:18.643 1
...


می خوام یه درست SQL بنویسم که جدول بالا رو به صورت زیر در بیاره:



...
2006-08-05 12:31:28.643 1
2006-08-05 12:45:53.143 0
2006-08-05 12:59:05.043 1
...


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

[AminSobati]

شما میتونین یک فیلد جدید اضافه کنید که باعث دسته بندی صفرها و یکها بشه. یعنی در این فیلد جدید:
- تمام یکهای اول=1
- تمام صفرهای دوم=2
- تمام یکهای سوم=3
- تمام صفرهای چهارم=4
- ... الی آخر

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

[omid_Ahmadi]

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

حالا اگر ستون مربوط به مارک کردن رو ایجاد کنم، باز هم لازمه که یه Cmposite Index روی این دو تا ستون ایجاد کنم؟ و اگر بهتره که ایندکس داشته باشه، این ایندکس به صورت CLUSTERED باشه بهتره یا NONCLUSTERED ؟

[AminSobati]

وجود Composite Index ایندکس باز هم مفیده. اول اون فیلدی که برای مارک زدن استفاده میشه باید در ایندکس بیاد و بعد هر فیلد دیگه ای که در فهرست Select نام بردین.
به طور معمول PK اگر Clustered باشه بهتره اما حالتهایی هم هست که میشه این کار رو نکرد. با توجه به اینکه سایر Queryهای شما رو نمیدونم چی هستن روی این جدول، این ایندکس رو Non Clustered کنین.