احسان رضایی

گاهی داخل app نیاز به یک فیلد با مقادیر مشخصی داریم. مثل status در جدول payments که میتونه paid یا unpaid باشه. از اونجایی که در پروژه های مختلف این فیلد رو به روش های متفاوتی پیاده میکردن تصمیم گرفتم در موردش کمی بنویسم. به طور کلی سه دیتا تایپ برای این قبیل فیلد ها انتخاب میشن که در موردشون توضیح میدم.

- string/varchar: ساده ترین رویکرد انتخاب دیتا تایپ string هست. وضوح خوبی هم داره. چون هنگام توسعه با یک نگاه به سطر مورد نظرتون متوجه وضعیتش میشید. حتی میتونید توی فرانت دقیقا این رشته رو چاپ کنید(ولی نه توی app های چند زبانه). اما بسته به طول رشته طبیعتا فضایی برای ذخیره سازی در نظر گرفته میشه. هر چند موضوع فضا خیلی وقته به حاشیه رفته و کمتر کسی نگران پر شدن هارد سرورشه، اما اگر سطرهای زیادی داشته باشید هنگام پیمایش اطلاعات، کندی رو حس خواهید کرد. مورد بعدی تغییرات هست. فرض کنید پس از مدتی متوجه غلط املایی در یکی از آیتم ها میشید، تمام سطر ها باید update بشن.

- enum: چیزی که ازش به شدت متنفرم! من دوست ندارم منطق و فرآیند برنامه رو توی دیتابیس ببرم. چرا که مثلا هنگام تغییرات و یا کم و زیاد شدن آیتم ها مجبورم جدول رو هم بروز کنم.

- tinyint: یک رویکرد مناسب برای بهبود سرعت query ها و ملایم در هنگام تغییرات یا افزودن گزینه های بیشتر. نیازی نیست به طور مستقیم با اعداد کار کنید، میتویند از جدول میانی یا ثابت ها بهره برد. من به طور پیشفرض از ثابت ها برای آیتم های کم و جدول در مواقعی که گزینه های زیادی یاا اطلاعات اضافی مثل توضیحات و... داریم استفاده میکنم.

انتخاب هر یک از این روش ها بستگی به شرایط و app شما داره. میتونید string رو برای پروژه های کوچک و اطلاعات کم استفاده کنید. enum توی پروژه هایی که به شما ارث رسیده(یک پروژه قدیمی که مشغول توسعه نسخه جدیدش هستید) و فرآیند ها و منطق برنامه از قبل مشخص هست هزینه تغییرات پایینی داره. tinyint هم زمانی که در یک پروژه بزرگ یا مواقعی که تغییرات زیادی هنگام توسعه اتفاق میوفته کارآمد هست.

هنگامی که موضوع کار با داده ها در application مطرح میشه احتمالا نیاز به یک ORM پیدا خواهید کرد. ORM یک لایه بین پایگاه داده و application شماست. که به وسیله اون عملیات CRUD یا به عبارت دیگه create, read, update,  delete به آسونی انجام میپذیره. بیشتر از این به ORM نمیپردازم چون در حال حاضر اکثر فریمورک های مدرن ازش استفاده میکنن و بعید میدونم شما تا الان با اون کار نکرده باشید.

دو الگو پیاده سازی محبوب ORM ها Active Record و Data Mapper هست. در این مقاله تصمیم دارم به تفاوت بین این دو الگو بپردازم. مزایا و معایبشون چی هست و چطور میشه یکی از این الگو ها رو برای کار خودمون انتخاب کنیم.

بیشتر به درد اونایی میخوره که وسط کار یاد migration افتادن. زمانی که دیتابیس رو طراحی کردن و آماده است. یا کسایی که حال و حوصله ی migration نوشتن رو ندارن.

برای این کار(ایجاد خودکار migration از روی پایگاه داده) در درجه اول نیاز به PHP >= 7.1 و Yii >= 2.0.15.1 دارید. داخل composer.json بسته bizley/migration رو اضافه و بروزرسانی کنید.

{
    "require": {
        "bizley/migration": "~3.0.0"
    }
}

برای PHP < 7.1 میتونید از نسخه ی 2.3.0 این بسته استفاده کنید.

{
    "require": {
        "bizley/migration": "~2.3.0"
    }
}

قدم بعدی پیکره بندی هست. ترجیحا داخل پیکره بندی console این کارُ انجام بدین.

'components' => [
    // ...
],
'controllerMap' => [
    'migration' => [
        'class' => 'bizley\migration\controllers\MigrationController',
    ],
],

توسعه دهندگان نرم افزار همیشه علاقمند به گسترش فعالیت و رفتن به سمت بازار های جدید هستن. به این معنی که سعی میکنن محصولات خودشون رو در مناطق مختلف قرار بدن. در این مطلب چند روش برای بومی سازی یا مدل سازی داده و طراحی پایگاه داده چند زبانه توضیح داده میشه. مخصوصا بومی سازی در سطح محتوای نرم افزار.

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

زمانی که درباره بومی سازی فکر میکنیم در درجه اول ترجمه محتوا ذهن ما رو به خودش مشغول میکنه. ما نیاز به یک مدل پایگاه داده قوی و کارآمد برای ذخیره محتوای ترجمه شده در چندین زبان داریم.

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

elastic اخیرا ماژول های filebeat رو معرفی کرده، که برای پردازش و به دست آوردن یک بینش بصری از log های رایج طراحی شده. filebeat در kibana به عنوان نقطه ی شروع یک داشبورد از پیش طراحی شده در اختیارتون قرار میده که میتونید بعدا نمودار های دیگه ای هم بسته به نیازتون بهش اضافه کنید. ماژول Apache2 که اینجا در موردش حرف میزنیم، اطلاعات مربوط به log های apache رو از مسیر های پیشفرض جمع آوری میکنه، اگر مسیر های پیشفرض رو هم تغییر دادین امکان پیکره بندی این ماژول وجود داره.
اطلاعات جمع آوری شده توسط filebeat به elasticsearch ingest node ارسال خواهد شد(به گره هایی که قبل از شاخص گذاری روی پرونده ها عملیات پیش پرازش رو انجام میدن ingest node گفته میشه) تا عملیات تجزیه و تحلیل قبل از شاخص گذاری در elasticsearch انجام بگیره.

تعدادی اصطلاح در elasticsearch وجود دارد که دانستن آنها در ابتدا به فرایند یادگیری بسیار کمک میکند.

 Near Realtime (NRT)

 elasticsearch یک بستر جستجوی نزدیک به زمان واقعی است، به این معنی که از زمان شاخص گذاری یک سند تا قابلیت جستجو در آن تاخیر کمی وجود دارد(معمولا یک ثانیه).

cluster

یک cluster مجموعه ای از یک یا چند node است(server) که با هم تمام اطلاعات را نگه داشته و شاخص گذاری و قابلیت جستجو را در بین تمام node فراهم میکنند.

node

یک node یک server تکی و قسمتی از cluster میباشد. که در ذخیره سازی داده های خود و شاخص گذای و فراهم کردن قابلیت جستجو شرکت میکند.

index

یک index مجموعه ای از document است که تا حدودی دارای ویژگی های مشابهی هستند، به عنوان مثال شما میتوانید یک index برای اطلاعات مشتریان، یک index از فهرست محصولات و یک index از اطلاعات سفارشات داشته باشید.

index به وسیله ی نام خود شناخته میشود، که باید حروف لاتین کوچک باشد. این نام در زمان شاخص گذاری، جستجو، ویرایش و حذف مورد استفاده قرار میگیرد.

در یک cluster تکی شما میتوانید هر چقدر index نیاز دارید تعریف کنید.