פיתוח קטלוג מוצרים: EAV, SEO, וריאנטים וקישוריות

כשלקוחות מגיעים אלינו עם קטלוג איטי, פילטרים שלוקח דקות להיטען, וירידה בתנועת SEO עקב דפים כפולים, הסיבה השורשית היא לרוב ארכיטקטורה לקויה: מודל קטגוריות שגוי, פגינציה לא יעילה, או חוסר בקאשינג. פיתוח קטלוג מוצרים הוא המשימה המרכזית עבור חנות איקומרס, וביצוע נכון שלו יכול לחסוך עד 40% מתקציב התמיכה (הפחתת עלויות תשתית עד 300,000 רובל בשנה). סטטיסטיקות מראות ש-70% מהמשתמשים עוזבים את האתר אם הקטלוג נטען יותר מ-3 שניות, וקטלוג מעוצב היטב יכול להעלות את שיעור ההמרה ב-20%. עם 8 שנות ניסיון בפיתוח קטלוגים ויותר מ-50 פרויקטים לחנויות עם 10,000+ מבקרים יומיים, אנחנו יודעים מה עובד.

הקטלוג הוא מודול הליבה של אתר איקומרס. הארכיטקטורה שלו קובעת את מהירות החיפוש, קלות הניווט ותנועת ה-SEO. טעויות כאן הן היקרות ביותר, ודורשות מיגרציה של נתונים ועיבוד מחדש של מודולים תלויים. קטלוג מוצרים מתוכנן כראוי מתמודד עם עד 500,000 פריטים ללא פגיעה בביצועים.

איזה מודל קטגוריות לבחור?

עץ הקטגוריות מאוחסן במסד הנתונים. שתי גישות נפוצות:

רשימת שכנים (Adjacency List) – כל רשומה מאחסנת parent_id. כתיבה פשוטה, אבל קריאת העץ המלא דורשת CTE רקורסיבי:

WITH RECURSIVE category_tree AS (
    SELECT id, name, parent_id, 0 AS depth
    FROM categories
    WHERE parent_id IS NULL
    UNION ALL
    SELECT c.id, c.name, c.parent_id, ct.depth + 1
    FROM categories c
    JOIN category_tree ct ON c.parent_id = ct.id
)
SELECT * FROM category_tree
ORDER BY depth, name;

קבוצות מקוננות (MPTT) – כל רשומה מאחסנת ערכי WITH RECURSIVE category_tree AS ( SELECT id, name, parent_id, 0 AS depth FROM categories WHERE parent_id IS NULL UNION ALL SELECT c.id, c.name, c.parent_id, ct.depth + 1 FROM categories c JOIN category_tree ct ON c.parent_id = ct.id ) SELECT * FROM category_tree ORDER BY depth, name; ו-lft. שאילתת תת-עץ: rgt – שאילתה אחת, ללא רקורסיה. הכתיבה מורכבת יותר: הוספת צומת מעדכנת את כל האחים הימניים.

טבלת סגירה (Closure Table) – טבלה נפרדת עם כל זוגות האב–צאצא. הגמישה ביותר, דורשת יותר אחסון. אופטימלית לפעולות עץ מורכבות (העברת תתי-עץ).

ההמלצה שלנו: עבור קטלוגים עד 10,000 קטגוריות, רשימת שכנים עם קאשינג של עץ ב-Redis מספיקה. MPTT כאשר שאילתות תת-עץ תכופות ואין שימוש בקאש.

כיצד ליישם מאפייני מוצר בצורה נכונה?

מוצרים בקטגוריות שונות כוללים קבוצות מאפיינים שונות. שלוש גישות:

• טבלת עמודות קבועות: WHERE lft BETWEEN :parent_lft AND :parent_rgt, kalnoy/nestedset, products.color. עובד רק עם מבחר הומוגני. הוספת מאפיין חדש דורשת ALTER TABLE, מיגרציה ופריסה.
• EAV (ישות-מאפיין-ערך): גמיש אבל איטי עם JOINs. לצורך פילטור, יש צורך ב-Elasticsearch או אינדקס דה-נורמליזציה.
• עמודת JSONB ב-PostgreSQL:

ALTER TABLE products ADD COLUMN attributes JSONB; CREATE INDEX ON products USING GIN (attributes); 

פשרה: גמישות של EAV ללא JOINs מיותרים. כפי שמתועד בתיעוד PostgreSQL, עמודות JSONB מספקות גמישות EAV ללא טבלאות נוספות. מתאים לקטלוגים עד 500,000 מוצרים.

וריאנטים של מוצר: הורה-צאצא

מוצרים עם וריאנטים (צבע × מידה) נפוצים. שני תבניות:

• SKU פשוט: כל שילוב הוא רשומה נפרדת ב-products.size. פשוט אבל קשה לניהול כרטיס הורה.
• הורה-צאצא: מוצר הורה מסוג 'משתנה' וצאצא 'וריאנט' עם שילובי מאפיינים ספציפיים.

products (id, type, parent_id, sku, name, price, stock)
-- type: 'simple' | 'variable' | 'variant'
-- variant: parent_id → variable product

בעת הצגת כרטיס המוצר, טען הורה + כל הווריאנטים. המשתמש בוחר שילוב מאפיינים → מצא את הווריאנט המתאים → עדכן מחיר, תמונה, מלאי. עבור מטריצת הווריאנטים, השתמש באובייקט עם אינדקס לפי מזהה מאפיין.

מבנה URL ו-SEO

כתובות URL של קטגוריות הן קריטיות ל-SEO. שלוש אפשרויות:

• שטוח: products.weight – פשוט, מאבד הקשר היררכי.
• היררכי: ALTER TABLE products ADD COLUMN attributes JSONB; CREATE INDEX ON products USING GIN (attributes); – טוב יותר ל-SEO, קשה יותר כאשר קטגוריה מועברת.
• היברידי: products – slug קריא + מזהה ייחודי (עמיד בפני שינויי שמות).

עבור דפי פילטור: products (id, type, parent_id, sku, name, price, stock) -- type: 'simple' | 'variable' | 'variant' -- variant: parent_id → variable product עם canonical ל-/catalog/noutbuki או דפי SEO נפרדים לשילובים פופולריים (/catalog/elektronika/kompyutery/noutbuki כאגרגטור סטטי). Schema.org: /noutbuki-c142 בדפי קטגוריה עם /noutbuki?brand=apple&ram=16 עבור כל מוצר ברשימה.

פגינציה וגלילה אינסופית

פגינציה מסוג Offset: /noutbuki. עובד, אבל בדפים עמוקים (/noutbuki-apple-16gb) PostgreSQL עדיין קורא 10048 שורות. פתרון – פגינציה מסוג Keyset:

SELECT * FROM products WHERE (sort_value, id) > (:last_sort_value, :last_id) ORDER BY sort_value, id LIMIT 48; 

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

למובייל – גלילה אינסופית עם ItemList, לדסקטופ עם עדיפות SEO – פגינציה קלאסית (מנועי חיפוש ממקדים טוב יותר דפים עם מספרים מפורשים).

ניהול קטלוג ב-CMS

ממשק ניהול לקטלוג:

• עריכה מרובה: בחר 50 מוצרים → שנה קטגוריה/סטטוס/מחיר.
• ייבוא מ-CSV/XLSX: מיפוי עמודות, תצוגה מקדימה עם שגיאות, טעינת רקע דרך תור.
• מיון בגרירה ושחרור: עץ ויזואלי עם יכולת סידור מחדש.
• ניהול מאפיינים: הוסף מאפיין לקטגוריה – הוא מופיע בטפסי העריכה של כל מוצרי הקטגוריה.

לייבוא מרובה: Laravel Jobs + Horizon. קובץ מועלה ל-S3, ה-job לוקח מהתור, מנתח שורה-אחר-שורה (דרך ListItem או PhpSpreadsheet), מוצרים מוכנסים בקבוצות של 100.

כיצד להאיץ את הקטלוג עם קאשינג?

דפי קטלוג הם העומס העיקרי על מסד הנתונים. אסטרטגיית קאשינג:

כאשר מוצר משתנה, בצע flush לקאש רק בדפים שבהם הוא מופיע. תגי קאש ב-Laravel: OFFSET 10000. תצורת קאשינג אופטימלית יכולה להפחית את זמן טעינת הדף מ-3 ל-0.5 שניות. קאשינג יכול לקצץ בעלויות שרת עד 200,000 רובל בשנה.

עבור קטלוגים עם דינמיקה גבוהה (שינויי מחיר או מלאי תכופים), הפחת את TTL של הרשימה ל-1-2 דקות והשתמש באינוולידציה מבוססת תגים. עבור קטלוגים סטטיים, הגדל את ה-TTL לשעה.

לוחות זמנים

• קטלוג בסיסי (קטגוריות, רשימת מוצרים, כרטיס, פגינציה): 2–3 שבועות.
• עם וריאנטים, מאפייני EAV, ייבוא וקאשינג: 4–7 שבועות.
• אינטגרציה עם Elasticsearch לחיפוש ופילטורים מוסיפה 2–3 שבועות.

מה כלול

1. הכנת מפרט טכני עם מודל נתונים מפורט.
2. עיצוב ויישום היררכיית קטגוריות, מאפיינים ווריאנטים.
3. פיתוח מבנה URL מותאם SEO וסימון Schema.org.
4. תצורת פגינציה וקאשינג.
5. אינטגרציה עם פאנל ניהול לניהול מבחר.
6. תיעוד קוד ו-API, הדרכת צוות, העברת גישה.
7. תמיכה באחריות ל-30 יום לאחר המסירה.

אם אתם רוצים להעריך את היקף העבודה לפרויקט שלכם, צרו קשר – ננתח את הקטלוג הנוכחי שלכם ונציע פתרון. קבלו ביקורת קטלוג: בקשו ייעוץ מהנדס. המומחה שלנו יחזור אליכם תוך יום.

טעויות נפוצות בעיצוב קטלוג

• שימוש בפגינציה מסוג offset לקטלוגים >10,000 מוצרים – מוביל להאטות בדפים עמוקים.
• EAV ללא אינדקסים וקאשינג – פוגע בביצועים במהלך פילטור.
• חוסר ב-canonical בדפי פילטור – יוצר כפילויות ומוריד דירוג.
• URL שטוח ללא הגנה מפני שינויי שמות – מאבד משקל SEO.

טעויות אלו מגדילות את זמן הטעינה ב-40% ומפחיתות המרה. הימנעו מהן עם עיצוב נכון תוך שימוש בפרקטיקות מודרניות.