robo 3t formerly robomongo tutorial
Allt du behöver veta om Robo 3T - Tidigare Robomongo:
I juni 2017 utsågs Robomongo med ett helt nytt namn som heter ”Robo 3T”. Detta är lanseringen av Robo 3T 1.1-version som stöds av 3.4-versionen av MongoDB.
Läs igenom => Serie med detaljerade MongoDB-handledning
Beslutet att byta namn har tagits mot bakgrund av det faktum att programvaran har genomgått några grundläggande förändringar och har förbättrats mycket med avseende på buggar och fel .
Den framträdande förändringen som måste nämnas är att företaget bytte namn från Robomongo till Robo 3T på grund av vissa förändringar i produktens varumärke.
Du kan hänvisa här för mer information om denna oro.
Vad du kommer att lära dig:
- Vad på jorden handlar det här Robo 3T-verktyget om?
- Varför Robo 3T?
- Om MongoDB
- Förord
- Förmåner för MongoDB över typiska RDBMS
- Varför MongoDB över RDBMS?
- Områden där MongoDB kan användas
- Varför kallas MongoDB som en NoSQL-databas?
- Datamodellering i MongoDB
- Omfattande kontrast mellan SQL och NoSQL MongoDB
- Kontrast mellan SQL- och MongoDB-uttalanden
- Teoretisk översikt över skillnader
- Dialektskillnaden: Språken
- SQL DBMS
- NoSQL DBMS
- Skalbarhetskontrast mellan SQL och NoSQL DBMS
- Data struktur
- Slutsats
- Rekommenderad läsning
Vad på jorden handlar det här Robo 3T-verktyget om?
Robo 3T är ett gratis och lätt GUI för MongoDB. Det är ett MongoDB-hanteringsverktyg som har en skalcentrerad tvärplattform och stöds av JSON dvs. JavaScript-objektnotering. Det här verktyget är inte typiskt för MongoDB: s andra administrativa verktyg för användargränssnittet, dvs dess skal kan bli inbäddat i Mongo Shell med mycket åtkomst i både Mongo CLI och Mongo GUI.
Med hjälp av detta mongoskal kan en användare visa, redigera och ta bort mongodokument. Dessutom är Robo 3T ett frivilligt open source-projekt och det är helt gratis för allmänheten.
vad är det bästa programmet för att rengöra din dator
Det kan spridas på nytt och kan också ändras på nytt genom att följa TOS i Allmän allmän licensversion 3, som har publicerats av Free Software Foundation.
Denna programvara har utfärdats och kan distribueras i syfte att hjälpa människor som kan få hjälp av den, det är därför det inte finns någon garanti för att grossisera den, enligt reglerna från GNU.
För mer information om GNU kan du kolla in GNU-licenser
Varför Robo 3T?
Robo 3T är en gratis och maskinvänlig programvara som använder ett litet antal resurser som finns tillgängliga på en maskin. Det är mycket uppskattat och erkänt som det världsberömda projektet med högsta framgångsgrad när det gäller att ge bästa resultat.
Framför allt, av Robo 3T, behöver användaren inte gå igenom den röriga proceduren att använda tabeller och rader, som vanligtvis används i rationella databaser. Till skillnad från dem är den byggd på arkitektur från Mongo-samlingar och Mongo-dokument.
Branscher som använder Robo 3T
Om MongoDB
MongoDB är skapad som en öppen källkodsdatabas som stöder Mongo-dokumentation, det är därför det sägs vara en dokumentdatabas. Som vi nämnde tidigare är det en arkitektur för Mongo-samlingar och -dokument, där databasen innehåller samlingar, som så småningom innehåller Mongo-dokument i dem.
Antalet fält och storleken varierar från ett Mongo-dokument till ett annat. Ramverket för MongoDB är baserat på Compiler-språk C ++.
Den föreslagna handledningen klargör varje koncept i detalj och skulle ge en tydlig förståelse för metoderna och förfarandena för att skapa och hantera en mycket effektiv och användarvänlig databas.
Det kommer att göras genom att hålla ett öga på att hålla konceptuell hantering av MongoDB för användare som vill lära sig det på ett mycket enklare sätt som möjligt. I slutet av denna omfattande guide skulle användaren kunna testa sin expertis i ett praktiskt skede.
Förord
Om DB:
Databasen är bärare av samlingar. DB i ditt system innehåller flera uppsättningar filer. MongoDB har kapacitet att bära flera databaser samtidigt. Det säkerställer enkel skalbarhet och effektivt utförande.
Vad är samlingen?
I MongoDB är samlingen ett paket med mongodokument.
Det är detsamma som RDBMS-tabellen i typiska databashållare. Samlingen i MongoDB innehåller inte något slags schema och finns i en enda databas. Mongo-dokument som finns i samlingar har olika fält. Vanligtvis har mongodokument i samlingar analoga funktioner.
Vad är Mongo-dokumentet?
Mongo-dokument är samlingsbärare och har dynamiskt schema, dvs Mongo-dokument är inte bundna till att ha samma paket med fält eller arkitekturer. De är programmerade som nyckel-värdepar.
Ett exemplar av Mongo-dokumentet:
Följande utdrag är en illustrativ mongodokumentstruktur för bloggen, som visar nyckel-värdeparet av det med kommatecken i instanser.
{ _id: ObjectId(“53a99ad6444c11ac2758a5d6”) title: 'Robo 3T Tutorial', description: 'MongoDB is no sql database', by: 'Software Testing Help', url: 'https://www.softwaretestinghelp.com', tags: ('mongodb', 'database', 'NoSQL'), likes: 1000, comments: ( { user: “john25”', message: 'Welcome to Software Testing Help', dateCreated: new Date(2018,8,2,5,15), like: 5 }, { user: “kevin12”, message: 'Welcome to MongoDB', dateCreated: new Date(2018,8,5,10,45), like: 10 } ) }I kodavsnittet är _id ett hexadecimalt tal som totalt har 12 byte. Det bekräftar exklusiviteten i mongodokumentet. Användaren måste lägga till _id under införandet av ett mongodokument. Om användaren inte gör det väljer MongoDB auto distinkt ID för varje mongodokument.
Under tiden, av 12 byte, är de första fyra byten reserverade för en aktuell tidsstämpel, tre bredvid dessa fyra är reserverade för maskin-id, två bredvid dessa tre är reserverade för en serverprocess och äntligen utelämnas tre byte används som ett värde som ökar.
Förmåner för MongoDB över typiska RDBMS
Vanligtvis är Schemat för RDBMS utformat på ett sådant sätt att det visar antalet tabeller och deras förhållanden mellan dem. Under tiden, som nämnts tidigare, finns det inget relationsschema närvarande i MongoDB.
Låt oss diskutera varför MongoDB är ett bättre val för dataforskare framför typiska RDBMS:
- Först och främst saknar MongoDB schema. Mongo-dokumenten är bärare av samlingar och antal fält och storleken varierar från ett Mongo-dokument till ett annat.
- Det finns en tydlig arkitektur för ett enda objekt i MongoDB.
- Det saknar komplex sammanfogning.
- Den har omfattande frågeförmåga på grund av närvaron av egenskapen som säger att mongo-dokument har förmåga till dynamiska frågor med hjälp av dokumentbaserat frågespråk som är effektivt som MySQL.
- Det kan göra tuning.
- Den har den enklaste skalbarheten.
- För konvertering och kartläggning finns det inget behov av objekt.
- Få åtkomst till data snabbare än vanliga DBMS.
Varför MongoDB över RDBMS?
MongoDB har dokumentorienterad lagring där data bearbetas i paketet med JSON-formade dokument.
Dessutom kan indexet fördelas på vilket attribut som helst. Det säkerställer omedelbar tillgänglighet och kan göra enorma repliker. Det kan delas automatiskt och ha omfattande frågor.
Framför allt kan användaren få professionellt stöd från MongoDB.
Områden där MongoDB kan användas
MongoDB är framtiden eftersom big data är framtiden. MongoDB behandlar effektivt big data.
Det har förmågan att effektivt hantera och genomföra innehåll på ett ställe. MongoDB är det bästa alternativet att använda i mobila och sociala medier. Det fungerar som ett datahubb och hanterar användardata som bäst.
Varför kallas MongoDB som en NoSQL-databas?
Till skillnad från RDBMS, där användaren måste lära sig MySQL, kräver MongoDB inte att användaren ska ha massor av MySQL-kunskap för att börja arbeta eller förlita sig på någon annan att arbeta med databas för dem.
MongoDB är inte en rationell databas, därför kallas den som en NoSQL-databas. Det ger en suck av avkoppling för sina användare på grund av dess mindre komplexa arkitektur.
Det finns ingen användning av poster som måste bindas av samma kolumnnamn och -typer och de som kretsar kring tabellen. Figurerna nedan kommer att förklara allt. Dessa två utdrag är exempel på de två tabellerna, där en tillhör kunden och den andra tillhör order.
I båda tabellerna finns det en ömsesidig relation.
Kundtabell
| Kundnummer | Köparens namn | OrderID |
|---|---|---|
| Primärnyckel | Primärnyckel | |
| 1 | Adam Gilchrist | 1 |
| två | Rickey Ponting | två |
| 3 | Shane Warne | 3 |
Beställ tabell
| OrderID | Produkt | Kvantitet |
|---|---|---|
| 1 | iPhone X | 5 |
| två | Samsung S9 | 10 |
| 3 | HP Pavilion x360 | femton |
I MongoDB finns det inga rationella egenskaper som RDBMS. Ge en glimt av dessa två utdrag.
Kundtabell
| Kund-ID 01 | Köparens namn Adam Gilchrist | BeställningsID 001 | Stad USA |
| Kund-ID 02 | Köparens namn Rickey Ponting | BeställningsID 002 | Statusprivilegium |
| Kund-ID 03 | Köparens namn Shane Warne | BeställningsID 003 |
Beställ tabell
| BeställningsID 001 | Produkt iPhone X | Kvantitet 5 | Leveransdatum 14 augusti 2018 |
| BeställningsID 002 | Produkt Samsung S9 | Kvantitet 10 | |
| BeställningsID 003 | Produkt HP Pavilion x360 | Kvantitet femton |
Därför, i NoSQL, är det första man måste fundera över frånvaron av kolumner med specifika kolumnnamn. Dessutom finns det ett nyckel-värdepar i alla fält. För det andra, i kundtabellen är de första tre nycklarna och raderna lika och den fjärde, dvs. status och stad skiljer sig från de två första raderna och lutar inte till den tredje raden.
Under tiden, i tabellen som tillhör orderdetaljerna, har andra och tredje raden värden som inte har något samband med den fjärde kolumnen.
I ett nötskal gör alla dessa egenskaper NoSQL, det bästa valet jämfört med typiska DBMS. Världen revolutionerar och tekniken förändras stadigt med den. I denna snabba era behöver affärsvärlden de snabbaste lösningarna för sin programvara.
Med hjälp av DBMS som MongoDB, som är en NoSQL DB, kan snabbare vändningstid uppnås på grund av dess mindre komplexitet jämfört med RDBMS. När vi måste granska de ansträngningar, potential, tid och pengar som man måste bära när man använder RDBMS, kommer MongoDB över det på nolltid.
Datamodellering i MongoDB
Data som finns i MongoDB har det enklaste schemat. En typisk SQL DBMS där en användare måste deklarera schema för en tabell innan insättning av data påbörjas.
Som vi studerade är MongoDBs samlingar dokumentorienterade och binder inte användaren till den typiska dokumentstrukturen som RDBMS. Flexibilitet är det mest kraftfulla attributet för MongoDB, att använda det över RDBMS.
En användare måste överväga följande punkter för att kunna göra datamodellering i MongoDB:
- Ta reda på de avgörande behoven för den önskade applikationen. För detta ändamål måste man ge en överblick över affärsbehov av tillämpning och räkna ut önskad data och dess typer för den. Efter detta måste man se till att dokumentarkitekturen räknas ut efter syftet.
- Ta reda på hämtningsmönstren för data. Om det finns ett behov av komplex frågeanvändning, gå till index i datamodellen för att säkerställa effektiviteten i frågorna.
- Sist, men inte minst, är att säkerställa insatser, uppdateringar och raderingar som händer i DBMS. Detta kan säkerställas genom att omvärdera användningen av index och inbyggd skärning om den måste finnas i datamodelleringsdesignen. Detta är mycket viktigt för att förbättra effektiviteten i MongoDB: s miljö.
Omfattande kontrast mellan SQL och NoSQL MongoDB
Skillnaden mellan termer och syntax
| SQL-termer / syntax | MongoDB-villkor / syntax |
|---|---|
| Databas | Databas |
| Tabell | Samling |
| Rad | Dokumentera |
| Kolumn | Fält |
| Index | Index |
| Tabell | $ lookup eller inbäddade dokument |
| Transaktioner | Transaktioner |
Flera DBMS och deras körbara filer
| Databas namn | Databasserver | Databasklient |
|---|---|---|
| MySQL | Mysqld | Mysql |
| Orakel | Orakel | Sqlplus |
| MongoDB | Mongod | Mongo |
| DB2 | DB2-server | DB2-klient |
| Informix | IDS | DB-Access |
Precedens och exempel:
Tabellerna ovan illustrerar termer, syntax, koncept och uttalanden för flera typer av DBMS.
Låt oss överväga exemplen på SQL och MongoDB för ytterligare förtydliganden.
Låt oss överväga ett exempel på SQL, som har tabellnamnfolk, medan MongoDB har en samling namnpersoner som är samma som tabeller med SQL.
MongoDBs samling har följande prototyp:
{ _id: ObjectId(“59z12ad6444n59ac2758a5x7”), user_id:'john25', age: 25, status: 'A' }Kontrast mellan SQL- och MongoDB-uttalanden
SKAPA OCH ÄNDRA
| SQL Schema-uttalanden | Uttalanden om MongoDB-schema |
|---|---|
| SKAPA TABELL anställd ( id MEDIUMINT INTE NULL AUTO_INCREMENT, user_id Varchar (30), åldersnummer, status char (1), PRIMÄR NYCKEL (id) ) | db.employee.insertOne {{ id: 'john25', namn: john, status: 'A' }) Du kan dock också uttryckligen skapa en samling: db.createCollection (“anställd”) |
| ALTER TABLE anställd LÄGG TILL join_date DATETIME | db.anställd.updateMany ( {}, {$ set: {last_name: Adam}} ) |
| ALTER TABLE anställd DROP COLUMN join_date | db.anställd.updateMany ( {}, {$ unset: {“Ålder”: “”}} ) |
FÖRA IN
| SQL INSERT-uttalanden | Uttalanden från MongoDB insertOne () |
|---|---|
| INSERT INTO-anställd (user_id, ålder, status) VÄRDEN ('test001', Fyra fem, 'TILL') | db.medarbetare.insertOne ( { user_id: “john25”, ålder: 45, status: “A”} ) |
Vissa SELECT-frågor av SQL och MongoDB
| SQL SELECT-uttalanden | MongoDB hitta () uttalanden |
|---|---|
| VÄLJ * FRÅN anställd | db.medarbetare.find () |
| VÄLJ id, användar ID, status FRÅN anställd | db.anställd.find ( {}, {user_id: 1, status: 1} ) |
| VÄLJ användar-ID, status FRÅN anställd | db.anställd.find ( {}, {user_id: 1, status: 1, _id: 0} ) |
| VÄLJ * FRÅN anställd VAR status = 'A' | db.anställd.find ( {status: “A”} ) |
UPDATE Uttalanden om SQL och MongoDB
| SQL Update-uttalanden | Uttalanden från MongoDB updateMany () |
|---|---|
| UPPDATERA anställd SET-status = 'C' VAR ålder> 25 | db.anställd.updateMany ( {ålder: {$ gt: 25}}, {$ set: {status: 'C'}} ) |
| UPPDATERA anställd SET ålder = ålder + 3 VAR status = 'A' | db.anställd.updateMany ( {status: 'A'}, {$ inc: {age: 3}} ) |
Ta bort poster av SQL och MongoDB
| SQL Radera uttalanden | Uttalanden från MongoDB deleteMany () |
|---|---|
| RADERA FRÅN anställd VAR status = 'D' | db.employee.deleteMany ({status: 'D'}) |
| RADERA FRÅN anställd | db.employee.deleteMany ({}) |
Teoretisk översikt över skillnader
När en användare får ett behov, där han måste gå igenom en katarsis där han måste ta ett beslut från massor av gott om alternativ framför sig, måste han välja att antingen han måste fylla för RDBMS (SQL) eller Icke-rationell DBMS (NoSQL).
Det finns vissa skillnader, och genom att fundera på dem kan en motsvarande användare fatta ett hållbart beslut enligt hans behov.
Låt oss få en översikt över de stora bildkollisionerna mellan dessa två olika datastrukturer.
Dialektskillnaden: Språken
Låt oss ta ett exempel på församlingen, där ingen är tvåspråkig, varje person talar samma språk och det är den enda formen för kommunikation mellan dem.
I ett nötskal står det att detta är det enda mediet de förstår varandra från. Om staden plötsligt blir utsatt för ett annat helt nytt språk, måste det vara anarkiskt för dem att anta det på ett ögonblick, eftersom de inte förstår det eller bara ett fåtal kanske förstår det.
Tänk nu på ett exempel på en annan stad där en gemenskap är tvåspråkig och de talar flera språk. Varje person som bor i samhället interagerar med andra på olika sätt och det finns inget universellt sätt att kommunicera där. Det är som om en familj är annorlunda än de andra, och det påverkar dem inte på något sätt.
Dessa enkla exempel förklarar kärnkonceptet för SQL och MongoDB.
Låt oss se kontrasten !!
SQL DBMS
SQL DBMS har strukturerat frågespråk, dvs MySQL för datahantering.
Det råder ingen tvekan om hur starkt MySQL-språket är, det är det mest använda bland användarna av DBMS och det är mångsidigt att använda. För komplex datahantering är det det bästa valet. Men det finns också en begränsning av det och det är dess styva schema.
På grund av dess komplexa schema kan man inte växla mellan flera strukturer, de måste bara hålla fast vid en struktur som de följer från början. Enligt det första exemplet skulle förändrad struktur vara densamma som att byta språk där alla bara vet en och på detta sätt skulle det skapa anarki och röra.
NoSQL DBMS
NoSQL DBMS utgör Dynamic Schema.
Ostrukturerad data kan enkelt lagras på flera sätt, dvs. det kan lagras som ett nyckel-värdepar eller kan vara en kolumn och dokumentorienterad. Detta kan förklaras ytterligare eftersom användaren skulle kunna skapa Mongo-dokument utan att vara begränsad till en fördefinierad struktur, till skillnad från det typiska DBMS.
Dokumenten skulle ha sin egen struktur som skulle vara unik i sitt slag. Fälten kan läggas till när som helst under processen och syntaksen varierar i varje annan databas.
Skalbarhetskontrast mellan SQL och NoSQL DBMS
SQL DB: er är skalbart vertikalt till skillnad från NoSQL, som är horisontellt skalbart.
Vertikalt skalbar innebär att data kan laddas på en enda server genom att öka RAM. Under tiden betyder horisontellt skalbar att flera servrar kan användas, dvs. öka trafiken med hjälp av skärning. Därför kan SQL DBMS vara kraftfull men NoSQL är bäst för att ändra datamängder.
Data struktur
SQL DBMS är baserat på tabeller medan NoSQL DB: er baseras på dokument, nyckel-värdepar, grafer och kolumneriktningar.
SQL DBMS är ett bra val för typiska datatransaktioner som bokföring och banksystem. Under stora data skulle NoSQL utmärka den rationella DBMS.
Typiska exempel av RDBMS inkluderar MySQL, Oracle, Maria DB och MS SQL Server. NoSQL-exempel inkluderar MongoDB, Neo4J, CouchDB, RavenDB Cassandra, HBase, BigTable och Redis.
Slutsats
Alla ovan nämnda detaljer läggs i ett nötskal för enkel förståelse.
MySQL: Pluspoängen
Nedan följer fördelarna med SQL-databaser:
- Gammalt är guld: MySQL är gammal, därför har den en ganska stark mark när det gäller enormt community och testning.
- Stabil : MySQL är stabil eftersom den har fler användare.
- Kompatibel : Det finns allmänt tillgängligt på alla större plattformar och ramar inklusive Win, Mac, BSD, Solaris och Linux. Flera språk har en anslutning till dem inklusive C ++, C #, Java , Perl, Pytonorm och PHP.
- Billig : MySQL är öppen källkod och kostnadsfritt.
- Replikerbarhet : Det kan replikeras bland mer än en nod.
- Sharding : MySQL har hög kapningsförmåga, vilket i sin tur gör det pålitligt för företag.
MongoDB: Pluspoängen
Det här är fördelarna med MongoDB:
- ManVänschema: Som nämnts tidigare gör dess dynamiska schema detmestflexibel DBMS för en användare.
- Skalbarhet : Dess horisontella skalbarhet hjälper till att minska arbetsbelastningen.
- Förvaltning : MongoDB kräver inget administrativt verktyg. Det är användarvänligt av både tillverkare och administratörer.
- Snabb : Dess frågor körs på nolltid.
- Flexibde : Dess dokument- och kolumneriktning gör det flexibelt och enkelt att använda DBMS för en användare.
Att vara slutanvändare, vad väljer du?
MySQL skulle vara rätt val för de användare och företag som behöver stela scheman och fördefinierade strukturer för sina företag.
Till exempel applikationer och programvara som behöver långa transaktioner, det vill säga de som faktiskt används i bank- och redovisningssystem. Systemen som har övervakningstjänster stöder MySQL DBMS.
Medan MongoDB skulle vara det bästa valet för företag som har riklig tillväxt och de skulle kräva mångsidiga scheman.
Om det är svårt att definiera schemat eftersom det ändras på nolltid, skulle MongoDBs dynamiska schema fungera bäst i denna situation. Detta tillstånd händer ofta i mobilappsindustrin, analytiska system och innehållshanteringssystem.
Detta var bara en introduktion för att få en antydan om vad den här handledningen skulle ge dig på lång sikt. Kolla in vår kommande handledning för att lära dig mer om installationsguiden för MongoDB på Windows.
PREV-handledning | NÄSTA självstudie
Rekommenderad läsning
- 20+ MongoDB-handledning för nybörjare: Gratis MongoDB-kurs
- Fördjupade förmörkningsövningar för nybörjare
- MongoDB Sharding Tutorial med exempel
- MongoDB Skapa databashandledning
- Distribution i MongoDB: Steg-för-steg-handledning
- MongoDB Skapa säkerhetskopia av databas
- Vad är MongoDB-replikering
- MongoDB Regular Expression $ regex med exempel