توسعه برنامه هایی که هرگز حذف نمی شوند

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

نرم افزار یک تجارت خنده دار است. به عنوان مثال، شما حساب A و حساب B دارید. شما از یکی برداشت می کنید و در داخل تراکنش به دیگری اضافه می کنید. با این تفاوت که حسابداری اینگونه نیست. احتمالاً باید این کار را به روش دیگری انجام دهید.

نوشتن یک برنامه پایگاه داده که هرگز به روز رسانی یا حذف نمی کند، نه تنها امکان پذیر است، بلکه اغلب عملی است. توسعه دهندگان برنامه های کاربردی اینترنت اشیا (اینترنت اشیا) این کار را همیشه انجام می دهند. دستگاه‌ها داده‌های سری زمانی، معمولاً اطلاعات وضعیت، را ارسال می‌کنند که در جدولی همراه با مهر زمانی قرار می‌گیرد. صرف نظر از اینکه از یک پایگاه داده سنتی مانند Oracle، یک پایگاه داده SQL توزیع شده جدیدتر مانند CockroachDB، Yugabyte، یا MariaDB Xpand یا حتی یک پایگاه داده NoSQL مانند MongoDB استفاده می کنید، روش اساساً یکسان است.

جدولی مانند این را در نظر بگیرید:

Customer {
  id BIGINT(0) UNSIGNED AUTO_UNIQUE NOT NULL,
  name_given TINYTEXT,
  name_middle TINYTEXT,
  name_family TINYTEXT,
  email [varchar] TINYTEXT,
  dob DATETIME
}

اگر مشتری ایمیل یا نام خانوادگی خود را تغییر دهد، به‌روزرسانی لازم است. با این حال، این به معنای گم شدن تاریخ است. به‌روزرسانی منطقی می‌تواند به عنوان حذف و درج در نظر گرفته شود. روش دیگر انجام آن چیزی شبیه به این خواهد بود:

Customer {
  entry_id BIGINT(0) UNSIGNED AUTO_UNIQUE NOT NULL,
  entry_date TIMESTAMP NOT NULL,
  id BIGINT(0) UNSIGNED NOT NULL,
  name_given TINYTEXT,
  name_middle TINYTEXT,
  name_family TINYTEXT,
  email [varchar] TINYTEXT,
  dob DATETIME
}

entry_id به کلید یکتا برای ردیف تبدیل می شود، اما id کلیدی است که آن شخص منحصر به فرد را شناسایی می کند. برای پیدا کردن نام و ایمیل فعلی شخصی، یک درخواست مانند:

صادر می کنید

select … from Customer where id=1 and entry_date = (select max(entry_date) from customer where id =1)

این جستجو آخرین ورودی را برای مشتری می‌کشد که در آن id برابر با ۱ است. برای تغییر ایمیل یا نام خانوادگی مشتری، کافی است یک ردیف جدید با id ۱ وارد کنید. و یک ردیف جدید (توجه: اگر id یک auto_unique است و یک دنباله نیست، max(entry_id) را انجام ندهید.)

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

موضوعات دیگری نیز وجود دارد که باید در نظر گرفته شوند. مشکل یافتن مشتریانی را که کالای خاصی برایشان ارسال شده است در نظر بگیرید. ممکن است جداول مشتری، سفارش، ارسال و Shipped_Item داشته باشید. با فرض اینکه فقط رکورد «جاری» را می‌خواهید و همه جداول نسخه‌بندی شده‌اند، در نهایت با حداقل سه سؤال فرعی مواجه می‌شوید. در عوض می‌توانید ساختار سنتی‌تری مانند تعریف اولین جدول مشتری داشته باشید، اما درج‌هایی را در هنگام حذف با یک جدول بایگانی صادر کنید:

Customer_Archive {
  archive_id BIGINT(0) UNSIGNED AUTO_UNIQUE NOT NULL,
  customer_id BIGINT(0) UNSIGNED NOT NULL,
  entry_date TIMESTAMP NOT NULL,
  name_given TINYTEXT,
  name_middle TINYTEXT,
  name_family TINYTEXT,
  email [varchar] TINYTEXT,
  dob DATETIME
}

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