ورود

View Full Version : چند سوال درباره نوع داده ای TimeStamp



tst835
دوشنبه 18 خرداد 1394, 20:10 عصر
سلام.
من برای رفع مشکل همزمانی در دیتابیس از یک فیلد TimeStamp استفاده میکنم. در سمت SQL مقدار باینری مربوط به این فیلد رو به مقدار (varchar(max تبدیل و برگشت میدم و در زمان لازم دوباره این مقدار رشته ای رو به آرایه ای از بایت ها ( []byte ) تبدیل و برای sql میفرستم و عملیات مقایسه رو انجام میدم. حالا سه تا سوال داشتم :
1. با تبدیل مقدار به varchar یه سری رشته های خاص تولید میشه (در عکس زیر اولین ستون از سمت راست). من همین cast رو در یک query در سمت sql اجرا میکنم هیچ رشته ای تولید نمیشه. آیا این نوع تبدیل مشکلی ایجاد نمیکنه؟
2. آیا مقدار TimeStamp یونیک و منحصربفرده؟ یعنی تو شرط کوئری می تونم فقط از همین مقدار استفاده کنم یا کلید جدولم رو هم باید در شرط بیارم؟ (ظاهرا که مقدارش یونیک هست).
3. با cast کردن مقدار TimeStamp به (varchar(max آیا همچنان مقدار یونیک میمونه؟(در حالتیکه اصل مقدار یونیک بوده باشه).
نمایش داده ها در سمت برنامه :
132072

نمایش داده ها در سمت sql :
132074

SabaSabouhi
سه شنبه 19 خرداد 1394, 11:43 صبح
سلام
در مورد cast کردن پاسخ رو نمی‌دونم، اما در پاسخ به پرسش دوم شما، بله مقدار TimeStamp در کل دیتابیس یکتا هشت.
و دیگه این که این نوع داده به زودی از Sql Server حذف می‌شه. بجاش از RowVersion استفاده کن.

صبا صبوحی

golbafan
پنج شنبه 21 خرداد 1394, 10:02 صبح
اگر رکوردهای شما یکی یکی وارد بشن مقدار timestamp یونیک خواهد بود چرا که تفاوت در این فیلد با میلی ثانیه هستش
اما شما میتونید از فیلد autoinc به همراه timestamp همزمان استفاده کنید تا مشکل برطرف بشه
باید کلید اصلی رو بزارید روی هر دو فیلد

در مورد cast هم درصورت یونیک بودن timestamp مقادیر برگشتی یونیک خواهد بود

ASKaffash
جمعه 22 خرداد 1394, 12:16 عصر
سلام
برای مدیریت همزمانی باید یکی از این دو روش را انتخاب کنید تا بهینه ترین راه حل باشد :
1- استفاده از یک فیلد از نوع indentity
2- استفاده از Max یک فیلد ایندکس شده یونیک و افزایش یک واحد و سپس مدیریت خطای اس کیوال سرور
من روش دوم را می پسندم در شبکه و برای کاربران زیاد هم تست کرده ام و کارامد است بقیه روش ها خیلی منظقی نیست

tst835
شنبه 23 خرداد 1394, 09:00 صبح
سلام
برای مدیریت همزمانی باید یکی از این دو روش را انتخاب کنید تا بهینه ترین راه حل باشد :
1- استفاده از یک فیلد از نوع indentity
2- استفاده از Max یک فیلد ایندکس شده یونیک و افزایش یک واحد و سپس مدیریت خطای اس کیوال سرور
من روش دوم را می پسندم در شبکه و برای کاربران زیاد هم تست کرده ام و کارامد است بقیه روش ها خیلی منظقی نیست
ضمن تشکر از حضور شما در بحث.
شاید من منظور شما رو درست متوجه نشده باشم ولی به نظر میرسه هر دو روش جوابگوی مشکلات همزمانی نباشه. من یک مثال میزنم تا روی اون بهتر بشه بحث کرد.
ما در نرم افزار (تحت شبکه) فرضا جدولی به نام Customers داریم که مثلا 3 فیلد FullName ، ID و Purchase رو داریم( کاری به اشتباه بودن طراحی جدول نداشته باشیم).
ما یک مشتری با کد : 1، نام و فامیل : مرادد اکبری (اشتباها توسط کاربر1 (کاربر امور روزمره) یه حرف "د" اضافی برای اسمش قرار داده شده) و میزان خرید : 35000 (مقدار صحیح 30000 بوده ولی اشتباها توسط کاربر2 (کاربر بخش مالی) 35000 ثبت شده).
حالا هر کدوم از این کاربرها برای تصحیح اشتباهشون رکورد مورد نظر رو بصورت همزمان فراخوانی میکنن. کاربر2 میزان خرید رو به 30000 تغییر میده و دکمه تصحیح رو میزنه. نتیجه : 1 مرادد اکبری 30000
کاربر 1 میاد نام مشتری رو به "مراد" تغییر میده (ولی همچنان مقدار خرید رو 35000 می بینه (چون قبل از تغییر، رکورد رو فراخوانی کرده)) و دکمه تصحیح رو میزنه : نتیجه نهایی روی این رکورد : 1 مراد اکبری 35000
حالا این Identity یا مقدار MAX یونیک که شما گفتید چطور میتونه این رکورد رو کنترل کنه؟
در صورتیکه TimeStamp یا RowVersion به محض تغییر یکی از فیلدهای رکورد، بصورت اتومات مقدارش تغییر میکنه که میتونه ملاک مناسبی برای مقایسه و تشخیص تغییرات باشه.

golbafan
یک شنبه 24 خرداد 1394, 09:14 صبح
ضمن تشکر از حضور شما در بحث.
شاید من منظور شما رو درست متوجه نشده باشم ولی به نظر میرسه هر دو روش جوابگوی مشکلات همزمانی نباشه. من یک مثال میزنم تا روی اون بهتر بشه بحث کرد.
ما در نرم افزار (تحت شبکه) فرضا جدولی به نام Customers داریم که مثلا 3 فیلد FullName ، ID و Purchase رو داریم( کاری به اشتباه بودن طراحی جدول نداشته باشیم).
ما یک مشتری با کد : 1، نام و فامیل : مرادد اکبری (اشتباها توسط کاربر1 (کاربر امور روزمره) یه حرف "د" اضافی برای اسمش قرار داده شده) و میزان خرید : 35000 (مقدار صحیح 30000 بوده ولی اشتباها توسط کاربر2 (کاربر بخش مالی) 35000 ثبت شده).
حالا هر کدوم از این کاربرها برای تصحیح اشتباهشون رکورد مورد نظر رو بصورت همزمان فراخوانی میکنن. کاربر2 میزان خرید رو به 30000 تغییر میده و دکمه تصحیح رو میزنه. نتیجه : 1 مرادد اکبری 30000
کاربر 1 میاد نام مشتری رو به "مراد" تغییر میده (ولی همچنان مقدار خرید رو 35000 می بینه (چون قبل از تغییر، رکورد رو فراخوانی کرده)) و دکمه تصحیح رو میزنه : نتیجه نهایی روی این رکورد : 1 مراد اکبری 35000
حالا این Identity یا مقدار MAX یونیک که شما گفتید چطور میتونه این رکورد رو کنترل کنه؟
در صورتیکه TimeStamp یا RowVersion به محض تغییر یکی از فیلدهای رکورد، بصورت اتومات مقدارش تغییر میکنه که میتونه ملاک مناسبی برای مقایسه و تشخیص تغییرات باشه.

تنها راه حل این مشکل استفاده از روشهای قفل کردن رکورد میباشد.
https://msdn.microsoft.com/en-us/library/ms173763.aspx

ASKaffash
یک شنبه 24 خرداد 1394, 10:01 صبح
سلام
پس از RowLock استفاده کنید تا بقیه در انتظار باز شدن قفل باشند مثلا :
Set Tran Isolation Level Serializable
Begin Tran
Select * From T1 With (RowLock) Where A1=2

tst835
سه شنبه 26 خرداد 1394, 08:36 صبح
تنها راه حل این مشکل استفاده از روشهای قفل کردن رکورد میباشد.
https://msdn.microsoft.com/en-us/library/ms173763.aspx


سلام
پس از RowLock استفاده کنید تا بقیه در انتظار باز شدن قفل باشند مثلا :
Set Tran Isolation Level Serializable
Begin Tran
Select * From T1 With (RowLock) Where A1=2
گذاشتن قفل روی رکورد در نرم افزارهای تحت شبکه ای که تراکنش بالایی دارند باعث wait ای کاربران میشه.
بعبارتی کاربر باید منتطر بمونه تا قفلی که بخاطر کاربر فبلی ایجاد شده از روی رکورد برداشته بشه تا بتونه با رکورد مورد نظر کار کنه.

golbafan
یک شنبه 31 خرداد 1394, 11:17 صبح
گذاشتن قفل روی رکورد در نرم افزارهای تحت شبکه ای که تراکنش بالایی دارند باعث wait ای کاربران میشه.
بعبارتی کاربر باید منتطر بمونه تا قفلی که بخاطر کاربر فبلی ایجاد شده از روی رکورد برداشته بشه تا بتونه با رکورد مورد نظر کار کنه.

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

مگر اینکه از mysql استفاده کنید
در این صورت با استفاده از فیلد int در حالت autoinc دیگه میتونید نگران نباشید.