חשבתי על רעיון, ואשמח לדעת מה הבעיה בו (למה לא חשבו עליו קודם )
בSQL יש חסרון בולט לעומת NOSQL שכל JOIN צריך לחפש בטבלה נפרדת, ובביג דטה זה יוצר חיפושים מרובים. ואפילו אם הטבלאות מאונדקסות כהלכה מ"מ במליארדי שורות זה עלול להגיע להרבה חיפושים לכל טבלה (שורש ריבועי - ל256 עד 8 חיפושים, ל 1024 עד 10 חיפושים, וכידוע).
וכן הבעיה הזו בכל הוספה לטבלה בה יש אינדקס ייחודי - צריך לוודא שאין את הנתון הזה שוב בכל הטבלה וזה מחייב שוב חיפושים וכו' וכו'.
מצד שני ל NOSQL צריך לשכפל נתונים ולנפח את הדטא או להגביל את השליפה לצורה מתוכננת מראש, כך שלא יצטרכו לבצע JOIN.
וע"ז אני שואל אם יש מסד נתונים בו מחיקות הם דבר יותר נדיר, למה לא ליצור מסד נתונים יחסי, שקל לשלוף ממנו על ידי שאילתות SQL, אך המזהה שלו לא יהיה ניתן למחיקה. ובכל חיפוש על ידי מפתח זר או הוספה לאינדקס יהיה אפשר להגיע ישירות למיקום של השורה בלי לחפש אותה מתוך הנתונים הממוינים. - כמו HASH MAP.
ומה אם כן רוצים למחוק?
אפשר למחוק כפקודה עתידית. להשאיר את הערכי המזהים שצריך למחוק בטבלת מערכת עם שם הטבלה שנמחק ממנה, לכתוב שם כמה שורות מחוקות, ולעדכן את השדות של אותה שורה בערך ייחודי 'מחוק' / NULL רגיל.
ובכל שאילתת צבירה לבדוק גם בטבלת המערכת הזו כמה לא צריך לצבור.
ותמיד יעבור אספן אשפה לאט לאט על הטבלה ויעדכן בפועל את המזהים ללא המחיקה - יקטין אותם על ידי מיון בועות. (ויעדכן את טבלת המערכת הנ"ל). ובכל המפתחות הזרים ישנה לפי העדכון.
לדוגמה אם יש טבלה א בה מזהי השורות הם 1,2,3,4,5,6 ובטבלה ב יש שדה מפתח זר עם 1,3,2,5,5,4, ומחקתי מטבלה א את שורה 2:
שורה 2 לא תמחק מיד, ובטבלת המערכת נכתוב בשדה 'שם הטבלה' 'טבלה א' ובשדה 'ערך מזהה' 2.
במשך הזמן יעבור האספן אשפה על טבלת המערכת ימחק בפועל את שורה 2 וישנה את ערך המזהה בשורה 3 ל 2, ויעבור על כל שאר הטבלאות בהם יש מפתח זר וימחק את ההפניה למזהה 2. וישנה את ההפניה למזהה 3 שתהיה למזהה 2.
וכך לכל שאר המפתחות הזרים. ולכל המזהים הגבוהים מ - 3.
וכמובן במקרה ומוחקים בבת אחת הרבה שורות זה יעלה פחות עבודה ל GC. וא"כ אפשר להפעיל אותו רק מדי פעם או במחיקה מרובה.