Engleza
Romana
YQ Service și TecDoc nu livrează date în același format, iar diferența contează din prima zi de proiectare a bazei de date, nu doar la afișarea pieselor în magazin. YQ Service organizează piesele OE (Original Equipment) în jurul VIN-ului vehiculului și al poziției tehnice originale, în timp ce TecDoc organizează piesele aftermarket în jurul numărului de articol al producătorului terț și al unei chei de compatibilitate proprii. O bază de date bine construită nu forțează cele două structuri într-un singur tabel, ci le păstrează distincte și le leagă printr-o cheie de mapare comună.
Diferența dintre "a avea acces la ambele API-uri" și "a avea un catalog complet" stă exact aici: în modul în care schema bazei de date reține relația dintre o piesă originală și echivalentele ei aftermarket, pentru același vehicul și aceeași poziție tehnică.
Acest ghid explică cele două modele de date, cum se leagă tehnic între ele, ce tabele și chei sunt necesare pentru o bază de date unificată și cum a fost gestionată această combinare în stoauto.ro, un magazin de piese auto originale dezvoltat de HappyWeb cu integrare YQ Service.
Ce structură de date livrează YQ Service pentru piesele OE
YQ Service (sistemul ACIS) răspunde la o interogare pe bază de VIN cu o listă de piese originale, fiecare identificată prin codul OE al producătorului și poziția ei tehnică pe vehicul (de exemplu, "filtru ulei, poziție motor, partea stângă"). Datele includ, de regulă, schema grafică a poziției piesei, ceea ce permite localizarea ei vizuală fără interpretare suplimentară.
Conform informațiilor publicate pe yqservice.eu, platforma acoperă peste 100 de milioane de VIN-uri și 67 de branduri de vehicule pasagere și comerciale, cu date originale preluate direct de la producători. Pentru o bază de date, asta înseamnă un volum mare de combinații VIN-poziție-cod OE, care trebuie stocat eficient, nu doar interogat la cerere.
Ce structură de date livrează TecDoc pentru piesele aftermarket
TecDoc, dezvoltat de TecAlliance, organizează piesele aftermarket în jurul numărului de articol al fiecărui producător terț, legat de o listă de vehicule compatibile prin propriul sistem de identificare (tip motorizare, an de fabricație, variantă caroserie), nu direct prin VIN. O aceeași poziție tehnică poate avea, în TecDoc, mai multe articole de la branduri diferite, cu prețuri și disponibilitate diferite.
Pentru detalii tehnice de integrare TecDoc (API, licențiere, arhitectură de sincronizare catalog), consultă ghidurile dedicate TecDoc de pe HappyWeb.ro; acest ghid tratează exclusiv modul în care structura de date TecDoc se combină cu cea a YQ Service la nivel de bază de date, nu implementarea TecDoc în sine.
Diferența cheie dintre cele două surse: identificator de vehicul vs. identificator de piesă
Cea mai importantă diferență de proiectare este aceasta: YQ Service pornește de la vehicul (VIN) și ajunge la piesă, în timp ce TecDoc pornește de la piesă (articol) și ajunge la o listă de vehicule compatibile. O bază de date care tratează greșit această diferență (de exemplu, presupunând că ambele surse indexează după VIN) va genera erori de mapare greu de depistat ulterior.
| Aspect | YQ Service (OE) | TecDoc (aftermarket) |
|---|---|---|
| Punct de pornire | VIN-ul vehiculului | Numărul de articol al producătorului |
| Identificare piesă | Cod OE + poziție tehnică | Cod articol + brand |
| Compatibilitate vehicul | Directă, pe VIN | Pe combinație motorizare/an/caroserie |
| Multiplicitate | De regulă un singur cod OE pe poziție | Mai multe articole/branduri pe aceeași poziție |
Cum arată o schemă de bază de date care unifică cele două surse
O structură funcțională păstrează trei elemente distincte: tabelul cu piese OE, tabelul cu piese aftermarket și un tabel de mapare între ele, construit pe poziția tehnică, nu pe denumirea liberă a piesei.
- Tabel piese_oe: cod OE, VIN/model asociat, poziție tehnică, schemă grafică, sursă (YQ Service).
- Tabel piese_aftermarket: cod articol, brand, poziție tehnică (mapată manual sau prin tabel de corespondență), preț, stoc, sursă (TecDoc).
- Tabel mapare_pozitii: cheie tehnică unică pe poziție (de exemplu "motor_filtru_ulei"), care leagă rândurile din primele două tabele fără să le amestece.
- Tabel produse_afisate: nivelul folosit efectiv de magazin pentru afișare, care combină, pentru fiecare poziție tehnică și vehicul, varianta OE disponibilă și variantele aftermarket disponibile.
Această separare pe patru tabele evită două probleme frecvente: suprascrierea datelor OE cu date aftermarket la un import comun și imposibilitatea de a actualiza o singură sursă fără să afecteze cealaltă.
Cum decizi când normalizezi datele într-un singur tabel și când le păstrezi separate
Nu orice magazin are nevoie de cele patru tabele descrise mai sus de la început. Decizia depinde de volumul de date și de cât de des se schimbă fiecare sursă:
- Un catalog mic, cu câteva categorii de piese OE, poate porni cu o singură coloană de mapare într-un tabel existent de produse aftermarket, fără tabele separate.
- Un catalog mediu spre mare, cu import periodic din ambele surse, are nevoie de tabele separate plus tabelul de mapare, pentru ca actualizările automate să nu se suprascrie reciproc.
- Un catalog B2B, cu ateliere care cer date tehnice complete pe ambele variante, beneficiază de nivelul suplimentar produse_afisate, ca strat de agregare optimizat pentru interogări rapide, separat de tabelele sursă.
Riscuri de proiectare a bazei de date și cum se evită
Combinarea a două surse externe la nivel de bază de date introduce riscuri specifice, diferite de riscurile de afișare din catalog:
- Chei de mapare inconsistente: dacă poziția tehnică nu are un format unic (text liber în loc de cod standardizat), maparea între OE și aftermarket devine nesigură. Se evită printr-un dicționar fix de poziții tehnice, definit înainte de primul import.
- Import care suprascrie date: un job de sincronizare care actualizează simultan ambele surse în același tabel poate șterge accidental date OE la un import aftermarket. Se evită prin joburi de import separate, pe tabele separate.
- Date orfane: piese aftermarket importate fără nicio poziție tehnică mapată rămân "invizibile" pentru piesele OE echivalente. Se evită prin validare la import, cu raport explicit al rândurilor fără mapare.
- Actualizare asincronă: dacă YQ Service se actualizează lunar și TecDoc zilnic, tabelul de afișare poate reflecta date vechi de la una dintre surse. Se evită printr-un câmp de dată a ultimei sincronizări, verificat înainte de afișare.
Plan practic: cum construiești baza de date unificată pas cu pas
Pentru un magazin care are deja o singură sursă integrată (de obicei TecDoc) și vrea să adauge YQ Service la nivel de bază de date, pașii practici sunt:
- Etapa 1 (0-30 zile): definirea dicționarului de poziții tehnice standard și proiectarea schemei cu tabele separate pentru OE și aftermarket.
- Etapa 2 (30-60 zile): import inițial de date OE din YQ Service, mapare pe poziții tehnice existente, validare a rândurilor fără corespondent.
- Etapa 3 (60-90 zile): construirea tabelului de agregare pentru afișare, joburi automate de sincronizare separate pentru fiecare sursă, testare cu volum real de date pe categoriile prioritare.
Studiu de caz: stoauto.ro, bază de date unificată pentru piese originale
stoauto.ro este un magazin online de piese auto originale dezvoltat de HappyWeb, cu integrare directă a API-ului yqservice.eu. Implementarea include o bază de date de vehicule (activă/inactivă în funcție de disponibilitatea pieselor), scheme grafice de piese OE căutabile vizual, căutare după VIN, sortare după producător și model, plus import și actualizare de prețuri prin fișiere CSV, integrate în modulele de ecommerce ale magazinului (coș, cont client, comenzi, feed-uri pentru marketplace-uri).
Structura de date din spatele acestui proiect a fost gândită astfel încât actualizările de preț, primite periodic prin CSV, să nu afecteze datele tehnice provenite din YQ Service, un exemplu concret al separării descrise mai sus între sursele de date și stratul de afișare.
Întrebări frecvente despre baza de date OE vs. aftermarket
Pot fi stocate piesele OE și aftermarket în același tabel din baza de date?
Tehnic e posibil, dar nu este recomandat la volum mare de date, pentru că cele două surse au formate de identificare diferite (VIN vs. cod articol) și frecvențe de actualizare diferite. Tabelele separate, legate printr-o cheie de mapare, reduc riscul de suprascriere accidentală.
Ce se întâmplă dacă o piesă OE nu are niciun echivalent aftermarket mapat?
Rămâne afișată individual, ca variantă originală, fără alternativă vizibilă. Nu este o eroare de structură; nu toate pozițiile tehnice au echivalente aftermarket disponibile în catalogul TecDoc la un moment dat.
Cum evit duplicarea aceleiași piese sub două coduri diferite?
Prin dicționarul fix de poziții tehnice folosit ca cheie de mapare, nu prin compararea denumirilor libere ale pieselor, care diferă frecvent între cele două surse.
Cât de des trebuie sincronizată baza de date cu fiecare sursă?
Depinde de frecvența de actualizare a fiecărui furnizor și de volumul de categorii acoperite; pentru o estimare corectă a intervalului optim de sincronizare, discută direct cu o echipă de dezvoltare specializată.
Este necesar un tabel separat de agregare pentru afișare?
Pentru cataloage mici, nu. Pentru cataloage medii sau mari, un tabel de agregare separat de tabelele sursă reduce timpul de interogare la afișarea produsului și izolează eventualele erori de import de datele brute.
Concluzie
O bază de date pregătită pentru piese OE și aftermarket nu amestecă cele două surse într-un singur tabel, ci le păstrează separate și le leagă printr-o cheie de mapare construită pe poziția tehnică a piesei. Această structură evită duplicatele, permite sincronizare independentă pentru fiecare sursă și susține un catalog complet, ușor de întreținut pe termen lung. HappyWeb a implementat deja acest tip de structură pentru stoauto.ro și poate face același lucru pentru un magazin care vrea o bază de date unificată pentru piese originale și aftermarket.
Vrei o bază de date de piese auto pregătită pentru OE și aftermarket, fără duplicate? Contactează-ne pentru o discuție despre structura bazei de date și integrare cu YQ Service.
Scrie un comentariu