فصل دوم: مدل‌های داده و زبان‌های پرس‌وجو

تا حالا به این فکر کرده‌اید که چرا وقتی می‌خواهید ساختار پیچیده‌ای مثل مشخصات یک کاربر را در پایگاه داده ذخیره کنید، گاهی کدهای برنامه‌نویسی شما پر از ترجمه‌های دست‌وپاگیر می‌شود؟ چطور انتخاب یک مدل داده می‌تواند تعیین کند که نوشتن کدام ویژگی نرم‌افزار آسان یا عذاب‌آور باشد؟ چه فرقی بین روش‌های مختلف سازماندهی اطلاعات در زیر پوست برنامه‌ها وجود دارد؟

در کتاب «طراحی برنامه‌های داده‌گرا» نوشتهٔ «مارتین کلپمن»، فصل دوم به بررسی مدل‌های داده و زبان‌های پرس‌وجو می‌پردازد تا ببینیم زیربنای انتخاب‌های ما در ذخیره‌سازی اطلاعات چیست.

اولین ایدهٔ کلیدی، مدل رابطه‌ای (Relational Model) در برابر مدل سندی (Document Model) است. مشکل اینجاست که برنامه‌های امروزی با شیءها کار می‌کنند، در حالی که پایگاه‌های دادهٔ سنتی اطلاعات را در جدول‌ها نگه می‌دارند و این فاصله به ناهمگونی شیء-رابطه‌ای (Impedance Mismatch) منجر می‌شود. گزینه‌های مختلفی مانند جدول‌های نرمال‌شده، داده‌های ساخت‌یافته درون ستون‌ها یا ذخیرهٔ جی‌سان وجود دارد که هرکدام تعادلی بین پیچیدگی کد و انعطاف ایجاد می‌کنند؛ مثلاً ذخیرهٔ مشخصات یک رزومه به شکل یک سند واحد جی‌سان، دسترسی به تمام اطلاعات را با یک پرس‌وجو ممکن می‌کند.

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

ایدهٔ سوم، مسئلهٔ طرح‌واره اسکیما (Schema) و انعطاف آن است. مشکل اینجاست که تغییر ساختار داده‌ها در پایگاه‌های داده می‌تواند وقت‌گیر باشد و به بازنویسی اطلاعات نیاز پیدا کند. گزینه‌های پیش رو بین مدل اسکیما-روی-نوشتن (Schema-on-Write) که ساختار را در زمان درج داده کنترل می‌کند و اسکیما-روی-خواند (Schema-on-read) که ساختار را در زمان خواندن تفسیر می‌کند متغیر است. برای مثال، پایگاه‌های دادهٔ سندی به شما اجازه می‌دهند بدون تغییر قبلی ساختار جدول، فیلد جدیدی را به برخی اسناد اضافه کنید و ناسازگاری‌ها را هنگام خواندن مدیریت کنید.

ایدهٔ چهارم، تفاوت زبان‌های پرس‌وجو است. مشکل اینجاست که دستورات دستوری به کامپیوتر می‌گویند چه عملیاتی را به چه ترتیبی انجام دهد، که نوشتن برنامه‌های موازی را دشوار می‌کند. گزینه‌های بهتری مثل زبان‌های پرس‌وجوی اعلامی (Declarative) وجود دارند که در آن‌ها فقط الگوی دادهٔ مورد نظر را توصیف می‌کنید. مثلاً در زبان اس‌کیوال (SQL) شما مشخص می‌کنید چه اطلاعاتی می‌خواهید و موتور پایگاه داده خودش تصمیم می‌گیرد از چه روشی برای سریع‌تر شدن کار استفاده کند.

ایدهٔ پنجم، مدل‌های مبتنی بر گراف برای داده‌های به‌شدت مرتبط است. مشکل اینجاست که وقتی همه‌چیز می‌تواند به همه‌چیز وصل باشد، مدل‌های جدول‌محور یا درختی ناکارآمد می‌شوند. گزینه‌هایی مانند گراف‌های ویژگی (Property Graphs) از رأس‌ها (Vertices) و یال‌ها (Edges) تشکیل شده‌اند تا ارتباط‌های پیچیده را به شکلی طبیعی ذخیره و پرس‌وجو کنند. برای مثال، پیدا کردن مسیر مهاجرت افراد از یک کشور به قاره‌ای دیگر در پایگاه‌های دادهٔ گرافی با زبان‌هایی مثل سایفر (Cypher) بسیار کوتاه‌تر و خواناتر از اس‌کیوال پیاده‌سازی می‌شود.

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

انتخاب درست مدل داده، مرز میان یک معماری نرم‌افزار تمیز و توسعه‌پذیر با کدهایی پر از وصله و پینه است که در نهایت سرنوشت محصول شما را رقم می‌زند.