Database Design, SQL vs NoSQL, עיצוב מסד נתונים

ההחלטה שהכי קשה לשנות בכל מערכת

ב-2012, Digg.com ביצעה migration מ-MySQL ל-Cassandra. שנתיים של עבודה, בעיות ב-production, ובסוף, חזרה ל-MySQL. ב-2022, סטארטאפ ישראלי בתחום ה-HR-tech התחיל ב-MongoDB כי "זה גמיש", וגילה אחרי 18 חודש שהוא צריך transactions ו-joins לדוחות תשלומים. ה-migration לקח רבעון שלם. הבחירה ב-database היא אחת ההחלטות הארכיטקטוניות הקשות ביותר לשנות בדיעבד, ו-Claude עוזר לבחור נכון מההתחלה.

עיקרון בסיסי: אין database אחד שמתאים לכל use case. הבחירה תלויה בשלושה ממדים, מודל הנתונים, query patterns, ו-consistency requirements. כל שאר השיקולים (ecosystem, familiarity, cost) הם secondary. ב-2026 הגבול בין SQL ל-NoSQL מיטשטש: PostgreSQL תומך ב-JSONB מלא, ו-MongoDB תומך ב-ACID multi-document transactions. אבל ה-trade-offs עדיין קיימים, וצריך להבין אותם.

Framework להחלטה: 4 שאלות קריטיות

שאלה	SQL מנצח	NoSQL מנצח
מודל נתונים	Relational, joins מורכבים	Document, key-value, graph, time-series
Consistency	ACID transactions קריטי	Eventual consistency מספיק
Scale	עד ~100M rows, vertical scaling	מיליארדי rows, linear horizontal scaling
Query flexibility	Ad-hoc queries, aggregations	Access patterns ידועים מראש

פרומפט לבחירת DB, DB Selection Framework

הפרומפט הזה מייצר decision tree מותאם אישית לכל מערכת. הגישה: לתאר כמה components שונים ולבקש המלצה נפרדת לכל אחד, כך Claude מדגים שהתשובה שונה לכל חלק במערכת.

מה עדיף SQL או NoSQL לאפליקציה שלי?

I am building an Israeli B2B SaaS (project management for construction companies). Help me choose the right database for each component: 1. User accounts and permissions, strong consistency required, 50K users 2. Project activity feed, write-heavy, read by project/user, last 30 days 3. Document attachments metadata, flexible schema, variable fields per file type 4. Audit logs, regulatory retention 7 years, write-heavy, queries by date range For each: recommend the database, explain the reasoning, name one alternative and why it loses.

שימו לב ל-"name one alternative and why it loses", שורה אחת שמכריחה את Claude לנמק ולא רק לרשום אפשרויות. זה בדיוק סגנון ה-reasoning שמראיין system design מחפש.

JSONB ב-PostgreSQL, כלי עוצמתי, לא פתרון לכל דבר

JSONB הוא אחד הפיצ'רים הכי מנוצלים לרעה ב-PostgreSQL. הוא מצוין לשדות semi-structured, הגדרות משתמש, event payloads, attributes גמישים. אבל כשמשתמשים בו ל-core entities, מאבדים type safety, constraint enforcement, ואפשרות ל-query optimization.

הממצא המפתיע מהמחקר: PostgreSQL לא שומר statistics על ערכים בתוך JSONB columns, מה שיכול לגרום לquery planner לבחור seq scan במקום index scan, ולהאט queries פי 2,000 בתנאים מסוימים (Heap.io, 2024). המדיניות הנכונה: שדות שחוזרים ב-queries תכופים, column מפורש. שדות גמישים שמשתנים לעיתים רחוקות, JSONB.

כן ל-JSONB: products.attributes, events.payload, users.preferences, configuration objects
לא ל-JSONB: customer_id, order_total, created_at, כל שדה שמופיע ב-WHERE clause תכוף
GIN index: כשמשתמשים ב-JSONB, תמיד להוסיף GIN index על columns שנשאלים, ללא זה הביצועים מאוד גרועים

מתי Cassandra ומתי Redis, שתי קטגוריות שונות

שני ה-NoSQL הנפוצים ביותר פותרים בעיות שונות לחלוטין:

Cassandra / ScyllaDB: write-heavy time-series data בscale גדול. IoT sensor data מ-10,000 מכשירים, application event logs, click streams, financial tick data. הסיבה: LSM-tree architecture, כתיבות מהירות מאוד, linear horizontal scaling. אבל: reads מורכבים עם joins לא אפשריים, access patterns חייבים להיות ידועים מראש.
Redis: caching, session storage, real-time leaderboards, pub/sub, rate limiting. זה לא "database ראשי", זה שכבת acceleration. כמעט כל מערכת production צריכה Redis בצד ה-database הראשי.

Polyglot persistence, שימוש בכמה databases יחד, הוא הנורמה ב-2025. PostgreSQL לconsistency, Redis לcaching, Cassandra ל-event data, pgvector לsemantic search. Claude עוזר לתכנן את הארכיטקטורה המשולבת.

טעויות נפוצות בבחירת DB

"MongoDB כי זה גמיש": גמישות schema היא יתרון רק בשלב early. ברגע שיש לוגיקה עסקית, consistency requirements גדלים, ו-joins הופכים הכרחיים. Stack Overflow Developer Survey 2025: PostgreSQL ב-45% מהדוולפרים, MongoDB ב-25%, הפער מספר סיפור.
לשכוח Zero-Downtime Migrations: הוספת column ל-טבלה עם 50M rows ב-production תגרום ל-table lock שיפיל את ה-site. תמיד לשאול Claude: "How do I add this column without downtime?", התשובה כוללת pg_repack, shadow tables, ו-lazy backfill.
לבחור לפי trend ולא לפי use case: כל ה-DBs מוסיפים vector capabilities בגלל ה-AI wave, זה לא אומר שצריך לעבור לחדש. pgvector על PostgreSQL קיים מספק לרוב ה-use cases של GenAI לסטארטאפ.

MongoDB, כי הוא גמיש ומהיר לפתח

PostgreSQL, ACID קריטי לנתונים פיננסיים, queries מורכבים עם joins

Cassandra, כי יש הרבה עובדים ונתונים

Redis, כי צריך ביצועים גבוהים

JSONB תופס פי 2 storage מ-columns רגילים

אין type safety, constraints לא אפשריים, ו-query planner לא יכול לבצע אופטימיזציה

לא ניתן להוסיף indexes על JSONB

לא ניתן לאחסן arrays ב-JSONB

שימוש ב-ORM שתומך בכמה שפות תכנות

הפעלת כמה instances של אותו NoSQL database במקביל

שימוש בכמה סוגי databases במקביל, כל אחד למה שהוא טוב בו

פגיעה מכוונת ב-performance כדי לתמוך בהרבה לקוחות

פרומפט לעיצוב Schema, B2B SaaS ישראלי

הפרומפט הזה מדגים את הגישה שמפתחים מנוסים משתמשים בה: לא לשאול "מה ה-schema הנכון" אלא לתת requirements ספציפיים ולבקש DDL מלא עם נימוק לכל החלטה.

Design a PostgreSQL schema for a B2B construction management tool
(used by Israeli construction companies, Electra, Shapir, Shikun u'Binui).

Entities: Companies, Projects, Tasks, Workers, Equipment, Timesheets, Safety Incidents

Requirements:
1. Multi-tenant: strict data isolation between companies
2. Flexible task attributes: each project type has custom fields
3. Worker activity: who worked on what, hours, location, queried by worker/project/date
4. Regulatory: safety incidents require 10-year retention, tamper-proof
5. Real-time dashboard: open tasks per project, overdue items

For each table:
- Show the DDL (CREATE TABLE)
- Normalization decision: why normalized vs denormalized
- Required indexes for the query patterns above
- N+1 query risks to watch

Also flag: where would Redis caching help, and where would JSONB be appropriate?

נקודות מפתח לסיכום

PostgreSQL כ-default: לרוב ה-CRUD applications, PostgreSQL עם tuning נכון מספיק גם לעשרות מיליוני rows, אל תעברו ל-NoSQL לפני שתוכיחו שנחוץ.
Redis תמיד בצד: כמעט כל production system צריך Redis לcaching ו-sessions, זה לא "תוסף" אלא חלק בסיסי מהארכיטקטורה.
Cassandra לtime-series גדול: מעל מיליוני events ביום עם write-heavy patterns, Cassandra / ScyllaDB הוא הבחירה הנכונה.
תכנן migrations מראש: כל שינוי schema ב-production עם traffic דורש תכנון. Claude יכול לעזור לתכנן Zero-Downtime migration לכל שינוי.
Vector DB בעידן AI: אם המערכת כוללת semantic search, pgvector על PostgreSQL הוא נקודת התחלה סבירה לפני שמחליטים על Pinecone / Weaviate נפרד.