În primul rând, afirmația "Totul într-o singură masă" a fost doar
la lista de bunuri imobiliare. Pune ceva în această masă
Imobiliare nu au nevoie de :)
Îți dau o legătură cu Habr.
"B-tree Operația de căutare se realizează în momentul O (t logt n), unde t -
gradul minim. Este important aici operațiunile pe disc pe care le avem
noi facem doar O (log t n)! "
Logaritmul înseamnă că atunci când creșteți baza de date de 2 ori,
Timpul de căutare crește doar printr-o singură operație de comparație
(sau o operație pe disc, deși acest lucru nu este întotdeauna cazul).
Se pare că pentru a găsi înregistrarea necesară în rândul a 1.000.000 de înregistrări
A petrecut 0.1 sec. Și printre cele 2.000.000 de înregistrări (într-un singur tabel)
este petrecut 0,101 secunde.
Dacă căutăm în două tabele pentru 1.000.000 de înregistrări, atunci respectiv
ne va lua 0.2 sec.
1000, 500, 250, 125, 65, 33, 17, 8, 4, 2, 1
Total 1000 de pagini pentru 11 abordări.
50, 25, 12, 6, 3, 2, 1
Total 50 pagini pentru 7 abordări. Și din moment ce avem 20 de directoare, totalul
vor exista 140 de abordări. Acest lucru este de peste 10 ori mai mult!
Aveți nevoie de rezultatele testelor reale?
vinxru, mulțumesc pentru răspunsul extins.
Aveți dreptate, potențial "Viteza de căutare va scădea de câte ori este numărul de tabele pe care le-ați partajat date (în mod condiționat)".
Dar acest lucru va fi cazul dacă toate tabelele sunt de aceeași mărime (descrieți separarea unei mese mari în 8 mici) și dacă căutăm indexuri. Dar, de fapt, separarea tabelelor nu se bazează pe numărul de înregistrări, ci pe conținutul lor și pe relația dintre date, și nu toate coloanele trebuie să fie indexate.
Ie Masa principală cu proprietăți imobiliare, deși cu mai multe coloane, cel puțin cu cinci, va avea aceeași dimensiune - n. Dar toate datele duplicate nu ar trebui plasate în aceeași masă mare.
De exemplu, avem câteva tipuri de case în baza de date:
Cehii (9 etaje, panouri, cu lift de marfă)
Cehii (12 etaje, panouri, cu lift de marfă)
Cehă (9 etaje, cărămidă, cu lift de marfă)
Dacă plasați aceste date în tabelul principal, acestea vor ocupa mai întâi 4 coloane ("cehă", 9, "cărămidă", "da").
În al doilea rând, pentru a le căuta rapid, va trebui să creați indici suplimentari.
Aș fi făcut altfel: am creat o tabelă separată "de tipul casei" care ar conține aceste tipuri și ar fi foarte mică. În tabelul principal, se adaugă o singură coloană - tipul casei.
Sincer, eu nu pot spune că de căutare pentru a doua versiune a „caramida clădire nouă etaje, cu un lift, un ceh“ va fi mai rapid decât în primul (cu indici), dar cel puțin va câștiga în mărimea de bază și comoditatea de a lucra cu ea.
Orice tabele suplimentare reduc întotdeauna viteza de lucru, adăugăm totul într-una.
Sunt de acord. Voi corecta pentru că "orice JOIN suplimentar sau cererea reduce întotdeauna viteza de lucru".
Îl închin formei normale, ca mulți aici. Dar mi-am dat seama de mult că există trei extreme: productivitatea, simplitatea și forma normală, între care trebuie să alegi.
Articole similare
-
Generarea unui cod de bare pentru formularele poștale din Rusia în 1 secunde
-
Cele mai noi mijloace de întărire a structurii unui unghi natural vă vor da forța și unghiile
Trimiteți-le prietenilor: