În ce caz are sens să scrieți direct la tabela SQL?
Când este posibil să trebuiască să scrieți direct la tabela SQL de pe platforma 1C 8.1?
În cazul nostru, tabelul de registru 1C8.1 a fost utilizat ca sursă pentru transferul datelor către o altă bază de date contabilă. Pentru un timp, totul a funcționat cu ajutorul lui 1C. Dar a sosit momentul când procesul de scriere a registrului a început să ocupe indecentat mult timp. În același timp, toate datele din registru sunt "urgent necesare".
Cum să accelerați procesul de scriere într-o tabelă SQL
După unele probleme (nu am reușit să depășesc 1C în ceea ce privește optimizarea lucrărilor SQL), a apărut întrebarea despre indexarea tabelului. Ca rezultat, sa decis să se copieze tabela de registru într-o tabelă separată și să se omoare toți indicii, care uneori accelerau procesul de înregistrare directă.
Următoarele descriu implementarea procesului de scriere într-un tabel SQL fără indexuri.
Vom analiza pe un exemplu concret.
Să presupunem că avem următoarele sarcini:
- Colectați pentru anumite înregistrări de conturi pentru o perioadă în cadrul organizațiilor (Orgs) și scenarii (Scene), procesați aceste date în conformitate cu reguli cunoscute și scrieți date într-un tabel al unei baze de date separate
- Înregistrările pentru perioada pentru organizații și scenarii trebuie rescrise
- Trebuie să arhivați tabelul ca și copii la data respectivă
punerea în aplicare
Pentru a crea baza de date, avem nevoie de "Enterprise Manager" (figura 1)
Deschideți "Enterprise Manager". poziționarea în folderul "Baze de date" și făcând clic pe butonul drept al mouse-ului creați o nouă bază de date (figura 2).
Creați o bază (figura 3).
Setarea bazei de date este prezentată în figurile 4 și 5
(T-SQL:
Creați baza de date MyBase
Alter DataBase MyBase SET Recuperare simplă
Alter DataBase MyBase SET Auto_Shrink ON)
Deschideți baza de date, poziționați pe "Tabele" și faceți clic dreapta pentru a crea o tabelă nouă (Figura 6)
În urma TK, avem câmpuri "cheie":
Câmpurile rămase sunt reprezentate sub formă de tipuri de date de bază (Figura 7). Tipurile de valori și lungimea lor sunt luate cu ajutorul unui registru 1C ca exemplu.
Astfel, avem tabelul "MyTable" (Figura 8):
Pentru munca corectă, scriem Organizația și Scriptul sub formă de link-uri (Figura 8). Vom avea nevoie de acest lucru mai târziu.
Nu mă prefac că tratamentul ar trebui să arate așa. Aș dori să menționez că procesele de procesare a datelor și scrierea lor în registru sunt împărțite.
Colectarea și prelucrarea datelor
În acest caz, acest proces nu este de interes. În analiza finală, avem un tabel de valori pentru "tabelul de date"
Ștergerea mesei, scrierea în registru
Vom folosi următoarea schemă:
Nu voi cita tot codul de prelucrare, mă voi concentra doar pe punctele principale.
StrokaKonnekta = "Provider = SQLOLEDB; Parola = $ Sdr 543Qr; Persistă Security Info = true; User ID = userSQL; de catalog inițială = MyBase; Sursa de date = serverSQL";
// Recepție GUID sursă: Mista. ru
Cercetare proprie:
Fragmentul codului de compensare și scriere în registru:
Trebuie remarcat faptul că, în fragmentul de cod de mai sus de mai sus „FIRM“ - Organizația, „BASE“ - script, „ENTITY_NAME“ - un exemplu de valoare șir, „InRep“ - boolean și „Summ“ - suma.
Vreau doar să fac o rezervare că arhivarea are loc prin copierea tabelului la o anumită dată.
55. Alexander Speshilov (speshuric) 950 16.02.11 23:36 Deja în subiect
Nu sunt pierdut, doar puțin încărcat.
Ei bine, atunci. Despre lucrurile mici.
Despre atitudinea mea (nu numai a mea) față de gestionarea tranzacțiilor de la client, am spus principalul lucru. Dar mai este încă un moment. Prin trimiterea "BEGIN TRANSACTION" direct la server, nu luăm în considerare faptul că unii furnizori (și MS SQL prea, dar nu ADO, dar în ADO.NET) pot lucra în modul pool pool. Este minunat ca clientul să preia rapid conexiunea din piscină, în loc să aștepte conexiunea "lungă", dar acest mecanism este mult mai complicat. Și mai multe buggy. Ie "BEGIN TRANSACTION", ipotetic, nu poate merge în legătură cu cererile rămase și cu "COMMIT", deși nu într-un caz atât de trivial. Nu, desigur, acest lucru este de obicei fix (driverul de dezvoltator), dar de ce să căutați rake atunci când conexiunea are metode BeginTrans, CommitTrans și RollbackTrans?
Designul nu este înțeles deloc
De ce un astfel de dans cu tranzacții? Aveți nevoie de o tranzacție - așezați-vă în cerere. Numai dacă utilizați mai multe comenzi într-o singură interogare, trebuie să introduceți mai întâi "SET NOCOUNT ON;". De fapt, tranzacția aici este doar un salt suplimentar de la 1C la ADO, deci este mai ușor de eliminat.
Observație ciudată "Trebuie menționat faptul că înregistrarea în tabela SQL trebuie să fie proprietarul tabelului. Pot să ghicesc ce sa însemnat (de exemplu, că se recomandă să se asocieze utilizatorul bazei de date cu schema dbo în mod implicit), dar dreptul nu este evident. Mai bine aduceți scripturile la crearea tabelelor și a intrărilor - aceasta va fi lipsită de ambiguitate.
Lucru inexact cu paranteze în bucată:
Dacă nu vă pasă ce scrieți, cum poate un "începător" să vă înțeleagă proiectul?
Pentru ce ați stabilit SokrLP pe linie? El o va mânca. Chiar pe muscatura dreapta (sunt multe muscatura si nu se poate vedea), dar la urma urmei, el musca in stanga!
Este ciudat faptul că tranzacțiile sunt utilizate, dar când suprascrieți (ca o singură operație), ștergerea are loc într-o singură tranzacție, iar inserarea într-o altă tranzacție. Nipanyatna.
Drop masa în tranzacție în ciclu cu întrebarea, așa cum am scris mai sus - în cele din urmă poate stoca. De fapt - o soluție cu un singur utilizator.
Nevoia de "arhivare" a acestor volume ridică, de asemenea, mari îndoieli. Pe tabelele cu un volum de până la 100 GB pe an, indexul grupat după dată este adesea suficient pentru urechi. Și apoi puteți folosi partiționarea.
Interogarea pentru sysobjects se face fără a restricționa tipurile de obiecte. Și dacă dacă există o procedură cu acest nume?
Dacă închideți conexiunile la sfârșit, atunci de ce nu ar trebui să se închidă înregistrările după utilizare?
Mai departe. Metoda Execute are conexiuni și comenzi care au de fapt parametri, care sunt CommmTypeEnum și ExecuteOptionEnum. În special, există parametrul "adExecuteNoRecords", care este recomandat pentru executarea interogărilor din care rezultatul nu este așteptat. Apropo, pentru lizibilitate recomand sa folosesc constructiile de tip
astfel încât puteți face codul foarte ușor de citit și portabil cu VBS.
Un exemplu de lucru cu parametrii poate fi găsit aici. Pe scurt, argumentele pro: imposibilitatea de bază de injecție SQL, ar trebui să nu se gândească la reprezentarea constantelor (numere, date), o singură cerere de compilare la server, economisind traficul în rețea. Mai puțin este cunoscut pentru mine singur: pentru anumite tipuri de interogări foarte simple (de exemplu, se introduce un tabel îngust, fără indici) datorită muncii lent la 1C joncțiune și COM mai rapid 1C colectează script-ul dorit (dar, de asemenea, să poată să) și trimite-l la server.
Indicații de blocare. În mod implicit, MS SQL folosește nivelul de izolare READED COMMITTED și blocarea scriere (dacă este posibil) cu o creștere suplimentară a numărului de încuietori. Acest lucru este în general convenabil, dar nu în cazul încărcării în bloc. În cazul încărcării în vrac, pentru a economisi memoria, este mai bine să blocați întreaga masă până la sfârșitul tranzacției.
Ei bine, în general, dacă sunteți interesat de încărcarea de date productive, este mai bine să scoateți din vedere teoria. să-l întruchipeze în practică. Și dacă doriți să faceți un exemplu pentru incepatori, nu superperegruzki că acest exemplu ar trebui să fie perfect frumoasă în simplitatea ei: ea trebuie să fie în același stil de scriere (mai degrabă decât Conn, atunci CONN), acesta trebuie să fie completă și realizată, acesta trebuie să fie corect nu numai din punctul de vedere al începătorului, ci și din punctul de vedere al programatorului normal.