این سؤال تقریباً در هر دموی مشکوکانهای که دادهام مطرح میشود. کسی میبیند یک سازندهی هوش مصنوعی در چند دقیقه یک اپلیکیشن کارآمد راه میاندازد و اولین سؤال جدیاش، بعد از اینکه شگفتیِ اولیهی «وای، چقدر سریع بود» فروکش کرد، نسخهای از این است: خب، ولی اینجا واقعاً پایگاهدادهای هست یا فقط جعلش کرده؟ سؤال منصفانهای است. اینها سؤالهایی هستند که، تقریباً به همان ترتیبی که شکاکیت آدمها با کندوکاو بیشتر تکامل مییابد، مطرح میشوند.
آیا واقعاً پایگاهداده وجود دارد یا دمو فقط با دادهی نمونه جعل شده؟
بله، پایگاهدادهی واقعی وجود دارد. آنچه تغییر میکند این است که کدام پایگاهداده، و درک آن تفاوت پیش از ساختن هر چیزی که قصد نگهداشتنش را دارید، ارزشمند است. یک سازندهی هوش مصنوعی برای نمونهی اولیه که هدفش «در نود ثانیه این کار را ببین» است، معمولاً سراغ SQLite میرود — یک فایل روی دیسک، بدون هیچ راهاندازی، کاملاً توانا برای اجرای یک اپلیکیشن واقعی برای یک کاربر. سازندهای که برای «باید ترافیک واقعی و چند مستأجر را تاب بیاورد» بهینه شده، سراغ Postgres میرود، چون مدل قفلگذاری فایل در SQLite همین که بیش از یک فرآیند بخواهد همزمان بنویسد، شروع به آسیبزدن میکند. بپرسید کدامیک را دریافت میکنید. این سؤالی کاملاً معقول برای پرسیدن از یک صفحهی فروش یا چت پشتیبانی است، و اگر کسی نتواند بهروشنی پاسخ دهد، خودش حرفی برای گفتن دارد.
واقعاً از چه موتور پایگاهدادهای استفاده میکند؟
در پلتفرمهایی که برای چیزی فراتر از یک ابزار سرگرمی ساخته شدهاند، Postgres. این پاسخ خستهکننده اما درست است، و خستهکننده بودن همان چیزی است که اینجا میخواهید. Postgres به شما امنیت در سطح ردیف میدهد تا ردیفهای مستأجر A حتی اگر کد اپلیکیشن باگ داشته باشد، برای پرسوجوهای مستأجر B نامرئی بمانند، بههمراه کلیدهای خارجی واقعی، تراکنشهای واقعی، و بیست سال تجربهی «کسی قبلاً به این حالت مرزی برخورده و رفعش کرده». حالت شکست جالبتوجه این نیست که «کدام گویش SQL» — بلکه سازندههایی هستند که برای سرعت روی SQLite شروع میکنند و هرگز با رشد کاربری از آن مهاجرت نمیکنند، چون مهاجرت یک پایگاهدادهی زنده با کاربران فعال کاری بیظرافت است که بهراحتی میشود همیشه به تعویق انداخت. اگر دارید یک سازنده را برای چیزی ارزیابی میکنید که قصد اجرایش برای سالها را دارید، بپرسید با رشد اپلیکیشن فراتر از یک کاربر، چه اتفاقی برای پایگاهداده میافتد. پاسخ صادقانه شامل یک مسیر مهاجرت است؛ پاسخ طفرهآمیز شامل تکرار کلمهی «مقیاسپذیر» بدون جزئیات است.
آیا میتوانم دادههای خودم را ببینم یا داخل یک جعبهی سیاه قفل شدهاند؟
باید بتوانید، نقطه. یک مرورگر جدول، یک کنسول پرسوجو، یک دکمهی خروجی گرفتن — راهی برای دیدن ردیفها بدون عبور از رابط کاربری خود اپلیکیشن. این کمتر یک سؤال فنی است و بیشتر یک سؤال اعتماد. سازندهی هوش مصنوعیای که طرحوارهای تولید میکند که نمیتوانید بازرسیاش کنید، از شما میخواهد به کدی اعتماد کنید که خودتان ننوشتهاید و نمیتوانید ممیزی کنید، که خواستهی بسیار بزرگتری نسبت به «به من اعتماد کن، دکمهی رابط کاربری کار میکند» است. ابزارهایی که این را درست انجام میدهند، دادهی زیرین را بهطور پیشفرض متعلق به شما میدانند، نه یک جزئیات پیادهسازی که دارند از شما محافظت میکنند.
وقتی ویژگی جدیدی درخواست میکنم، آیا تغییرات طرحواره را مدیریت میکند؟
اینجا واقعاً سخت میشود، و جایی است که بسیاری از سازندههای هوش مصنوعی بهآرامی کم میآورند. افزودن یک ستون کار سادهای است. افزودن یک ستون، پر کردن ردیفهای موجود با مقدار پیشفرض معقول، بهروزرسانی هر پرسوجویی که با آن جدول کار میکند، و انجام همهی اینها بدون از دست دادن دادههای موجود — این یک مایگریشن است، و مایگریشنها یکی از معدود جاهایی هستند که «هوش مصنوعی کدی نوشت که کامپایل میشود» با «هوش مصنوعی کدی نوشت که اجرایش روی دادههای تولیدی امن است» یکی نیست. سازندهای که ارزش استفاده دارد، تغییر طرحواره را بهعنوان یک مرحلهی قابلبررسیِ مستقل میبیند، نه چیزی که بهطور بیصدا داخل یک درخواست ویژگیِ بزرگتر بستهبندی شده. اگر درخواست «افزودن تاریخ سررسید به وظایف» بدهید و دیفی برگردد که فقط فرانتاند را لمس میکند، مشکوک شوید — پایگاهداده متوجه ماجرا نشده.
آیا روابط را درست مدلسازی میکند یا همهچیز داخل یک بلوک بزرگ JSON مسطح میشود؟
هر دو الگو وجود دارند، و اینکه کدامیک را میگیرید بیشتر از آنچه بیشتر افراد در ابتدا تصور میکنند اهمیت دارد. یک طرحوارهی رابطهای — جداول جداگانه برای کاربران، سفارشها و اقلام سفارش، که با کلیدهای خارجی به هم متصل شدهاند — به شما اجازه میدهد سؤالهایی بپرسید که رابط کاربری اولیهی اپلیکیشن هرگز پیشبینی نکرده بود: «کدام مشتریان X و Y را با هم خریدهاند»، «نرخ بازگشت وجه ما بر اساس دستهی محصول چقدر است». یک بلوک JSON غیرنرمالشدهی منفرد برای هر رکورد، تولیدش سریعتر است و برای یک اپلیکیشن واقعاً ساده مناسب است، اما هر درخواست آیندهی «فقط یک گزارش اضافه کن» را به یک بازطراحیِ کامل تبدیل میکند. بخواهید طرحواره را ببینید، نه فقط اپلیکیشن در حال اجرا. اگر هر جدول بهطور مشکوکی شبیه `{ id, data jsonb }` باشد، دارید با سازندهای طرف میشوید که برای نمایش سریع چیزی روی صفحه بهینه شده و مدلسازی واقعی داده را به تعویق انداخته.
| الگو | در چه چیزی خوب است | کجا خراب میشود |
|---|---|---|
| طرحوارهی رابطهای مناسب (جداول جداگانه، کلیدهای خارجی) | گزارشگیری، پیوندها (join)، یکپارچگی داده، ویژگیهای آیندهای که هنوز به آنها فکر نکردهاید | زمان تولید اولیهی کمی بیشتر؛ برای یک پرامپت ساده سختتر است که در همان بار اول دقیقاً درست از آب دربیاید |
| یک بلوک JSON منفرد برای هر رکورد | سرعت رسیدن به اولین دمو، اپلیکیشنهای تکموجودیتیِ ساده (یک ابزار یادداشتبرداری، یک فرم ساده) | هر پرسوجویی که چند رکورد را در برمیگیرد، هر رابطهای، هر گزارشی — همه به راهحلهای موقتی در کد اپلیکیشن تبدیل میشوند بهجای SQL |
| ترکیبی (فیلدهای اصلی در ستونها، اطلاعات انعطافپذیر اضافی در یک ستون jsonb) | اپلیکیشنهایی با شکل اصلیِ پایدار بههمراه فیلدهای سفارشیِ کاربر | نیازمند این است که سازنده بداند کِی از کدامیک استفاده کند — نسخهی بیدقت همهچیز را داخل ستون jsonb میریزد |
اگر از میزان دادهای که برایش ساخته شده بیشتر شوم چه اتفاقی میافتد؟
کاملاً به این بستگی دارد که آیا موتور زیرین از اول برای همزمانی ساخته شده یا نه. این همان سؤال SQLite در برابر Postgres است با ظاهری دیگر. اپلیکیشنی روی SQLite که چند صد ردیف را برای یک کاربر مدیریت میکند، دقیقاً مثل اپلیکیشنی روی Postgres با همان بار بهنظر میرسد — تفاوت فقط زمانی نمایان میشود که نویسندگان همزمان، تعداد ردیفهای بیشتر، یا پرسوجوهای تحلیلیای که از ایندکسگذاری و برنامهریزی پرسوجو سود میبرند، اضافه شوند. اگر اپلیکیشن شما واقعاً برای همیشه تککاربره و کمحجم است، ممکن است هرگز به این مشکل برنخورید. اگر دارید چیزی میسازید که امیدوارید مشتری داشته باشد، سؤال مقیاسپذیری را قبل از رسیدن به مشکل بپرسید، نه بعد از اینکه یک تیکت پشتیبانی جوابش را به شما یاد بدهد.
آیا دادهی من واقعاً از سایر کاربران روی یک پلتفرم مشترک جدا شده است؟
این همان سؤالی است که بیشترین اصرار را روی آن دارم، چون تا زمان شکست نامرئی است. پلتفرمهای چندمستأجریِ که دادهی همه را در یک پایگاهدادهی مشترک نگه میدارند، به یک مرز جداسازیِ واقعی نیاز دارند — سیاستهای امنیت سطح ردیف که توسط خود پایگاهداده اعمال میشود، نه فقط کد اپلیکیشنی که یادش میماند به هر پرسوجو یک شرط `WHERE user_id = ?` اضافه کند. این تفاوت اهمیت دارد چون جداسازی مبتنی بر کد اپلیکیشن بهآرامی شکست میخورد: یک فیلتر جامانده در یک اندپوینت و ناگهان مستأجر A میتواند ردیفهای مستأجر B را ببیند. جداسازی اعمالشده در پایگاهداده با صدا شکست میخورد، چون پرسوجو حتی اگر کد اپلیکیشن فیلتر را فراموش کرده باشد، چیزی برنمیگرداند. مشخصاً بپرسید که آیا جداسازی مستأجران در سطح پایگاهداده اعمال میشود یا به کد اپلیکیشن سپرده شده. بیشتر کسانی که میپرسند «آیا میتواند پایگاهدادهی واقعی را مدیریت کند»، در واقع دارند همین سؤال را میپرسند بدون اینکه هنوز واژگانش را بدانند.
آیا میتوانم همهچیز را خروجی بگیرم و اگر خواستم بروم؟
باید بتوانید یک خروجی کامل از دادههای واقعی خودتان بگیرید — نه یک اسکرینشات از اپلیکیشنتان، نه یک PDF از یک گزارش، بلکه ردیفهای زیرین در قالبی که بتوانید جای دیگری بارگذاری کنید. سازندهای که این کار را سخت میکند، دربارهی طرز فکرش نسبت به این رابطه چیزی به شما میگوید. نسخهی صادقانهی «سازندهی هوش مصنوعی» یعنی پلتفرم کد و طرحواره را از طرف شما تولید کرده؛ هرگز قرار نبود به این معنا باشد که بهمحض قرارگرفتن در جدولی که خودتان تهیه نکردهاید، داده مالکیتش را از دست بدهد.
پایگاهداده بخشی است که هیچکس دموی آن را نشان نمیدهد، و دقیقاً به همین دلیل بخشی است که ارزش پرسیدن دارد پیش از اینکه برای چیزی ثبتنام کنید.
هیچکدام از اینها مهندسیِ عجیبوغریب نیست. همان بررسیِ دقیقی است که برای هر تصمیم backend-as-a-service یا میزبانی اعمال میکنید — بخش هوش مصنوعی فقط این را آسان میکند که فراموش کنید بپرسید، چون دمو در پنهانکردن لولهکشی خیلی خوب است. بپرسید چه موتوری، بخواهید طرحواره را ببینید، دربارهی مایگریشنها بپرسید، دربارهی جداسازی بپرسید. اگر پاسخها مشخص باشند، احتمالاً وضعیت خوبی دارید.
