بخش بزرگی از زندگی کاری من با این فرض گذشته است که «پایگاه داده» یعنی یک فایل Excel. از شمارش موجودی و پیگیری پروژهها گرفته تا بودجهبندی و حتی یک CRM دستساز که با conditional formatting و VLOOKUP ساخته بودم و بیدلیل هم به آن افتخار میکردم، همهچیز در Excel بود. دلیلش ساده بود: Excel سریع باز میشد، ویرایشش آسان بود و تقریباً همه کسانی که با آنها کار میکردم از قبل بلد بودند چطور از آن استفاده کنند.
اما یک روز رسید که همین فایلها زیر وزن خودشان خم شدند و دیگر روشن بود به یک پایگاه داده واقعی نیاز دارم. فقط یک آخرهفته برای تحقیق و مهاجرت زمان برد، اما همان کافی بود تا Postgres دقیقاً جای خالی را پر کند.
صفحهگستردهها بیسروصدا به پایگاه داده من تبدیل شدند
سالها رشد، محدودیتهای Excel را آشکار کرد
هیچکس از اول تصمیم نمیگیرد که از یک صفحهگسترده «بزرگتر» شود. یک روز از خواب بیدار نمیشوید که بگویید وقتش رسیده Excel را کنار بگذارم و سراغ ابزار دیگری بروم. این اتفاق آهسته رخ میدهد: یک فایل به سه زبانه تبدیل میشود، بعد به ده زبانه، بعد به یک فایل مادر که به چند فایل دیگر ارجاع میدهد. فرمولها به سلولهایی اشاره میکنند که سالها پیش حذف شدهاند. بعد هم یک نفر بهاشتباه یک فیلتر را دستکاری میکند و نیمی از سطرها ناپدید میشوند، بدون اینکه تا لحظه نیاز به یک خروجی جدی از این بهاصطلاح پایگاه داده، اصلاً متوجه شوید.
مشکل اصلی فقط خود خطاها نیست؛ مسئله این است که تقریباً همه سازوکارهای محافظتی Excel اختیاری هستند. میتوانید با data validation جلوی بخشی از اشتباهها را بگیرید و حتی با Power Pivot بین شیتها رابطه مدل کنید، اما واقعیت این است که کمتر کسی اینها را درست پیادهسازی میکند و هیچچیز هم مانع نمیشود بعداً همان قواعد را دور بزنید. در Excel چیزی شبیه foreign key که رابطه بین جدولها را بهصورت اجباری نگه دارد وجود ندارد. همهچیز به عادتهای دستی وابسته است و عادتها هم زیر فشار deadline بیشتر از چیزی که دوست دارید میشکنند.
Postgres مشکلهایی را حل کرد که Excel از پسشان برنمیآمد
این ابزار برای داده ساختیافته و قابلاعتماد ساخته شده است
نقطه شکست من زمانی بود که فهمیدم برای پاسخ دادن به یک سؤال که باید در ۳۰ ثانیه حل میشد، لازم است سه صفحهگسترده را با هم تطبیق دهم. بهجای چند لحظه، یک بعدازظهر کامل صرف VLOOKUP و copy-paste شد و در نهایت هم باز به جواب مطمئن نبودم. همین ناامیدی وادارم کرد راهحل واقعی پایگاه داده را جدی بگیرم و Postgres دقیقاً همان گزینه مناسب بود. راهاندازیاش سخت نیست، بهراحتی بهصورت یک سرویس containerized اجرا میشود و برای تحلیل هوشمند با LLMهای محلی هم بهسادگی قابلاتصال است.
با توجه به اینکه عادت دارم خیلی از سرویسها را در Docker اجرا کنم، بالا آوردن Postgres برایم جهش بزرگی نبود. فقط چند جزء پایه لازم دارید و یک Docker Compose file با named volume برای نگهداری پایدار دادهها کافی است تا در کمتر از ۱۰ دقیقه همهچیز بالا بیاید. ضمن اینکه قبلاً هم هنگام رفع مشکل memory در Claude تجربه کار با Postgres را داشتم.
همهچیز در یک آخرهفته جمع شد
مهاجرت از چیزی که انتظار داشتم آسانتر بود
فرایند مهاجرت کمی برنامهریزی میخواست، اما در عمل بهاندازهای که تصور میکردم سخت نبود. از شلوغترین فایل خودم شروع کردم؛ یک رهگیر مشتری و سفارش که با فرمولها سرِ پا مانده بود. بعد جدولهای واقعی را روی کاغذ درآوردم: customers، orders و payments. همین تمرین که بهجای ردیفهای تخت، با منطق جدولهای نرمالشده فکر کنم، نشان داد سالها چهقدر داده تکراری و ناسازگار را با خودم حمل کردهام. بعد یک Python script کوچک با pandas نوشتم تا فایل قدیمی را بخواند، تمیزش کند و همهچیز را با psycopg، محبوبترین Postgres adapter برای Python، داخل پایگاه داده بریزد.
این کار schema را با foreign key و constraintهای لازم سر جایش گذاشت. روز بعد عملاً نشستم و تماشا کردم که همین constraintها کاری را انجام میدهند که قبلاً باید دستی انجام میدادم. یک شرکت در شیت دوبار با همان email ثبت شده بود؛ بار دوم چند ماه بعد فقط با یک فاصله اضافه در انتهای نام که آن را جدید جلوه میداد. unique constraint روی email همانجا جلوی این تکرار را گرفت و نگذاشت نسخه دوم وارد شود. یک سفارش هم اصلاً تاریخ نداشت و non-null constraint آن را پس زد تا داده خراب وارد مجموعه نشود؛ هرچند مجبور شدم ورودی اصلی را پیدا کنم و اصلاحش کنم.
در موردی دیگر، یک ردیف به email مشتریای اشاره میکرد که اصلاً در فهرست وجود نداشت؛ همان نوع ورودی سرگردانی که VLOOKUP خیلی راحت در برابرش فقط یک خانه خالی برمیگرداند. foreign key در Postgres آن را کامل رد کرد. یک پرداخت هم بهجای عدد، عبارت “paid in full” را داخل ستون مبلغ داشت و Postgres تا زمانی که مقدار را اصلاح نکردم، حاضر نشد آن را بهعنوان currency ذخیره کند.
البته همه ستونهای بههمریخته به کشفهای دراماتیک ختم نشدند. مثلاً در ستون فاکتور من، مقادیری مثل yes، no، true و N کنار هم پخش بودند و boolean type در Postgres بیشترشان را بدون دردسر تفسیر کرد. constraintها جلوی داده بد را میگیرند، نه لزوماً قالببندی بد را.
مدیریت همهچیز سادهتر شد
داده تمیزتر، پرسوجوی سریعتر و خطای کمتر
تفاوت فقط در سرعت نیست، هرچند همین هم یک مزیت بزرگ است. سؤالی درباره صورتحساب مشتری که قبلاً در Excel یک بعدازظهر زمان میبرد، حالا به یک SQL query پنجخطی تبدیل شده و داشبورد Flash من همان لحظه بارگذاری صفحه جواب را نشان میدهد. دیگر لازم نیست حدس بزنم فرمولی اشتباه drag شده یا کسی روی یک مقدار overwrite انجام داده است. پایگاه داده قوانینی را اعمال میکند که قبلاً باید با حافظه و مراقبت شخصی حفظشان میکردم. هرجا هم نتواند، با صدای بلند خطا میدهد و وادارم میکند مسئله را قبل از بزرگ شدن اصلاح کنم.
مزیت مهم دیگر این است که حالا میتوانم واقعاً با دادههایم حرف بزنم. چند LLM محلی و Claude به همین پایگاه داده مشترک دسترسی دارند و در نتیجه در بسیاری از مواقع حتی لازم نیست خودم SQL بنویسم. کافی است از agentهای هوش مصنوعی بخواهم یک داده مشخص را برایم پیدا کنند. نسخههای پشتیبان هم حالا طبق برنامه اجرا میشوند، نه با این امید که شاید قبل از یک تغییر دائمی یادم مانده باشد یک کپی versioned ذخیره کنم.
Excel هنوز هم جای خودش را دارد
برای تحلیل عالی است، نه برای نگهداری بلندمدت
Excel بیفایده نیست و من هنوز هم برای بهاشتراکگذاری داده با کسانی که قرار نیست SQL query اجرا کنند از آن استفاده میکنم. اما بهعنوان system of record، هیچوقت برای کاری که از آن میخواستم ساخته نشده بود.
برای من، Postgres فقط جای یک ابزار را نگرفت؛ یک مدل ذهنی شکننده را کنار زد که مدتها با وصلهپینه سرِ پا نگهش داشته بودم. تنها حسرت من این است که چرا زودتر مهاجرت نکردم.
منبع: این مطلب یک بومیسازی و بازنویسی تحریریهای بر اساس مقالهای از MakeUseOf نوشته Yadullah Abidi است: مشاهده مقاله اصلی.