בנוסף,
תחשוב על פעולות עתידיות.
נניח ואתה רוצה לאפשר למשתמש לשלוט בחתימות. כלומר אילו יוצגו ואילו לא.
מה היית עושה?

אם היית משתמש בהפרדה ע"י פסיקים היית צריך ליצור עוד שדה שבו מופיעים כל השמות של החתימות שלא יופיעו.

לעומת זאת אם היית עובד נכון היית סה"כ מוסיף שדה שנקרא manage ושם בו 1 או 0 עבור כל חתימה.

באופן כללי אני לא רואה סיבה לוותר על גמישות הטבלה כל עוד אינדקסים לא נכנסים לתמונה. במקרה של החתימות, אני לא חוסך כמעט כלום אם אני מאחד את הכל בפסיקים ואני פוגע משמעותית ביעילות של שליפות בטבלה בהקשרים למשל של הפעלת לוגיקות מעניינות עליה (לדוגמה אם אני רוצה להחזיר את החתימה הנפוצה ביותר, למצוא קורלציה בין זוג חתימות ועוד). ד"א, במקרה כזה בגלל שהטבלה מלכתחילה מחזיקה fk ל-id של החתימות הרלוונטיות ו-fk ל-user היא תופסת פחות מקום בזיכרון מאשר עמודה עם פסיקים (במקרה הראשון אתה שומר 2 מצביעים עבור כל רשימה ובמקרה השני אתה משרשר ", id" ל-string שזאת פעולה כבדה יותר). במקרה הזה אתה לא מרוויח כלום.

כאשר היחס בין הישויות הוא many to many, מממשים פתרון של many to many ובמקרה שלא, אז לא. גם הפתרון של one to many הוא מאד דומה.

בד"כ היחס הזה ממומש באמצעות טבלת הצמדה בין זוג עמודות שמקיים יחס many to many. במקרים מסוימים אפשר לעשות משהו שהוא מעט יותר יעיל, לדוגמה יש לנו טבלה של קבצים ולכל קובץ יש מספר דגלים (למשל READ ONLY, HIDDEN, ENCRYPTED). היחס הוא many-to-many כי לכל קובץ יכולים להיות מותאמים מספר דגלים ומן הסתם לכל דגל יכולים להיות המון קבצים שהוא דולק בהם. נניח שמעניין אותנו להחזיק לכל קובץ איזה דגלים יש בו (וכך להבחין בין קובץ שהוא רק HIDDEN לקובץ שהוא למשל READ ONLY ו-ENCRYPTED), ז"א לממש יחס של one to many בהקשר של קבצים. במקרה הזה אני יכול לייצג באמצעות ביטים אילו דגלים דולקים לקובץ, נניח הביט השמאלי יהיה אינדיקטור האם הקובץ הוא HIDDEN והביט אחריו יהיה אינדיקטור האם הקובץ הוא READ ONLY. בסופו של דבר יהיה לי מספר שייצג בצורה בינארית את הביטים הדולגים, וכדי לעדכן ערכים בקובץ אני אבצע פעולה של XOR.