Postgres چیست؟ پایگاه داده پشت بسیاری از اپ‌ها توضیح داده شده
Postgres (به‌طور رسمی PostgreSQL) یک پایگاه داده رابطه‌ای رایگان و متن‌باز است: برنامه‌ای که داده‌های اپ را در جدول‌هایی از سطر و ستون ذخیره می‌کند، جدول‌ها را به هم وصل می‌کند و با زبانی به نام SQL درباره آن‌ها سؤال جواب می‌دهد. به قابل‌اعتماد بودن، سخت‌گیری در درست نگه داشتن داده و انعطاف‌پذیری برای کارهایی از فهرست ثبت‌نام ساده تا رکوردهای بزرگ یک شرکت شناخته می‌شود. بسیاری از اپ‌های وب و بسیاری از سرویس‌هایی که آن‌ها را میزبانی می‌کنند روی آن ساخته شده‌اند.
چرا وقتی با هوش مصنوعی می‌سازید اهمیت دارد
وقتی یک ابزار ساخت اپ با هوش مصنوعی «یک پایگاه داده» به پروژه‌تان اضافه می‌کند، احتمال زیادی وجود دارد که Postgres باشد. برای استفاده از آن لازم نیست SQL بنویسید، اما کمی درک آن خیلی کمک می‌کند:
- می‌توانید داده را به شکلی که پایگاه داده لازم دارد توصیف کنید. «مشتری‌ها سفارش‌های زیادی دارند؛ هر سفارش آیتم‌های زیادی دارد» مستقیم به جدول تبدیل می‌شود.
- می‌توانید محافظت‌های درست را بخواهید. Postgres می‌تواند داده بد را خودش رد کند، مثل ایمیل تکراری یا سفارشی برای مشتری‌ای که وجود ندارد، اگر هوش مصنوعی قواعد را تنظیم کرده باشد.
- می‌توانید کاری را که هوش مصنوعی کرده بخوانید. نام جدول‌ها، ستون‌ها و روابط در یک نمایشگر جدول به راحتی قابل بررسی است، حتی اگر هرگز به کد دست نزنید.
یک مثال روزمره: یک دفتر بایگانی بسیار سخت‌گیر
یک دفتر بایگانی را تصور کنید با یک کابینت برای هر نوع چیز: یکی برای مشتری‌ها، یکی برای سفارش‌ها، یکی برای محصولات. هر کارت در یک کشو فرم چاپی یکسانی دارد که باید پر شود. هر کارت شماره یکتایی دارد، و کارت سفارش مشخصات مشتری را تکرار نمی‌کند؛ فقط می‌گوید «مشتری شماره ۲۱۴»، که به کشوی مشتری‌ها اشاره می‌کند.
کارمند بایگانی سخت‌گیر است. سفارشی را که به مشتری‌ای اشاره می‌کند که وجود ندارد بایگانی نمی‌کند. کارتی را که خانه تاریخ اجباری‌اش خالی است قبول نمی‌کند. و اگر از او بخواهید پولی را از یک حساب به حساب دیگر منتقل کند، یا هر دو نیمه کار را انجام می‌دهد یا هیچ‌کدام را، و هرگز فقط یکی را.
آن کارمند Postgres است. کشوها جدول‌ها هستند، خانه‌های فرم ستون‌ها، هر کارت یک سطر است، و پیوند «مشتری شماره ۲۱۴» یک کلید خارجی (foreign key) است.
آنچه Postgres در آن خوب است
| امکان | معنی ساده |
|---|---|
| جدول‌ها و روابط | داده در جدول‌هایی زندگی می‌کند که به هم اشاره می‌کنند، پس هیچ چیزی در پنج جا کپی نمی‌شود |
| SQL | زبان استاندارد برای پرسیدن سؤال: «همه سفارش‌های پرداخت‌نشده ماه گذشته، جدیدترین اول» |
| تراکنش‌ها (ACID) | گروهی از تغییرات یا همه با هم انجام می‌شوند یا هیچ‌کدام، حتی اگر سرور وسط کار خراب شود |
| محدودیت‌ها (constraints) | قواعدی که پایگاه داده خودش اعمال می‌کند: فیلدهای اجباری، ایمیل یکتا، پیوندهای معتبر بین جدول‌ها |
| ایندکس‌ها | میان‌برهای جستجو تا جستجوها با رشد جدول‌ها سریع بمانند |
| JSONB | ذخیره داده انعطاف‌پذیر و سندمانند در یک ستون وقتی ساختار ثابت جا نمی‌شود |
| جستجوی تمام‌متن | جستجوی کلمات در فیلدهای متنی بدون یک سرویس جستجوی جداگانه، برای موارد ساده |
| افزونه‌ها | افزودنی‌هایی مثل PostGIS برای نقشه و موقعیت، یا pgvector برای ذخیره embeddingهای هوش مصنوعی |
| امنیت سطح سطر (Row-level security) | قواعد درون پایگاه داده درباره اینکه یک کاربر مشخص اجازه دیدن کدام سطرها را دارد |
Postgres به‌صورت یک پروژه پژوهشی در دانشگاه کالیفرنیا، برکلی، در دهه ۱۹۸۰ آغاز شد و از دهه ۱۹۹۰ به‌صورت باز توسط یک جامعه جهانی توسعه یافته است. همین سابقه طولانی دلیلی است که اغلب انتخاب پیش‌فرض است: مستندات خوب، پشتیبانی گسترده، و هر ارائه‌دهنده بزرگ ابری نسخه مدیریت‌شده‌ای از آن دارد.
یک مثال کامل: تبدیل یک اسپردشیت به جدول
فرض کنید یک کسب‌وکار کوچک کیترینگ دارید و همه چیز را در یک اسپردشیت پیگیری می‌کنید: هر سطر یک رویداد است، با نام، تلفن و ایمیل مشتری، تاریخ، آیتم‌های منو و قیمت.
مشکلات سریع پیدا می‌شوند. همان مشتری در شش سطر با دو شماره تلفن متفاوت آمده است. آیتم‌های منو در یک خانه با عنوان «canapés x40, salad x2» تایپ شده‌اند، پس نمی‌توانید تعداد canapéهای ماه را جمع بزنید.
در Postgres همین اطلاعات به چهار جدول تبدیل می‌شود:
| جدول | ستون‌ها | توضیح |
|---|---|---|
| clients | id، name، phone، email | ایمیل باید یکتا باشد |
| events | id، client_id، date، venue، status | client_id باید به یک مشتری واقعی اشاره کند |
| menu_items | id، name، unit_price | یک سطر برای هر غذا |
| event_items | event_id، menu_item_id، quantity | رویدادها را به غذاها با تعداد وصل می‌کند |
حالا شماره تلفن یک مشتری در یک جا زندگی می‌کند. «در مارس چند canapé درست کردیم؟» یک کوئری SQL است. و وقتی یک رویداد جدید را با آیتم‌هایش ثبت می‌کنید، یک تراکنش تضمین می‌کند که هرگز رویدادی با نیمی از آیتم‌هایش ذخیره‌نشده نداشته باشید.
این همان مرحله‌ای است که مردم وقتی از هوش مصنوعی می‌خواهند «از اسپردشیتم یک اپ بساز» جا می‌اندازند. راهنمای تبدیل اسپردشیت به اپ فراتر می‌رود.
اصطلاحات کلیدی
- جدول، سطر، ستون: یک نوع چیز، یک نمونه از آن، یک بخش اطلاعات درباره آن.
- کلید اصلی (Primary key): شناسه یکتای هر سطر، معمولاً
id. - کلید خارجی (Foreign key): ستونی که به سطری در جدول دیگر اشاره می‌کند، مثل
client_id. - طرح (Schema): طراحی همه جدول‌ها و ستون‌های شما.
- مهاجرت (Migration): یک تغییر ذخیره‌شده و قابل تکرار در طرح، مثل «اضافه کردن ستون
venueبه events». - کوئری (Query): یک سؤال یا دستور نوشته‌شده به SQL.
- رشته اتصال (Connection string): نشانی و رمز عبوری که بک‌اند شما برای رسیدن به پایگاه داده استفاده می‌کند. یک رمز است؛ ببینید متغیرهای محیطی و رمزها.
- Managed Postgres: سرویسی که Postgres را برای شما اجرا، پشتیبان‌گیری و به‌روزرسانی می‌کند.
برای عملیات روزمره‌ای که هر اپ روی این جدول‌ها انجام می‌دهد — ساختن، خواندن، به‌روزرسانی، حذف — ببینید CRUD یعنی چه.
اشتباه‌ها و تصورات غلط رایج
- یک جدول غول‌پیکر. کپی‌کردن ستون‌به‌ستون اسپردشیت به همان مشکلات تکرار منجر می‌شود. چیزهایی را که تکرار می‌شوند به جدول‌های خودشان ببرید.
- ذخیره فهرست‌ها در یک فیلد متنی. «canapés x40, salad x2» در یک ستون را نمی‌توان درست شمرد یا جستجو کرد. از یک جدول پیوندی استفاده کنید.
- نبودن محدودیت. بدون «ایمیل باید یکتا باشد» یا «هر رویداد به یک مشتری نیاز دارد»، داده بد بی‌صدا وارد می‌شود و ماه‌ها بعد ظاهر می‌شود.
- تغییر دستی پایگاه داده در محیط تولید. تغییرات طرح را به‌صورت مهاجرت بخواهید، تا تغییر ثبت شود و بشود تکرارش کرد.
- اجازه دادن به مرورگر برای صحبت مستقیم با پایگاه داده. فرانت‌اند باید از بک‌اند رد شود، که دسترسی‌ها را بررسی می‌کند. رمز پایگاه داده هرگز نباید در کد صفحه باشد.
- «Postgres فقط برای شرکت‌های بزرگ است.» برای یک فهرست ۵۰ سطری هم به همان خوبی اجرا می‌شود، و با رشد لازم نیست از آن جدا شوید.
- فرض اینکه پایگاه داده بک‌آپ است. پایگاه داده داده را ذخیره می‌کند؛ خودکار شما را از حذف شدن داده محافظت نمی‌کند. بررسی کنید میزبانتان چه بک‌آپی ارائه می‌دهد.
از ابزار ساخت با هوش مصنوعی‌تان چه بخواهید
- «[چیزها] را در یک پایگاه داده ذخیره کن. جدول‌ها: … با این فیلدها: … هر [سفارش] را به یک [مشتری] وصل کن.»
- «ایمیل مشتری‌ها را یکتا کن. این فیلدها را اجباری کن. سفارش بدون مشتری را نپذیر.»
- «برای هر تغییر طرح از مهاجرت استفاده کن.»
- «ایندکس برای جستجوهایی که بیشتر انجام می‌دهیم اضافه کن: سفارش‌ها بر اساس مشتری و تاریخ.»
- «همه دسترسی به پایگاه داده از طریق سرور باشد. رشته اتصال را در متغیرهای محیطی نگه دار.»
اگر اصلاً با ایده پایگاه داده تازه‌اید، با پایگاه داده چیست شروع کنید و سپس برگردید. یک اپ full-stack نشان می‌دهد پایگاه داده کنار فرانت‌اند و بک‌اند کجا قرار می‌گیرد.
Postgres در Mythex
Mythex به هر پروژه‌ای که به آن نیاز دارد یک پایگاه داده Postgres اختصاصی می‌دهد. لازم نیست آن را پیکربندی کنید: در چت بپرسید («ایمیل‌های فهرست انتظار را در یک پایگاه داده ذخیره کن») یا از دستور /database استفاده کنید، و Mythex آن را وصل می‌کند، اطلاعات اتصال را به اپ شما تزریق می‌کند و می‌تواند جدول‌ها را برایتان بسازد. پایگاه داده یک اپ منتشرشده بعد از پنج دقیقه بیکاری به خواب می‌رود و با درخواست بعدی بیدار می‌شود، و فقط زمانی که واقعاً بیدار بوده هزینه می‌شود، از همان موجودی اعتباری که برای ساختن استفاده می‌کنید. جزئیات در مستندات پایگاه داده است، و برای دیدن اپ‌هایی که با داده کار می‌کنند، قالب‌های داشبورد مکان خوبی است.
پرسش‌ها
آیا Postgres همان PostgreSQL است؟
بله. PostgreSQL نام رسمی است و Postgres نام کوتاه رایج آن است؛ هر دو به همان پایگاه داده رابطه‌ای متن‌باز اشاره دارند.
آیا Postgres رایگان است؟
بله. PostgreSQL تحت مجوز PostgreSQL License، که بسیار آزادانه است، متن‌باز است و می‌توانید آن را رایگان استفاده کنید، از جمله در محصولات تجاری. فقط برای سرورهایی که آن را اجرا می‌کنند یا سرویس مدیریت‌شده‌ای که از آن استفاده می‌کنید پول می‌دهید.
تفاوت Postgres و MySQL چیست؟
هر دو پایگاه داده SQL رابطه‌ای و رایگان‌اند و برای بیشتر اپ‌ها مناسب‌اند. Postgres به یکپارچگی داده سخت‌گیرانه، انواع داده غنی مثل JSONB و آرایه‌ها، و اکوسیستم بزرگ افزونه‌ها شناخته می‌شود؛ MySQL به سادگی و سابقه طولانی در میزبانی وب معروف است.
آیا Postgres برای یک اپ کوچک خوب است؟
بله. هم برای یک فهرست انتظار تک‌جدولی خوب کار می‌کند و هم برای سیستم‌های بزرگ تولیدی، پس با رشد اپ لازم نیست پایگاه داده را عوض کنید. سرویس‌های مدیریت‌شده اجرای آن را بدون مدیر پایگاه داده آسان می‌کنند.