- MySQL
- Baze de date
- Stocarea datelor
- Prelucrarea datelor
DB: MySQL.
Sarcina: pentru a stoca datele dicționarului în formularul id: int-> value: string.
Problema: sa dovedit că uneori este necesar ca un id să se potrivească cu o listă de valori. În acest caz, chiar dacă lista este alcătuită dintr-un singur element, trebuie totuși să o deosebiți de valoarea obișnuită.
Văd câteva soluții, dar nu-mi place nici unul.
1) Stocați datele nu ca un șir, ci într-un format: XML, JSON etc. Apoi într-un singur câmp de șir puteți salva întregul obiect.
Opțiunea nu-i place faptul că, în cele din urmă vom obține de-normalizare a datelor și a problemelor legate de acesta, cum ar fi incapacitatea de a opera pe valorile individuale listă instrumente standard SQL. Citirea și schimbarea elementelor individuale vor trebui realizate prin intermediul aplicației.
1.a) Stocați datele într-o singură linie cu un separator. Acesta este un caz special al opțiunii 1, iar contra sunt aceleași.
2) Creați un tabel separat pentru valorile listelor.
Varianta nu este plăcută pentru că va fi necesar să se facă cereri deja la două mese atât la citire, cât și la înregistrare.
3) Stocați toate datele într-o singură masă, doar nu faceți id-ul șirului de dicționare cu o cheie unică, apoi puteți adăuga mai multe intrări pentru un singur id.
Nu-mi place faptul că este dificil de determinat dacă un element este un element obișnuit sau o parte a unei liste. Adăugarea unui câmp de pavilioane speciale a-la is_list_element este o cârpă.
Ei bine, pentru mine, apoi opțiunea2 (Crearea unui tabel separat pentru valorile listelor) Este optim și standard. De obicei, ele nu o lasă decât în situații neobișnuite. Nu recomand să inventați o bicicletă.
Da, cel mai probabil, va trebui să-l utilizați. Speram că am trecut cu vederea o opțiune evidentă și bună.
Permiteți-mi să întreb, dar cum afectează raportul dintre elementele obișnuite și elementele listă?
Mă îngrijorează o altă întrebare. Am creat acum două tabele pentru opțiunea # 2, iar aceste tabele au o structură identică, cu excepția indexului unic din primul tabel.
Ie avem trei câmpuri: id, control_id, value.
Într-un tabel cu elemente simple de control_id, trebuie să potriviți intrarea din acest tabel și elementul paginii în care datele vor cădea (caseta de text). În al doilea tabel, control_id îndeplinește același rol pentru listele derulante + acest câmp va trebui să grupeze înregistrări.
Totul este bine, dar structura aproape identică a meselor duce la suspiciune :)
Permiteți-mi să întreb, dar cum afectează raportul dintre elementele obișnuite și elementele listate? Dacă aveți doar 1% din înregistrările din „lista“ formă, și numai 1-2 dublu pe fiecare, apoi 99 de ori din 100 vei cheltui 2 cereri în loc de una, și numai 1 timp economisi bani pe a face ceva. Este meritat?
Acesta este ceva asemănător cu caching-ul. În cazul în care cache-ul este construit pentru o lungă perioadă de timp ... și ai o memorie cache de 99% a lovit bine, iar dacă 1% dintr-un hit cache, punctul în cache-ul, în general, nu foarte mult. Cu cache-ul este ceva mai evident :)
Totul este bine, dar structura aproape identică a meselor duce la suspiciune. Aveți absolut dreptate.
Dar decizia finală depinde de datele dvs. reale. Normalizarea trebuie făcută bine, nu în ultimul rând pentru a reduce cantitatea de date. Și în caz de duplicare aproape completă ...
Aceasta înseamnă că, dacă aveți 10 valori medii pentru fiecare cheie și în același timp 80% din chei au un "tip" de listă, atunci alegerea celei de-a doua opțiuni este neechivocă. Și dacă listele sunt rare și mici, cel puțin nu este lipsită de ambiguitate.
Răspunsul dvs. la întrebare