- varchar استاندارد ANSI داره
- varchar2 استاندارد oracle رو داره (ماکزیمم 4000 بایت تو 11g و 32767 بایت تو 12c)
- char به صورت ماکزیمم 255 بایت یا کاراکتر رو ساپورت میکنه
- nvarchar2 به صورت ماکزیمم 2000 بایت یا کاراکتر
- number به صورت ماکزیمم ۳۸ رقم
- date شامل "قرن، سال، ماه، روز، ساعت، دقیقه، ثانیه" داره
- timestamp تمام date رو داره بعلاوه اینکه ثانیه تا ۹ رقم ریزتر هم میشه
- long برای کاراکتر استفاده میشه و ماکزیمم اون ۲ گیگ‌ه
- long raw برای فایلهای باینری هستش و برای فایلهای pdf, doc, mp3, avi, dll, ... هستش ماکزیمم ۲ گیگ
LOBs یا همون Large Objects
- clob به صورت کاراکتره و ماکزیمم ۴ گیگ‌ه
- nclob به صورت کاراکتر با ساپورت کاراکترهای national و ماکزیمم ۴ گیگ‌ه
- blob به صورت binary برای فایلهای باینری هستش و برای فایلهای pdf,rtf, doc, mp3, avi, dll, ... هستش، ماکزیمم ۴ گیگ
- bfile در این type فایلها به صورت اکسترنال و روی OS قرار داردند و درون bfile اشاره‌گر به فایل قرار دارد، ماکزیمم ۴ گیگ
- securefile همون blob با سرعت و کارایی بیشتر
تفاوت بین long و long raw و LOBها
1:
اگه فیلدهای جدول شما به صورت زیر باشه به طور قطع شما موقع ساخت جدول به مشکل میخورید:
create table e(
e_id number(20),
f_name varchar(40 char),
...,
...,
cv long,
img long raw
);
نکته اینجاست که در یک جدول ۲ فیلد long نمیتوان داشت
2:
سرعت خوندن در log و LOBها متفاوته
در حقیقت long و long raw به صورت sequencial از حافظه میخونن(سریالی) و LOBها به صورت random access(مستقیم)
3:
در اوراکل با contex index یا همون oracle text میشه فیلدهای blob رو به صورت لغت به لغت ایندکس‌گذاری کرد همچنین به طور کامل از فارسی پشتیبانی میکنه
نکته: روز فیلدهای blob و clob نمیتوان index معمولی (b-tree ,bitmap) گذاشت
نکته: اگه فایل pdf داشته باشید context index نمیتونه فارسی‌ها رو ایندکس بکنه و فقط انگلیس‌ها رو ایندکس میکنه
4:
ذخیره فایلهای باینری مثل فیلم و موزیک در bfile عملکرد بهتری نسبت به فقط ذخیره آدرس فایل در varchar یا ... دارد
مثلا فرض کنید OS ما ویندوزه و فایلهای ما هم در درایوهای ویندوز قرار داره پس موقع ذخیره آدرس فایل در varchar آدرس فایلها به صورت ویندوزی است در این حالت اگه مسیر فایلها رو عوض کنیم کل مسیرهای ذخیره شده در دیتابیس هم باید عوض شود همچنین اگه سیستم‌عاملمون رو عوض کنیم و به unix baseها یا unix likeها که از استاندارد POSIX استفاده میکنن بریم دوباره کل مسیرها باید عوض شوند تازه اگه فایلها تو انتقال طبقه‌بندی و از هم جدا بشن درست کردن مسیرها بسیار کار مشکلی خواهد بود
برای رهایی از این مشکلات از bfile استفاده می‌کنیم و با ایجاد یک آبجکت دایرکتوری در دیتابیس مسیر فایلها رو ذخیره می‌کنیم در این رویکرد اگه سیستم‌عامل عوض شود یا بخوایم مسیر رو عوض کنیم فقط مسیر دایرکتوری رو عوض می‌کنیم
مزیت دیگه bfile نسبت به varchar برای ذخیره آدرس فایلها اینه که میتونیم رو فایلها ایندکس بذاریم(مثلا ایندکس روی doc, docx, rtf, ...) در صورتی که اگه از نوع varchar باشه فقط روی رشته‌ها ایندکس انجام میشه
اگه blob رو به bfile ببریم اولین مشکل میتونه تو خراب شدن پسوند فایلها در OS به وجود بیاد، دومین مشکل سر export گیری هستش اگه فایلها توی blob باشن با یه export تمام فایلها هم بک‌آپ گرفته میشن همچنین حجم بک‌آپ بالاتر میره
char
وقتی از data type char استفاده می‌کنید داده‌ها تو حافظه به صورت fix ذخیره می‌شوند
(پس سایز char به صورت fix است) مثلاً:
Mahdi char(20) => 'Mahdi '
مشکلات char
- اشغال زیاد حافظه
- مشکل در index و sort
- مشکل در select (حتما باید موقع select ما trim کنیم رشته ورودی رو)
create table employees(
employee_id number(10),
f_name varchar2(40 char)
)
تو فیلد اول type ما در حقیقت 10 بایت‌ه و تعداد کاراکترهاش بسته به character set دیتابیس داره
و تو فیلد دوم type ما دقیقاً 40 کاراکتره
دریافت
دریافت