Krahasimi Postgresql me ms sql. Zgjidhni një bazë të dhënash midis mysql, postgresql, mariadb dhe mssql? Krahasimi i MySQL dhe PostgreSQL: ngjashmëritë dhe dallimet

Shtë e vështirë të gjesh një organizatë që nuk përdor sisteme të kontabilitetit nga 1C - madje edhe në megaholdings ku SAP ose OEBS janë zbatuar për një kohë të gjatë, ato përdoren pothuajse gjithmonë në një zonë ose në një tjetër. Është kënaqësi që softueri i aplikimit rus është bërë standardi de fakto për kompanitë tona, por ka një hollësi: përdorimi i Microsoft SQL Server si një DBMS është bërë një standard po aq de facto për vetë 1C: Enterprise.

Midis praktikuesve të 1C, mendimi më i zakonshëm është se pa DBMS komerciale nga prodhuesit amerikanë nuk do të ketë asgjë të mirë, thonë ata, disa qindra përdorues kërkojnë në mënyrë të pashmangshme instalimin e një baze të dhënash në MS SQL, Oracle Database ose IBM DB2; Mendimet e praktikuesve të njohur për ne për punën nën lirinë e PostgreSQL DBMS ndryshonin, por në rangun nga "nuk funksionon fare" në "i përshtatshëm për disa dhjetëra përdorues, jo më shumë".

Kishte një sërë shpjegimesh të besueshme për vlerësime të tilla modeste: përdorimi aktiv i mekanizmave të tabelave të përkohshme nga platformat 1C (të cilat në Postgres zbatohen shumë "sinqerisht" - me DDL transaksionale, të gjitha aftësitë e rikuperimit), dhe veçoritë e punës me të dhënat e tekstit. (ndërsa në fushën e teksteve shumëgjuhëshe, vanilja Postgres, përsëri, është tepër konservatore, duke mos përdorur bibliotekat e sistemit me performancë më të lartë), dhe një sërë aspektesh të tjera më pak të rëndësishme.

Por ne fshehtas besuam në Postgres, aq më tepër që asambleja pretendonte të zgjidhte të gjitha ato probleme që skeptikët përdorën për të justifikuar zgjedhjen e DBMS tregtare. Për më tepër, ishte e rëndësishme për ne që të merrnim treguesit e destinacionit për kompleksin e harduerit dhe softuerit - një motor të dhënash për një DBMS, i ndërtuar mbi bazën e pajisjeve dhe softuerit të sigurt për sanksione, të zhvilluara nga IBS së bashku me Postgres Professional.

Nga aplikacionet e përsëritura, aplikacioni më i dukshëm për një makinë të tillë, natyrisht, duhet të jenë sistemet 1C. Dhe rezultatet e standardeve të kryera na transferuan plotësisht nga kategoria e "besimtarëve të fshehtë" (dhe madje edhe dyshues) në kategorinë e "të bindurve": tani mund të themi me siguri se 1C:Enterprise versioni 8.3 në ndërtimin PostgreSQL EE 1.5 për Skala-SR / PostgreSQL funksionon më mirë se MS SQL 2012 në të njëjtin harduer me të gjitha optimizimet e mundshme.

Pra, disa detaje të eksperimenteve. Për sa i përket testimit të performancës, 1C ka gjithçka në mënyrë sistematike dhe shkencore - ekziston një konfigurim standard "Testi i ngarkesës standarde", mbi të cilin është nisur standardi, duke shtuar gradualisht përdorues të rinj në ngarkesë derisa aplikacioni të jetë mjaft i përgjegjshëm për punë të rehatshme. (Më saktë, përdoruesit shtohen derisa rezultati standard i performancës së aplikacionit Apdex të bjerë nën pragun prej 0.85, dhe numri maksimal i përdoruesve të tillë me performancë efektive konsiderohet si rezultat standard.)

Ne përdorëm versionin 8.3.9.1850 të 1C: Enterprise, test standard i ngarkesës në versionin 2.0.17.36. Fillimisht, u vendos që të mos jepet asnjë zbritje për Postgres: ne bëjmë optimizime maksimale në MS SQL në një nyje nga kompleksi Skala-SR / Postgres Pro (ne instalojmë Windows në metal të zhveshur, e konfigurojmë atë sipas të gjitha kanuneve, për shpejtësi ne bëjmë një ramdisk për tabela të përkohshme), dhe më pas e kthejmë të njëjtën nyje në kompleksin Scala-SR, instalojmë Linux dhe Postgres Pro EE dhe vetëm mbi të (pa çipat e grupit të disponueshëm në kompleks) kryejmë të njëjtin test.

Testi i parë: fillojmë me 100 vende pune, ngarkesa është 50/50 - gjysma gjeneron dokumente, gjysma gjeneron raporte. Testi i dytë: filloni me 400, ngarkesa 70/30. MS SQL “përfundoi” në testin e parë me 360 përdorues, në të dytin me 540 përdorues dhe kufizuesi në të dy ekzekutimet punonte me I/O lokale, pavarësisht se procesori ishte i ngarkuar mesatarisht me vetëm 30%. PostgreSQL arriti në 440 vende pune në provën e parë dhe deri në 660 në provën e dytë, por në serverin e bazës së të dhënave gjithçka zbriti në procesor, i cili u ngarkua në më shumë se 90% në "përdoruesit maksimalë".

Për 1C, ku numri i përdoruesve të njëkohshëm është faktori kufizues më problematik, ky është një rezultat i jashtëzakonshëm dhe më e rëndësishmja, tregon se këto sisteme aplikimesh ruse më të rëndësishme jo vetëm që mund të funksionojnë pa DBMS komerciale perëndimore, por edhe ta bëjnë atë shumë më mirë. .

Seria e përmbajtjes:

1. Historia e zhvillimit të MySQL dhe PostgreSQL

Historia e MySQL fillon në 1979, në origjinën e saj kishte një kompani të vogël të udhëhequr nga Monty Widenius. Në 1996, u shfaq publikimi i parë i 3.11 për Solaris me një licencë publike. Pastaj MySQL u transferua në sisteme të tjera operative dhe u shfaq një licencë speciale tregtare. Në vitin 2000, pasi shtoi një ndërfaqe të ngjashme me Berkeley DB, baza e të dhënave u bë transaksionale. Replikimi u shtua në të njëjtën kohë. Në vitin 2001, versioni 4.0 shtoi motorin InnoDB në MyISAM ekzistues, duke rezultuar në caching dhe rritje të performancës. Në vitin 2004, u lëshua versioni 4.1, i cili prezantoi nënpyetje, indeksim të pjesshëm për MyISAM dhe Unicode. Në versionin 5.0 në 2005, u shfaqën procedurat e ruajtura, kursorët, nxitësit dhe pamjet. MySQL po zhvillon tendenca komerciale: në vitin 2009, MySQL u bë një markë tregtare e Oracle.

Historia e Postgres filloi në 1977 me bazën e të dhënave Ingress.

Në 1986, ajo u riemërua PostgreSQL në Universitetin e Berkeley, Kaliforni.

Në 1995, Postgres u bë një bazë të dhënash e hapur. U shfaq psql interaktive.

Në 1996, Postgres95 u riemërua PostgreSQL version 6.0.

Postgres ka disa qindra zhvillues në mbarë botën.

2. Arkitektura e MySQL dhe PostgreSQL

PostgreSQL– një server i unifikuar i bazës së të dhënave me një motor të vetëm – motor ruajtës. Postgres përdor një model klient-server.

Për çdo klient, një proces i ri (jo një fill!) krijohet në server. Për të punuar me procese të tilla klienti, serveri përdor semaforë.

Kërkesa e klientit kalon nëpër fazat e mëposhtme.

Lidhu.
Analiza: kontrollohet korrektësia e kërkesës dhe krijohet një pemë pyetëse. Analizuesi bazohet në shërbimet bazë të Unix-it yacc dhe lex.
Rishkruaj: merret një pemë pyetëse dhe kontrollohet prania e rregullave në të, të cilat ndodhen në drejtoritë e sistemit. Sa herë që pyetja e përdoruesit rishkruhet në një pyetje që akseson tabelat e bazës së të dhënave.
Optimizer: për çdo kërkesë krijohet një plan pyetësor, i cili i kalohet ekzekutuesit. Qëllimi i planit është se ai kalon nëpër të gjitha opsionet e mundshme për të marrë rezultatin (qoftë për të përdorur indekse, bashkime, etj.), dhe zgjedh opsionin më të shpejtë.
Ekzekutimi i pyetjes: ekzekutuesi përshkon në mënyrë rekursive pemën dhe merr rezultatin, duke përdorur renditjen, bashkimet, etj., dhe kthen rreshtat. Postgres është një bazë të dhënash objekt-relacionale, çdo tabelë në të përfaqëson një klasë, dhe trashëgimia zbatohet midis tabelave. Implementuar standardet SQL92 dhe SQL99.

Modeli i transaksionit është ndërtuar mbi bazën e të ashtuquajturit kontrolli i konkurencës me shumë versione (MVCC), i cili jep performancë maksimale. Integriteti i referencës sigurohet nga prania e çelësave parësorë dhe dytësorë.

MySQL ka dy shtresa - një shtresë e jashtme sql dhe një grup të brendshëm motorësh, nga të cilët motori InnoDb përdoret më shpesh, pasi mbështet plotësisht ACID.

Standardi i implementuar SQL92.

Nga pikëpamja modulare, kodi MySQL mund të ndahet në modulet e mëposhtme.

Inicializimi i serverit.
Menaxheri i lidhjes.
Menaxheri i transmetimit.
Trajtuesi i komandave.
Autentifikimi.
Analizues.
Optimizer.
Drejtues tavoline.
Motorët (MyISAM, InnoDB, MEMORY, Berkeley DB).
Prerjet.
Replikimi.
API i rrjetit.
Kernel API.

Rendi i funksionimit të moduleve është si më poshtë: së pari, ngarkohet moduli i parë, i cili lexon opsionet e linjës së komandës, skedarët e konfigurimit, shpërndan kujtesën, inicializon strukturat globale, ngarkon tabelat e sistemit dhe transferon kontrollin te menaxheri i lidhjes.

Kur një klient lidhet me bazën e të dhënave, kontrolli i transferohet menaxherit të thread-it, i cili krijon një thread (jo një proces!) për klientin dhe kontrollohet vërtetimi i tij.

Kërkesat e klientëve, në varësi të llojit të tyre, përpunohen në nivelin më të lartë nga moduli i katërt (dispeçer). Kërkesat do të regjistrohen nga moduli i 11-të. Komanda i kalohet parserit dhe kontrollohet cache. Më pas, kërkesa mund të shkojë te optimizuesi, moduli i tabelës, moduli i përsëritjes, etj. Si rezultat, të dhënat i kthehen klientit përmes menaxherit të transmetimit.

Kodi më i rëndësishëm është në skedarin sql/mysqld.cc. Ai përmban funksione themelore që nuk kanë ndryshuar që nga versioni 3.22: init_common_variables () init_thread_environment () init_server_components () grant_init () // sql/sql_acl.cc init_slave () // sql/slave.cc get_options () trajton_connictions_sockets () chated_newread () handle_one_connection() check_connection() acl_check_host() // sql/sql_acl.cc create_random_string() // sql/password.cc check_user() // sql/sql_parse.cc mysql_parse() //ccpachery_parse ::store_query() // sql/sql_cache.cc JOIN::optimize() // sql/sql_select.cc open_table() // sql/sql_base.cc mysql_update() // sql/sql_update(//ccl_update) sql/sql_table.cc

Kreu sql/sql_class.h përcakton klasat bazë: Query_arena, Statement, Security_context, Open_tables_state classes, THD. Një objekt i klasës THD është një përshkrues thread dhe është një argument për një numër të madh funksionesh.

3. Krahasimi i MySQL dhe PostgreSQL: ngjashmëritë dhe dallimet

Standardi ACID

Standardi ACID bazohet në atomicitetin, integritetin, izolimin dhe besueshmërinë. Ky model përdoret për të garantuar integritetin e të dhënave. Kjo zbatohet në bazë të transaksioneve. PostgreSQL është plotësisht në përputhje me ACID. Për të mbështetur plotësisht ACID në MySQL, duhet të vendosni default-storage-engine=innodb në konfigurim.

Performanca

Bazat e të dhënave shpesh optimizohen bazuar në mjedisin në të cilin ato funksionojnë. Të dyja bazat kanë teknologji të ndryshme për të përmirësuar performancën. Historikisht, MySQL u zhvillua me shpejtësinë në mendje, ndërsa PostgreSQL u projektua që në fillim për të qenë shumë i personalizueshëm dhe në përputhje me standardet. PostgreSQL ka një numër cilësimesh që rrisin shpejtësinë e aksesit:

indekset e pjesshme;
kompresimi i të dhënave;
alokimi i memories;
cache e përmirësuar.

MySQL ka mbështetje të pjesshme për indekset e pjesshme në InnoDB. Nëse merrni motorin MySQL ISAM, rezulton të jetë më i shpejtë në pyetjet e sheshta, ndërsa nuk ka bllokime në inserte, nuk ka mbështetje për transaksione, çelësa të huaj.

Kompresimi

PostgreSQL kompreson dhe dekompreson më mirë të dhënat, duke ju lejuar të ruani më shumë të dhëna në hapësirën e diskut. Në të njëjtën kohë, të dhënat e kompresimit lexohen më shpejt nga disku.

Kompresimi MySQL për motorë të ndryshëm mbështetet pjesërisht, pjesërisht jo, dhe kjo varet nga versioni specifik i një motori të caktuar.

Për sa i përket performancës me shumë procesorë, PostgreSQL ka një avantazh ndaj MySQL. Edhe vetë zhvilluesit e MySQL pranojnë se motori i tyre nuk është aq i mirë në këtë drejtim.

Llojet e të dhënave

MySQL: përdor llojet TINYBLOB, BLOB, MEDIUMBLOB, LONGBLOB për të ruajtur të dhënat binare, të cilat ndryshojnë në madhësi (deri në 4 GB).

Karakteri: katër lloje - TINYTEXT, TEXT, MEDIEUMTEXT, LONGTEXT.

PostgreSQL: Mbështet motorin e të dhënave të përdoruesit me komandën CREATE TYPE, tipin BOOLEAN, llojet gjeometrike.

Karakteri: TEXT (kufizimi – madhësia maksimale e rreshtit).

Për të ruajtur të dhënat binare, ekziston një lloj BLOB që ruhet në sistemin e skedarëve. Kolonat e tabelës mund të përkufizohen si një grup shumëdimensional me gjatësi të ndryshueshme. Zgjerimi objekt-relativ: Struktura e një tabele mund të trashëgohet nga një tabelë tjetër.

Procedurat e ruajtura

Të dy PostgreSQL dhe MySQL mbështesin procedurat e ruajtura. PostgreSQL ndjek standardin Oracle PL/SQL, MySQL ndjek standardin IBM DB2. MySQL mbështet zgjerimin e SQL për funksionet e shkrimit në C/C++ që nga versioni 5.1. PostgreSQL: PL/PGSQL, PL/TCL, PL/Perl, SQL, C për shkrimin e procedurave të ruajtura.

Çelësat

Të dy PostgreSQL dhe MySQL mbështesin çelësin kryesor unik dhe çelësin e huaj. MySQL nuk mbështet kufizimet e kontrollit, plus çelësat dytësorë janë implementuar pjesërisht. PostgreSQL: implementim i plotë plus mbështetje për ON DELETE CASCADE dhe ON UPDATE CASCADE.

Shkaqet

MySQL: mbështetje rudimentare. PostgreSQL: nxitësit deklarativë: SELECT, INSERT, DELETE, UPDATE, SEAD OF; nxitësit procedural: KUFIZUESI I KUFIZIMIT. Ngjarjet: PARA ose PAS në INSERT, DELETE, UPDATE.

Rritje automatike

MySQL: Mund të ketë vetëm një kolonë të tillë në një tabelë, e cila duhet të indeksohet. PostgreSQL: Lloji i të dhënave SERIALE.

Replikimet

Mbështetet si në MySQL ashtu edhe në PostgreSQL. PostgreSQL ka një arkitekturë modulare dhe riprodhimi përfshihet në module të veçanta:

Slony-I është mekanizmi kryesor i replikimit në Postgres zvogëlimi i performancës si një funksion kuadratik i numrit të serverëve;

Replikimi në PostgreSQL është i bazuar në shkas dhe më i ngadalshëm se në MySQL. Është planifikuar të shtohet përsëritja në kernel duke filluar nga versioni 8.4.

Në MySQL, përsëritja përfshihet në thelb dhe ka dy shije, duke filluar me versionin 5.1:

SBR – replikimi i bazuar në deklarata;
RBR – replikimi i bazuar në rresht.

Lloji i parë bazohet në regjistrimin e të dhënave në një regjistër binar, i dyti bazohet në ndryshimet e regjistrimit. Duke filluar nga versioni 5.5, MySQL mbështet të ashtuquajturin replikim gjysmë sinkron, në të cilin serveri kryesor (master) rivendos të dhënat në një server tjetër (skllav) me çdo kryerje. Motori NDB bën replikim të plotë sinkron dyfazor.

Transaksionet

MySQL: Vetëm InnoDB. Mbështet SAVEPOINT, KTHIM NE SAVEPOINT. Nivelet e kyçjes: niveli i tavolinës (MyISAM). PostgreSQL: i mbështetur plus nivelet e kryera dhe të izolimit të leximit. Mbështetje ROLLBACK, ROLLBACK TO SAVEPOINT. Nivelet e mbylljes: niveli i rreshtit, niveli i tabelës.

Nivelet e privilegjeve

PostgreSQL: Privilegjet mund t'i caktohen një përdoruesi ose grupi përdoruesish.

Të dhënat e eksport-importit

MySQL: një grup i shërbimeve të eksportit: mysqldump, mysqlhotcopy, mysqlsnapshot. Importoni nga skedarët e tekstit, html, dbf. PostgreSQL: eksport - mjet pg_dump. Importoni midis bazave të të dhënave dhe sistemit të skedarëve.

Pyetjet e mbivendosura

Në dispozicion si në MySQL ashtu edhe në PostgreSQL, por ato mund të mos funksionojnë me efikasitet në MySQL.

Indeksimi

Hashimi i indeksit: i pjesshëm në MySQL, i plotë në PostgreSQL. Kërkimi në tekst të plotë: i pjesshëm në MySQL, i plotë në PostgreSQL. Indekset e pjesshme: nuk mbështeten në MySQL, mbështeten në PostgreSQL. Indekset me shumë kolona: në MySQL kufiri është 16 kolona, në PostgreSQL – 32. Indekset e shprehjes: në MySQL – emulim, në PostgreSQL – i plotë. Indeksi i krijimit pa bllokim: në MySQL - i pjesshëm, në PostgreSQL - i plotë.

Ndarje

MySQL mbështet ndarjen horizontale: varg, listë, hash, çelës, ndarje të përbërë. PostgreSQL mbështet RANGE dhe LIST. Ndarje automatike për tabela dhe indekse.

Rikuperimi automatik nga dështimet

MySQL: i pjesshëm për InnoDB - duhet të bëni manualisht një kopje rezervë. PostgreSQL: Shkruani regjistrimin përpara (WAL).

Motorët e ruajtjes së të dhënave

PostgreSQL mbështet një motor - Postgres Storage System. Ka disa prej tyre në MySQL 5.1:

MyISAM – përdoret për të ruajtur tabelat e sistemit;
InnoDB – pajtueshmëri maksimale me ACID, ruan të dhënat me çelësat kryesorë, futjet në memorie, mbështet kompresimin duke filluar nga versioni 5.1 – shih atributin ROW_FORMAT=COMPRESSED;
NDB Cluster – një motor i orientuar nga memorja, arkitektura e grupimit duke përdorur replikimin sinkron;
ARCHIV – mbështet kompresimin, nuk përdor indekse;
dhe gjithashtu: MERGE, MEMORY (HEAP), CSV.

InnoDB është zhvilluar nga InnoBase, një degë e Oracle. Në versionin 6, duhet të shfaqen dy motorë - Maria dhe Falcon. Falcon është një motor i bazuar në transaksionet ACID.

Licencimi

PostgreSQL: BSD (Berkeley Software Distribution) me burim të hapur. MySQL: GPL (Gnu General Public License) ose Commercial. MySQL është një produkt me burim të hapur. Postgres është një projekt me burim të hapur.

konkluzioni

Për ta përmbledhur, mund të themi sa vijon: MySQL dhe PostgreSQL janë dy bazat e të dhënave më të njohura me burim të hapur në botë. Çdo bazë ka karakteristikat dhe dallimet e veta. Nëse keni nevojë për ruajtje të shpejtë për pyetje të thjeshta me konfigurim minimal, unë do të rekomandoja MySQL. Nëse keni nevojë për ruajtje të besueshme për sasi të mëdha të dhënash, të zgjerueshme, të përsëritshme dhe plotësisht në përputhje me standardet moderne të gjuhës SQL, unë do të sugjeroja përdorimin e PostgreSQL.

Ne do të diskutojmë çështjet e konfigurimit për MySQL dhe PostgreSQL.

Burimet për shkarkim

static.content.url=http://www.site/developerworks/js/artrating/

Zone=Burim i hapur, Linux

ID e artikullit=779830

ArticleTitle=MySQL & PostgreSQL: Pjesa 1. Analiza krahasuese

Një çelës në server nevojitet për të nisur Serverin 1C (le ta quajmë atë 1C App).
Nevojitet një server 1C në mënyrë që baza e të dhënave të mos jetë e bazuar në skedarë, por me tre nivele.
Tre nivele, i njohur gjithashtu si tre nivele, është një model ndërveprimi me Klientin 1C<->Aplikacioni 1C<->DBMS (MS SQL, DB2, Oracle, PostgreSQL)
Ato. klienti, në fakt, nuk komunikon me serverin DBMS, ai komunikon me serverin 1C, dhe ai, nga ana tjetër, komunikon me DBMS.
Kështu, mund të keni 2,3,5-25-125 serverë DBMS, dhe vetëm një server 1C. Vetëm për secilën bazë të dhënash të serverit 1C do t'ju duhet të tregoni se në cilin server është instaluar baza e të dhënave specifike dhe çfarë lloj serveri është (lloji i DBMS).
Një çelës për një server 1C kushton ~ 42 mijë rubla. për versionin 32-bit, dhe ~ 74 tr. për 64-bit. Në të njëjtën kohë, çelësi për versionin 64-bit mund të përdoret për një server 32-bit (e kundërta, natyrisht, nuk është e mundur).
Si një çelës për serverin, e shoh më të arsyeshme përdorimin e një çelësi harduer.
Nga rruga, në lidhje me licencimin:
- shkollë e lirë
Po, ekziston një version i dorëzimit 1C me një licencë të përfshirë tashmë për MS SQL. Por:
A. Për të marrë një dërgesë të tillë, duhet të blini një grup: server 1C + MS SQL + të paktën 5 licenca klienti (më korrigjoni nëse e kam gabim, është e mundur që të keni nevojë të blini të paktën 10 klientë)
i cili, në rastin e çelësave 1C të blerë tashmë, zvogëlon shumë përfitimin e një blerjeje të tillë.
b. Sipas kushteve të licencës, kjo gjëmë mund të përdoret VETËM për 1 Ski.
Ato. Duket se jeni në gjendje të vendosni një bazë tjetër të dhënash në të, por kjo do ta kthejë menjëherë MS SQL të licencuar në një të palicensuar.
- Licencimi i saktë -
Sipas rregullave, licencimi MS SQL duhet të kryhet si licencë serveri + licenca për lidhjet e klientit.
Aty ku një "klient" konsiderohet se nuk është aplikacion 1C me një lidhje të vetme (mund të ketë më shumë lidhje - në varësi të numrit të proceseve që konfiguroni në server), por çdo përdorues 1C + 1 licencë për aplikacionin 1C
Ose licencimi i bazuar në procesorët e serverëve.
Për më tepër, mund të gaboj, por në rastin e 2005 - 2008 MS SQL, ju duhet të licenconi folenë (d.m.th., procesorin fizik, nëse numri i bërthamave nuk kalon 4), atëherë në rastin e 2012, Licencimi shkon te bërthamat e procesorit me një çmim = çmimi i licencës * numri i bërthamave/4.
Për më tepër, ORACLE ka përdorur këtë sistem licencimi për një kohë të gjatë (ekziston një tabelë e koeficientëve në varësi të numrit total të bërthamave të serverit),
sepse mjetet moderne të virtualizimit lejojnë të paktën 4, të paktën 64 procesorë fizikë 4-6-8 bërthama që të paraqiten në një makinë virtuale si 1 fizike me +100500 bërthama (të cilat disa i kanë përdorur me sukses)
- licencim i përhapur -
Shumë shpesh, vetëm një licencë serveri blihet (~ 28,000 rubla) dhe shpenzohet plotësisht për licencimin e lidhjeve të klientit.
Në disa raste, për shembull në rastin e Marrëveshja e ndërmarrjes, kjo është e pranueshme (pasi një licencë për një klient OS brenda licencës siguron automatikisht një licencë për një lidhje serveri).
Por në shumicën e rasteve shkel licencimin. Edhe pse ai ankohet dhe nuk shan.

Le të jemi të sinqertë, megjithëse 1C Enterprise është në përputhje me shumë DBMS, në fakt 99 për qind funksionojnë ose në MS SQL ose në PostgreSQL falas.

Me fjalë të tjera, këto dy "nën-tavolina" kanë pushtuar tregun klient-server 1C.

Dhe mund të supozojmë me siguri se nëse një kompani nuk punon në MS SQL, atëherë ka shumë të ngjarë që ata thjesht përdorin PostgreSQL.

Prandaj, ka kuptim vetëm të krahasohet Postgres me MS SQL.

Sot shkruhet shumë për MS SQL dhe PostgreSQL, por zakonisht ato nuk krahasohen objektivisht.

Në këtë artikull, ne do të analizojmë aspektet kryesore teknike të PostgreSQL falas, duke e krahasuar atë me MS SQL.

Çfarë do t'ju lejojë të bëni zgjedhjen më të mirë në të ardhmen dhe të përgatiteni për "surpriza" të ndryshme ose çfarë do t'i përshtatet më shumë "veçorive" të punës në këtë DBMS falas.

Do ta vlerësojmë gjithçka ashtu siç është, pa i shtuar Postgres ato merita që nuk i ka dhe pa e zbukuruar MS-në e paguar.

Unë do t'i përgjigjem menjëherë një pyetjeje që shqetëson shumë fillestarë!

PO! MS SQL funksionon më shpejt se PostgreSQL, ky është një fakt! Dhe ka një sërë arsyesh për këtë!

Ndoshta zhgënjeva menjëherë dikë, dhe mbase nuk jeni dakord me këtë deklaratë, ju kërkoj falje, por vetë fizika e kësaj DBMS falas nuk e lejon atë të kalojë përpara MS SQL, veçanërisht nëse po flasim për një kombinim të tillë si "Monster 1C" dhe PostgreSQL.

Do të shihni argumente të ngjashme më shumë se një herë në konferenca dhe seminare të ndryshme kushtuar këtij DBMS. Askush nuk fsheh dhe nuk mohon asgjë, një fakt është një fakt.

Sidoqoftë, performanca e PostgreSQL është mjaft e mjaftueshme për përdoruesit mund të funksionojë rehat në 1C.

Qofshin një duzinë përdoruesish apo edhe disa qindra që punojnë njëkohësisht në 1C Enterprise.

Pse "Monster 1C"?

Në fakt, kjo është mënyra se si 1C e sheh PostgreSQL pa "arna" të veçanta dhe shtesa të instaluara.

Po, siç thonë ata, jashtë kutisë, duke shkarkuar shpërndarjen PostgreSQL në zyrë. faqen e internetit, nuk do të mund ta përdorni për të punuar në lidhje me 1C. 1C do të ngadalësohet tmerrësisht dhe thjesht do të ndalojë dhe do të refuzojë të punojë.

Pse ndodh kjo dhe pse "arna"?

Fakti është se 1C Enterprise krijon një numër të madh tabelash të përkohshme në procesin e punës së saj, mund të flasim për rreth mijëra tavolina në sekondë, dhe nëse merrni, për shembull, regjistrin "Fetë e më të fundit" - "Të mbeturat dhe qarkullimet", mund të ketë dhe një milion rreshta secila të jetë.

Fakti është se si parazgjedhje (pa "arna") PostgreSQL nuk llogarit statistika në këto tabela të mëdha të përkohshme, me fjalë të tjera, optimizuesi i pyetjeve, i cili udhëhiqet nga të dhënat nga statistikat (dhe siç kujtojmë, është bosh; asgjë për të numëruar), përafërsisht, bën një përzgjedhje duke përdorur metodën ZGJIDH * që sigurisht do të funksionojë shumë, shumë ngadalë!

Prandaj frenat e mëdha në 1C!

Sigurisht, këto nuk janë të gjitha problemet që duhen zgjidhur që PostgreSQL të funksionojë siç duhet në lidhje me 1C. Do të nevojiten "arna" të tjera dhe shtesa speciale, dhe pas 15-20 përdoruesve do të nevojiten shtesë. cilësimet në "config"

Po, në fakt, në realitet gjithçka duket shumë më e ndërlikuar nga sa përshkrova më lart, por kështu, nëse thjeshtohet shumë, do të duket problemi kryesor i punës së ngadaltë të 1C me PostgreSQL.

Gjëja e dytë që nuk më pëlqen vërtet për PostgreSQL është mungesa e multithreading brenda një kërkese të vetme krahasuar me MS SQL.

(Duke filluar me versionin 9.6, ne bëmë përpjekjen e parë për të paralelizuar pyetjet, por deri më tani funksionon dobët, ndonjëherë efekti është i kundërt). por për të provuar 5!)

Çfarë, natyrisht, ndikon në performancën, në mënyrë që të kuptoni në terma të thjeshtë -

PostgreSQL është në gjendje të prishë serverin tuaj 48-bërthamë me një pyetje të madhe!

Është e thjeshtë, nuk ka paralelizim të fijeve brenda një kërkese dhe një kërkesë e madhe "ngarkon" vetëm një bërthamë.

Po, nëse ka shumë kërkesa, atëherë të gjitha bërthamat do të ngarkohen dhe gjithçka do të funksionojë mirë.

Dhe pothuajse harrova Ne po krahasojmë PostgreSQL me MS SQL Standard jo Express!

Megjithëse Express mund të përdoret për qëllime komerciale, ka një sërë kufizimesh

të tilla si 10 GB për bazë, përdorimi i një procesori, 1 GB RAM,

e bën përdorimin e një produkti të tillë pothuajse të pamundur për të punuar në 1C Enterprise.

Nëse nuk keni një bazë të dhënash shumë të vogël dhe vetëm disa përdorues (dhe edhe atëherë ka shumë pak frena 1 GB për një DBMS).

Pra, le të krahasojmë PostgreSQL me versionin popullor Standard.

SKRIPTET!!!

PostgreSQL është kryesisht skriptet në krahasim me MS SQL, shumica e operacioneve duhet të bëhen me dorë, dhe sigurisht që mund të instaloni dhe bëni disa gjëra themelore përmes ndërfaqes, por theksoj se ato themelore, dhe një hap në të majtë është një hap djathtas dhe ju duhet të shkruani një skrip, ose BAS në Linux ose cmd, powershell në Windows.

Shikoni dhe analizoni gjurmët duke përdorur SQL Server Profiler.

Profiler i njohur i serverit SQL mungon në PostgreSQL, dhe me fjalën "mungon" dua të them plotësisht, mjerisht, nuk ka asgjë të tillë në PostgreSQL.

Ka, sigurisht, shërbime që ju lejojnë, nëse keni kohë të përgjoni një kërkesë ose të vendosni një pikë ndërprerjeje 1C në korrigjues, dhe të merrni diçka dhe ta shikoni atë, por në krahasim me Profiler, siç thonë ata, nuk ishte' t edhe mbyll.

Mund të vendosni një regjistër dhe më pas t'i renditni të gjitha - por do të duhet shumë kohë!

Ja një shembull:

Një programues 1C po përpiqet të korrigjojë disa pyetje të mëdha, kërkon shumë kohë për të ekzekutuar, për shembull 30 minuta, por në PostgreSQL, në mënyrë që të dhënat të përfshihen në regjistër, kjo pyetje duhet të ekzekutohet! Mund ta imagjinoni sa kohë do të duhet për të korrigjuar një kërkesë të tillë?

Ndërsa në MS SQL mund të ndërprisni ekzekutimin e një pyetjeje dhe ta analizoni atë në Profiler, pasi ai tashmë do të jetë atje, por me statusin "i dështuar".

Postgres nuk ka të barabartë në shumëllojshmërinë e opsioneve të krijimit të kopjeve rezervë!

Këtu keni kopje rezervë në rritje, kopje rezervë të plotë dhe arkivim të vazhdueshëm WAL.

Në fakt, ekziston një kopje rezervë e pjesshme dhe rikuperimi i pjesshëm i të dhënave.

Mund të konfiguroni arkivimin e vazhdueshëm dhe rikuperimin pikë-në-kohë (Rikuperimi në kohë (PITR)).

Gjithashtu përsëritje, është i disponueshëm në mënyrë origjinale në PostgreSQl pa asnjë "arnim" të shërbimeve ose shtesave!

Replikimi kaskadë
Riprodhimi i transmetimit
Replikimi sinkron
Arkivim i vazhdueshëm në një server rezervë

E gjithë kjo tashmë është e disponueshme fillimisht në PostgreSQl dhe natyrisht jo në "express" dhe nuk është e disponueshme në versionin MS SQL Standard.

Për të marrë të gjitha sa më sipër në MS SQL, duhet të blini një MS SQL Enterprise shumë të shtrenjtë, tani rreth 15,000 dollarë.

Çfarë mungon në krahasim me MS SQL?

JO "backup" diferencial

Po, në PostgreSQl nuk ka "backup" diferencial, por ka analoge të ndryshme të krijimit në rritje të "backups".

Për shembull, "backup" në rritje në nivelin e bllokut.

KA një ndarje të TABLESPACE, e cila tashmë mbështet 1C si parazgjedhje!

E cila, nga rruga, nuk është në MS SQL!

Për shembull, mund të konfiguroni se në cilin disk do të keni "indekse" dhe në cilin disk do të vendoset "tabela" kjo është shumë e përshtatshme kur planifikoni infrastrukturën tuaj të TI-së kur bëhet fjalë për bazat e të dhënave të mëdha 1C. ONLINE_ANALYZE për të rillogaritur statistikat. E njëjta gjë vlen edhe për skedarin *dt.

Duke përdorur PostgreSQl, ju rrallë keni nevojë për REINDEX!

Në fakt, duhet të përdoret vetëm kur ekziston dyshimi se integriteti i bazës së të dhënave është dëmtuar.

Ju mund të bëni "kopje rezervë" duke përjashtuar tabelat!

Për shembull, nëse keni disa programues 1C që punojnë në kompaninë tuaj, ata janë të garantuar të bëjnë kopje rezervë për veten e tyre dhe të krijojnë "kopje rezervë" për zhvillim të mëtejshëm.

Si rezultat, përdoruesit vuajnë nga ngadalësimi i bazës së të dhënave gjatë krijimit të një "backup" të madh, veçanërisht nëse kjo bazë të dhënash përmban gjëra të tilla si skedarë të ndryshëm të bashkangjitur, arkiva dhe dokumente nga letra. Tabela të tilla me skedarë mund të përmbajnë lehtësisht qindra gigabajt. Dhe ato mund të përjashtohen në PostgreSQl duke krijuar një "backup", në këtë mënyrë të vogël në madhësi dhe me të gjithë funksionalitetin në të njëjtën kohë.

Në këtë mënyrë ne nuk i mbingarkojmë pajisjet e rrjetit, nuk e bllokojmë kanalin dhe shpenzojmë shumë më pak kohë duke krijuar një "backup" të tillë

Në fund të gjithë fitojnë! Të dy përdoruesit, programuesit dhe administratorët flenë të qetë.

Në këtë artikull, ne shqyrtuam vetëm ndryshimet themelore midis PostgreSQl dhe MS SQL (ka të tjera), por kur vendosni për një zgjedhje në favor të një ose një tjetër DBMS, artikulli duhet të ndihmojë!

Suksese kolege!

P.S. Tani jam duke punuar në një kurs të ri "1C dhe PostgreSQL" (Tashmë në fazën e regjistrimit, prisni, së shpejti!)

Përshëndetje, Bogdan.

Bazat e të dhënave relacionale janë përdorur për një kohë të gjatë. Ato janë bërë të njohura për shkak të sistemeve të menaxhimit që zbatojnë modelin relacional aq mirë sa është mënyra më e mirë për të punuar me të dhënat, veçanërisht për aplikacionet dhe shërbimet kritike për misionin.

MySQL ka qenë rreth e rrotull për një kohë mjaft të gjatë dhe ka dëshmuar se është një zgjidhje e shkëlqyer Postgresql erdhi në treg përafërsisht në të njëjtën kohë, por ofron mjaft funksione dhe aftësi interesante, falë të cilave po fiton me shpejtësi popullaritet. Në këtë artikull do të përpiqemi të krahasojmë MySQL me Postgresql, të krahasojmë ndryshimet kryesore midis këtyre sistemeve, të zbulojmë se si funksionojnë ato dhe të përpiqemi të kuptojmë se cili sistem do të jetë më i mirë për projektin tuaj.

Bazat e të dhënave janë krijuar për ruajtje të strukturuar dhe akses të shpejtë në të dhëna të ndryshme. Çdo bazë të dhënash, përveç vetë të dhënave, duhet të ketë një model specifik operimi sipas të cilit do të kryhet përpunimi i të dhënave. Për të menaxhuar bazat e të dhënave, përdoren DBMS ose sisteme të menaxhimit të bazës së të dhënave, programe të tilla përfshijnë MySQL dhe Postgresql.

Sistemet e menaxhimit të bazës së të dhënave relacionale lejojnë që të dhënat të vendosen në tabela duke lidhur rreshta nga tabela të ndryshme dhe duke lidhur kështu të dhëna të ndryshme, të kombinuara logjikisht. Përpara se të ruani të dhëna, duhet të krijoni tabela të një madhësie të caktuar dhe të specifikoni një lloj të dhënash për secilën kolonë. Kolonat përfaqësojnë fushat e të dhënave dhe vetë të dhënat vendosen në rreshta. Të dy sistemet e menaxhimit të bazës së të dhënave, MySQL vs Postgresql, janë relacionale. Më tej do të shikojmë më në detaje se si ndryshojnë të dy programet. Tani le të kalojmë në një shqyrtim më të detajuar.

Histori e shkurtër

MySQL

Zhvillimi i MySQL filloi në vitet '90. Lëshimi i parë i brendshëm i bazës së të dhënave u bë në 1995. Gjatë kësaj kohe, disa kompani po zhvillonin programin. Zhvillimi filloi nga kompania suedeze MySQL AB, e cila u ble nga Sun Microsystems, e cila vetë u bë pronë e Oracle. Për momentin, që nga viti 2010, Oracle e ka zhvilluar atë.

Postgresql

Zhvillimi i Postrgresql filloi në vitin 1986 në Universitetin e Kalifornisë, Berkeley. Zhvillimi zgjati pothuajse tetë vjet, më pas projekti u nda në dy pjesë: baza e të dhënave komerciale IIlustra dhe projekti plotësisht falas Postrgesql, i cili është zhvilluar nga entuziastët.

Ruajtja e të dhënave

MySQL

MySQL është një bazë të dhënash relacionale, motorë të ndryshëm përdoren për të ruajtur të dhënat në tabela, por puna me motorët është e fshehur në vetë sistemin. Motori nuk ndikon në sintaksën e kërkesave dhe ekzekutimin e tyre. Motorët kryesorë të mbështetur janë MyISAM, InnoDB, MEMORY, Berkeley DB. Ato ndryshojnë në mënyrën se si shkruhen të dhënat në disk, si dhe në metodat e leximit të tij.

Postgresql

Postgresql është një bazë të dhënash objekt-relacionale që funksionon vetëm në një motor - motorin e ruajtjes. Të gjitha tabelat përfaqësohen si objekte, ato mund të trashëgohen dhe të gjitha veprimet me tabela kryhen duke përdorur funksione të orientuara drejt objektivit. Ashtu si në MySQL, të gjitha të dhënat ruhen në disk, në skedarë të renditur posaçërisht, por struktura e këtyre skedarëve dhe të dhënat në to janë shumë të ndryshme.

Standardi SQL

Pavarësisht nga sistemi i menaxhimit të bazës së të dhënave të përdorur, SQL është një gjuhë e standardizuar e pyetjeve. Dhe ai mbështetet nga të gjitha zgjidhjet, madje edhe MySQL ose Postgresql. Standardi SQL u zhvillua në vitin 1986 dhe gjatë kësaj kohe tashmë janë lëshuar disa versione.

MySQL

MySQL nuk i mbështet të gjitha veçoritë e reja të standardit SQL. Zhvilluesit zgjodhën këtë rrugë zhvillimi për ta mbajtur MySQL të lehtë për t'u përdorur. Kompania përpiqet të përmbushë standardet, por jo në kurriz të thjeshtësisë. Nëse ndonjë veçori mund të përmirësojë përdorshmërinë, atëherë zhvilluesit mund ta zbatojnë atë si zgjerimin e tyre pa i kushtuar vëmendje standardit.

Postgresql

Postgresql është një projekt me kod të hapur, ai është zhvilluar nga një ekip entuziastësh dhe zhvilluesit përpiqen të përputhen me standardin SQL sa më shumë që të jetë e mundur dhe të zbatojnë të gjitha standardet më të fundit. Por e gjithë kjo vjen në kurriz të thjeshtësisë. Postgresql është shumë kompleks dhe për këtë arsye nuk është aq popullor sa MySQL.

Aftësitë përpunuese

Ndryshime të tjera midis postgresql dhe mysql dalin nga paragrafi i mëparshëm: aftësitë dhe kufizimet e përpunimit të të dhënave. Natyrisht, pajtueshmëria me standardet më të reja sjell aftësi më të reja.

MySQL

Kur ekzekuton një kërkesë, MySQL ngarkon të gjithë përgjigjen e serverit në kujtesën e klientit për sasi të mëdha të dhënash, kjo mund të mos jetë shumë e përshtatshme. Në thelb, Postgresql është superior ndaj Mysql për sa i përket funksioneve, ne do të shohim se cilat prej tyre më pas.

Postgresql

Postgresql mbështet përdorimin e kursorëve për të lundruar nëpër të dhënat e marra. Ju merrni vetëm një tregues, e gjithë përgjigja ruhet në memorien e serverit të bazës së të dhënave. Ky tregues mund të ruhet ndërmjet sesioneve. Ai mbështet ndërtimin e indekseve për disa kolona tabelash në të njëjtën kohë. Përveç kësaj, indekset mund të jenë të llojeve të ndryshme përveç hash dhe b-tree, GiST dhe SP-GiST janë të disponueshme për të punuar me qytete, GIN për kërkim teksti, BRIN dhe Bloom.

Postgresql mbështet shprehjet e rregullta në pyetje, pyetje rekursive dhe trashëgimi të tabelës. Por ka disa kufizime, për shembull, mund të shtoni vetëm një fushë të re në fund të tabelës.

Performanca

Bazat e të dhënave duhet të optimizohen për mjedisin në të cilin do të punoni. Historikisht, MySQL u fokusua në performancën maksimale dhe Postgresql u zhvillua si një bazë të dhënash me një numër të madh cilësimesh dhe sa më shumë që të ishte e mundur në përputhje me standardin. Por me kalimin e kohës, Postgresql ka marrë shumë përmirësime dhe optimizime.

MySQL

Në shumicën e rasteve, një tabelë InnoDB përdoret për të organizuar punën me një bazë të dhënash në MySQL, kjo tabelë është një pemë B me indekse. Indekset ju lejojnë të merrni të dhëna nga disku shumë shpejt dhe kërkojnë më pak operacione të diskut. Por skanimi i një peme kërkon gjetjen e dy indekseve, dhe kjo tashmë është e ngadaltë. E gjithë kjo do të thotë që MySQL do të jetë më i shpejtë se Postgresql vetëm kur përdorni një çelës primar.

Postgresql

Të gjitha informacionet e kokës së tabelave Postgresql janë të vendosura në RAM. Nuk mund të krijosh një tabelë që nuk ka memorie. Regjistrimet e tabelës janë renditur sipas indeksit, kështu që ju mund t'i rikuperoni ato shumë shpejt. Për lehtësi më të madhe, mund të aplikoni indekse të shumta në një tabelë.

Në përgjithësi, PostgreSQL është më i shpejtë, me përjashtim të përdorimit të çelësave primar. Le të shohim disa teste me operacione të ndryshme:

Llojet e të dhënave

Një nga pikat kryesore të të dy bazave të të dhënave janë llojet e të dhënave të mbështetura që mund të përdorni. Meqenëse të dyja zgjidhjet përpiqen të përputhen me sintaksën SQL, ato kanë grupe të ngjashme, por megjithatë ndryshojnë në disa mënyra.

MySQL

MySQL mbështet llojet e mëposhtme të të dhënave:

TINYINT: numër i plotë shumë i vogël.;
I VOGLA: tërësi e vogël;
MESIM: e tërë me madhësi mesatare;
INT: e tëra është me madhësi normale;
I MADH: tërësi e madhe;
NOTU: numër i nënshkruar me një pikë lundruese me saktësi të vetme;
DYFISHTE, SAKTËSIA E DYFISHTE, REAL: numër me pikë lundruese me saktësi të dyfishtë të nënshkruar
DHJETOR, NUMERIK: numër i nënshkruar me pikë lundruese;
DATA: data e;
DATA KOHA: kombinimi i datës dhe kohës;
STAMP KOHORE: vula kohore;
KOHA: koha;
VITI: viti në formatin YY ose YYYY;
CHAR: varg me madhësi fikse, i mbushur djathtas me hapësira në gjatësi maksimale;
VARCHAR: varg me gjatësi të ndryshueshme;
TINYBLOB, TINYTEXT: të dhëna binare ose tekstuale me një gjatësi maksimale prej 255 karaktere;
BLOB, TEKST: të dhëna binare ose tekstuale me një gjatësi maksimale prej 65535 karaktere;
MEDIUMBLOB, MESIMET: tekst ose të dhëna binare;
LONGBLOB, TEKST I GJATË: tekst ose të dhëna binare maksimumi 4294967295 karaktere të gjata;
ENUM: numërimi;
SET: turmave.

Postgresql

Llojet e fushave të mbështetura në Postgresql janë mjaft të ndryshme, por ato ju lejojnë të regjistroni saktësisht të njëjtat të dhëna:

bigint: numër i plotë 8 bajt i nënshkruar;
serial i madh: numër i plotë 8 bajt i shtuar automatikisht;
pak: varg binar me gjatësi fikse;
pak të ndryshme: varg binar me gjatësi të ndryshueshme;
boolean: flamuri;
kuti: drejtkëndësh në një aeroplan;
bajt: të dhëna binare;
karaktere të ndryshme: varg karakteresh me gjatësi fikse;
personazhi:
cidri: Adresa e rrjetit IPv4 ose IPv6;
rrethi: rreth në një aeroplan;
datë: data kalendarike;
saktësi e dyfishtë: numër i pikës lundruese me saktësi të dyfishtë;
inet: Adresa e internetit IPv4 ose IPv6;
numër i plotë: numër i plotë i nënshkruar 4 bajt;
intervali: periudha;
linjë: një vijë e drejtë e pafundme në një plan;
lseg: segment në një aeroplan;
macaddr: Adresa mac;
para: vlerë monetare;
rrugë: shteg gjeometrik në një aeroplan;
pika: pika gjeometrike në një rrafsh;
shumëkëndësh: shumëkëndësh në një aeroplan;
reale: numër i vetëm me pikë lundruese me saktësi;
i vogël: numër i plotë dy bajtë;
serial: numër i plotë katër-bit i shtuar automatikisht;
teksti: varg karakteresh me gjatësi të ndryshueshme;
koha: Kohët e ditës;
vula kohore: Data dhe ora;
tsquery: pyetja e kërkimit të tekstit;
tsvector: dokumenti i kërkimit të tekstit;
uuid: identifikues unik;
xml: të dhëna XML.

Siç mund ta shihni, ka më shumë lloje të dhënash në Postgresql dhe ato janë më të larmishme ka lloje fushash për disa lloje të dhënash që MySQL nuk i ka. Dallimi midis MySQL dhe Postgresql është i dukshëm.

Zhvillimi

Të dy projektet janë me burim të hapur, por zhvillohen ndryshe. Jo të gjithë e pëlqejnë zhvillimin e MySQL. Dhe këtu një krahasim i mysql dhe postgresql jep shumë ndryshime.

MySQL

Baza e të dhënave MySQL po zhvillohet nga Oracle dhe ka zëra se kompania synon të ngadalësojë zhvillimin e motorit. U krijuan shumë forks të projektit, duke përfshirë një pirun të MariaDB nga zhvilluesi i MySQL origjinal. Por ende zhvillimi mbetet i ngadaltë.

Postgresql

Siç u përmend në fillim të artikullit, zhvillimi filloi në Universitetin e Berkeley. Pastaj ajo u transferua në një kompani tregtare. Programi aktualisht është duke u zhvilluar nga një grup i pavarur programuesish dhe bordi i disa kompanive. Versionet e reja lëshohen në mënyrë mjaft aktive dhe marrin gjithnjë e më shumë veçori të reja.

konkluzionet

Në këtë artikull, ne krahasuam mysql dhe postgresql, shikuam ndryshimet kryesore midis të dy sistemeve të menaxhimit të bazës së të dhënave dhe u përpoqëm të kuptonim se cili është më i mirë, postgresql ose mysql. Në përgjithësi, Postgresql është më i miri për sa i përket aftësive, por është kompleks dhe nuk mund të përdoret kudo. MySQL është më e thjeshtë, por nuk mbështet disa veçori interesante. Cilën bazë të dhënash do të zgjidhni për projektin tuaj? Pse ajo? Shkruani në komente!

Për të përfunduar videon që përshkruan aftësitë dhe perspektivat e Postgresql: