robo 3t formerly robomongo tutorial
Alt hvad du behøver at vide om Robo 3T - Tidligere Robomongo:
I juni 2017 blev Robomongo navngivet med et helt nyt navn kaldet “Robo 3T”. Dette er frigivelsen af Robo 3T 1.1-version understøttet af 3.4-versionen af MongoDB.
Læs igennem => Series of Detailed MongoDB Tutorials
Beslutningen om at ændre navnet er taget i lyset af det faktum, at softwaren havde været igennem nogle grundlæggende ændringer og er forbedret meget med hensyn til fejl og fejl .
Den fremtrædende ændring, der skal nævnes, er, at virksomheden skiftede navn fra Robomongo til Robo 3T på grund af nogle ændringer i produktets varemærke.
Du kan henvise her for mere information om denne bekymring.
Hvad du lærer:
- Hvad i alverden handler dette Robo 3T-værktøj om?
- Hvorfor Robo 3T?
- Om MongoDB
- Forord
- Fordele ved MongoDB over typiske RDBMS
- Hvorfor MongoDB over RDBMS?
- Områder, hvor MongoDB kunne bruges
- Hvorfor kaldes MongoDB som en NoSQL-database?
- Datamodellering i MongoDB
- Omfattende kontrast mellem SQL vs NoSQL MongoDB
- Kontrast mellem SQL- og MongoDB-udsagn
- Teoretisk oversigt over forskelle
- Dialektforskellen: sprogene
- SQL DBMS
- NoSQL DBMS
- Skalerbarhed Kontrast mellem SQL og NoSQL DBMS
- Datastrukturer
- Konklusion
- Anbefalet læsning
Hvad i alverden handler dette Robo 3T-værktøj om?
Robo 3T er en gratis og let GUI til MongoDB. Det er et MongoDB-styringsværktøj, der har en shell-centreret cross-platform og understøttes af JSON dvs. JavaScript-objektnotation. Dette værktøj er ikke typisk for MongoDBs andre administrative værktøjer til brugergrænseflade, dvs. dets shell kan blive indlejret i Mongo Shell med meget adgang i både Mongo CLI og Mongo GUI.
Ved hjælp af denne mongo-skal kunne en bruger se, redigere og slette mongo-dokumenter. Desuden er Robo 3T et frivilligt open source-projekt, og det er gratis for offentligheden.
software test bøger gratis download pdf
Det kunne videresprede og kunne også blive ændret ved at følge TOS i General Public License version 3, som er udgivet af Free Software Foundation.
Denne software er blevet offentliggjort og kunne distribueres med det formål at hjælpe folk, der kunne få hjælp fra den, det er derfor, den ikke har nogen garanti for engrossalg af den, i henhold til reglerne fra GNU.
For mere information om GNU kan du tjekke ud GNU-licenser
Hvorfor Robo 3T?
Robo 3T er en gratis og maskinevenlig software, der bruger et lille antal ressourcer, der er tilgængelige på en maskine. Det er meget værdsat og anerkendt som det verdensberømte projekt med det højeste succesforhold i at give prime output.
Frem for alt ved Robo 3T behøver brugeren ikke at gennemgå den rodede procedure ved at bruge tabeller og rækker, som typisk bruges i rationelle databaser. I modsætning til dem er det bygget på arkitektur Mongo samlinger og Mongo dokumenter.
Industrier, der bruger Robo 3T
Om MongoDB
MongoDB er lavet som en open source-database, der understøtter Mongo-dokumentation. Derfor siges det at være en dokumentdatabase. Som vi nævnte tidligere, er det en arkitektur for Mongo-samlinger og -dokumenter, hvor databasen indeholder samlinger, som til sidst bærer Mongo-dokumenter i dem.
Antallet af felter og størrelsen varierer fra et Mongo-dokument til et andet. Rammen for MongoDB er baseret på Compiler-sprog C ++.
Den foreslåede vejledning vil afklare hvert koncept i detaljer og vil skabe en klar forståelse af metoderne og procedurerne til at skabe og administrere en meget effektiv og brugervenlig database.
Det vil blive lavet ved at holde øje med at holde konceptuel håndtering af MongoDB for brugere, der ønsker at lære det på en meget enklere måde som muligt. I slutningen af denne omfattende guide vil brugeren være i stand til at teste sin ekspertise på et praktisk tidspunkt.
Forord
Om DB:
Databasen er bærer af samlinger. DB i dit system indeholder flere sæt filer. MongoDB har evnen til at bære flere databaser på én gang. Det sikrer let skalerbarhed og effektiv udførelse.
Hvad er samlingen?
I MongoDB er samlingen en pakke med mongo-dokumenter.
Det er det samme som RDBMS-tabellen i typiske databaseholdere. Samlingen i MongoDB indeholder ikke nogen form for skema og findes i en enkelt database. Mongo-dokumenter, der findes i samlinger, har forskellige felter. Normalt har mongo-dokumenter i samlinger analoge funktioner.
Hvad er Mongo-dokumentet?
Mongo-dokumenter er bærere af indsamling og har dynamisk skema, dvs. Mongo-dokumenter er ikke forpligtet til at have den samme pakke med felter eller arkitekturer. De er programmeret som nøgleværdipar.
Et eksemplar af Mongo-dokumentet:
Følgende uddrag er en illustrativ mongo-dokumentstruktur af bloggen, som viser nøgleværdipar af den i kommaer i tilfælde.
{ _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 uddraget er _id et hexadecimalt tal, der har 12 bytes i alt. Det klarer eksklusiviteten i Mongo-dokumentet. Brugeren skal tilføje _id under indsættelse af et mongo-dokument. Hvis brugeren ikke gør det, vælger MongoDB auto særpræg for hvert mongo-dokument.
I mellemtiden er ud af 12 byte de første fire byte reserveret til et aktuelt tidsstempel, tre ved siden af disse fire er reserveret til maskine-id, to ved siden af disse tre er forbeholdt en serverproces og til sidst de venstre ude tre byte bruges som en værdi, der øges.
Fordele ved MongoDB over typiske RDBMS
Typisk er skemaet for RDBMS designet på en sådan måde, at det viser antallet af tabeller og deres forhold mellem dem. I mellemtiden er der, som tidligere nævnt, ingen forholdsskema til stede i MongoDB.
Lad os diskutere, hvorfor MongoDB er et bedre valg for dataforskere end typiske RDBMS:
- Først og fremmest mangler MongoDB skema. Mongo-dokumenterne er indehaveren af samlinger og antal felter, og størrelsen varierer fra et mongo-dokument til et andet.
- Der er en klar arkitektur af et enkelt objekt i MongoDB.
- Det mangler kompleks sammenføjning.
- Det har omfattende forespørgselsevne på grund af tilstedeværelsen af ejendommen, der siger, at mongo-dokumenter har en evne til dynamiske forespørgsler ved hjælp af dokumentbaseret forespørgselssprog, der er effektivt som MySQL.
- Det kunne gøre tuning.
- Det har den nemmeste skalerbarhed.
- Til konvertering og kortlægning er der ikke behov for objekter.
- Få adgang til data hurtigere end typisk DBMS.
Hvorfor MongoDB over RDBMS?
MongoDB har dokumentorienteret lagring, hvor data behandles i pakken med JSON-stylede dokumenter.
Desuden kunne indekset tildeles på en hvilken som helst attribut. Det sikrer øjeblikkelig tilgængelighed og kan skabe enorme replikaer. Det kan deles automatisk og have rige forespørgsler.
Frem for alt kunne brugeren få professionel support fra MongoDB.
Områder, hvor MongoDB kunne bruges
MongoDB er fremtiden, da big data er fremtiden. MongoDB behandler effektivt big data.
Det har evnen til effektiv indholdsstyring og udførelse på et sted. MongoDB er den bedste mulighed at bruge i mobil- og socialmedieindustrien. Det fungerer som et datahub og administrerer brugerdataene bedst.
Hvorfor kaldes MongoDB som en NoSQL-database?
I modsætning til RDBMS, hvor brugeren skal lære MySQL, kræver MongoDB ikke sin bruger at have masser af MySQL-viden for at begynde at arbejde eller stole på en anden til at arbejde på en database for dem.
MongoDB er ikke en rationel database, derfor kaldes den som en NoSQL-database. Det giver et suk af afslapning til sine brugere på grund af dets mindre komplekse arkitektur.
Der er ingen brug af poster, der skal være bundet af de samme kolonnenavne og typer og dem, der drejer sig om bordet. Figurerne nedenfor forklarer det hele. Disse to uddrag er eksempler på de to tabeller, hvor den ene tilhører kunden og den anden tilhører ordrer.
I begge tabeller er der tilstedeværelsen af et gensidigt forhold.
Kundetabel
Kunde ID | Kundenavn | Ordre ID |
---|---|---|
Primærnøgle | Primærnøgle | |
1 | Adam Gilchrist | 1 |
to | Rickey Ponting | to |
3 | Shane Warne | 3 |
Bestil tabel
Ordre ID | Produkt | Antal |
---|---|---|
1 | iPhone X | 5 |
to | Samsung S9 | 10 |
3 | HP Pavilion x360 | femten |
Mens du er i MongoDB, er der ingen rationelle egenskaber som RDBMS. Giv et glimt af disse to uddrag.
Kundetabel
Kunde-ID 01 | Kundenavn Adam Gilchrist | BestillingsID 001 | By US |
Kunde-ID 02 | Kundenavn Rickey Ponting | BestillingsID 002 | Status privilegium |
Kunde-ID 03 | Kundenavn Shane Warne | BestillingsID 003 |
Bestil tabel
BestillingsID 001 | Produkt iPhone X | Antal 5 | Afsendelsesdato 14. august 2018 |
BestillingsID 002 | Produkt Samsung S9 | Antal 10 | |
BestillingsID 003 | Produkt HP Pavilion x360 | Antal femten |
Derfor er det første, man skal overveje i NoSQL, fraværet af kolonner med specifikke kolonnenavne. Der er desuden et nøgleværdipar i alle felter. For det andet i kundetabellen er de første tre nøgler og rækker ens og fjerde, dvs. status og by adskiller sig fra de to første rækker og er ikke tilbøjelige til den tredje række.
I mellemtiden har den anden og tredje række i tabellen, der hører til ordredetaljerne, værdier, der ikke har noget forhold til den fjerde kolonne.
I en nøddeskal gør alle disse egenskaber NoSQL, det bedste valg i forhold til typisk DBMS. Verden revolutionerer, og teknologien transformerer sig stadigt med den. I denne hurtige æra har erhvervslivet brug for de hurtigste løsninger til deres software.
Ved hjælp af DBMS som MongoDB, som er en NoSQL DB, kan den hurtigere omdrejningstid opnås på grund af dens mindre kompleksitet sammenlignet med RDBMS. Når vi skal gennemgå den indsats, potentiale, tid og penge, som man skal bære, mens man bruger RDBMS, kommer MongoDB over det på ingen tid.
Datamodellering i MongoDB
Data til stede i MongoDB har det enkleste skema. En typisk SQL DBMS, hvor en bruger skal erklære skema for en tabel, inden man begynder at indsætte data.
Som vi studerede, er MongoDBs samlinger dokumentorienteret og binder ikke brugeren til den typiske dokumentstruktur som RDBMS. Fleksibilitet er den mest magtfulde attribut for MongoDB, at bruge den over RDBMS.
En bruger skal overveje følgende punkter for at udføre datamodellering i MongoDB:
- Find ud af de afgørende behov for den ønskede applikation. Til dette formål skal man give et blik på forretningsbehov ved anvendelse og finde ud af de ønskede data og dens typer til det. Efter dette skal man sikre, at dokumentarkitekturen regnes ud i henhold til formålet.
- Find ud af dataens hentningsmønstre. Hvis der er behov for kompleks forespørgsel, skal du gå til indekser i datamodellen for at sikre effektiviteten af forespørgslerne.
- Sidst, men ikke mindst, er det at sikre indsatser, opdateringer og sletninger i DBMS. Dette kunne sikres ved at revurdere brugen af indekser og indbygget sharding, hvis det skal være til stede i datamodelleringsdesignet. Dette er meget vigtigt for at forbedre effektiviteten af MongoDBs miljø.
Omfattende kontrast mellem SQL vs NoSQL MongoDB
Forskellen mellem udtryk og syntaks
SQL-vilkår / syntaks | MongoDB-vilkår / syntaks |
---|---|
Database | Database |
Bord | Kollektion |
Række | Dokument |
Kolonne | Mark |
Indeks | Indeks |
Bord | $ opslag eller indlejrede dokumenter |
Transaktioner | Transaktioner |
Flere DBMS og deres eksekverbare filer
Database navn | Databaseserver | Databaseklient |
---|---|---|
MySQL | Mysqld | Mysql |
Oracle | Oracle | Sqlplus |
MongoDB | Mongod | Mongo |
DB2 | DB2-server | DB2-klient |
Informix | IDS | DB-Access |
Præcedens og eksempler:
Tabellerne ovenfor illustrerer termer, syntaks, koncept og udsagn for flere typer DBMS.
Lad os overveje eksemplerne på SQL og MongoDB for yderligere afklaringer.
Lad os overveje et eksempel på SQL, som har tabelnavne mennesker, mens MongoDB har en samling navnemennesker, der er det samme som SQL-tabeller.
MongoDBs samling har følgende prototype:
{ _id: ObjectId(“59z12ad6444n59ac2758a5x7”), user_id:'john25', age: 25, status: 'A' }
Kontrast mellem SQL- og MongoDB-udsagn
OPRET og ALTER
SQL-skemaerklæringer | MongoDB-skemaerklæringer |
---|---|
OPRET TABEL medarbejder ( id MEDIUMINT IKKE NULL AUTO_INCREMENT, user_id Varchar (30), aldersnummer, status char (1), PRIMÆR NØGLE (id) ) | db.employee.insertOne {{ id: 'john25', navn: john, status: 'A' }) Du kan dog også eksplicit oprette en samling: db.createCollection ('medarbejder') |
ALTER TABLE medarbejder TILFØJ join_date DATETIME | db.medarbejder.updateMany ( {}, {$ set: {last_name: Adam}} ) |
ALTER TABLE medarbejder DROP KOLONN join_date | db.medarbejder.updateMany ( {}, {$ unset: {“Age”: “”}} ) |
INDSÆT
SQL INSERT-erklæringer | Erklæringer fra MongoDB insertOne () |
---|---|
INDSÆT I MEDARBEJDER (user_id, alder, status) VÆRDIER ('test001', Fire, fem, 'TIL') | db.medarbejder.insertOne ( { user_id: “john25”, alder: 45, status: “A”} ) |
Nogle SELECT forespørgsler af SQL og MongoDB
SQL SELECT-udsagn | Erklæringer fra MongoDB find () |
---|---|
VÆLG * FRA medarbejder | db.medarbejder.find () |
VÆLG id, bruger ID, status FRA medarbejder | db.medarbejder.find ( {}, {user_id: 1, status: 1} ) |
VÆLG bruger_id, status FRA medarbejder | db.medarbejder.find ( {}, {user_id: 1, status: 1, _id: 0} ) |
VÆLG * FRA medarbejder HVOR status = 'A' | db.medarbejder.find ( {status: “A”} ) |
UPDATE udsagn om SQL og MongoDB
SQL-opdateringserklæringer | MongoDB updateMany () udsagn |
---|---|
OPDATER medarbejder SET status = 'C' HVOR alder> 25 | db.medarbejder.updateMany ( {alder: {$ gt: 25}}, {$ set: {status: 'C'}} ) |
OPDATER medarbejder SET alder = alder + 3 HVOR status = 'A' | db.medarbejder.updateMany ( {status: 'A'}, {$ inc: {age: 3}} ) |
Slet poster af SQL og MongoDB
SQL Slet udsagn | MongoDB deleteMany () udsagn |
---|---|
SLET FRA medarbejder HVOR status = 'D' | db.employee.deleteMany ({status: 'D'}) |
SLET FRA medarbejder | db.employee.deleteMany ({}) |
Teoretisk oversigt over forskelle
Når en bruger får et behov, hvor han skal gennemgå en katarsis, hvor han skal tage en beslutning ud fra mange rigelige muligheder foran ham, så skal han vælge, at han enten skal klumpe til RDBMS (SQL) eller Ikke-rationel DBMS (NoSQL).
Der er nogle forskelle, og ved at overveje dem kan en tilsvarende bruger tage en levedygtig beslutning i henhold til hans behov.
Lad os få et overblik over det store billede sammenstød mellem disse to forskellige datastrukturer.
Dialektforskellen: sprogene
Lad os tage et eksempel på township, hvor ingen er tosproget, hver person taler det samme sprog, og det er den eneste form for kommunikation blandt dem.
I en nøddeskal siger det, at dette er det eneste medium, hvorfra de forstår hinanden. Hvis byen pludselig bliver udsat for et andet helt nyt sprog, skal det være anarkisk for dem at vedtage det på et øjeblik, da de ikke forstår det, eller kun få kan forstå det.
Overvej nu et eksempel på en anden by, hvor et samfund er tosproget, og de taler flere sprog. Hver person, der bor i samfundet, interagerer forskelligt med andre, og der findes ingen universel måde at kommunikere på. Det er som om en familie er anderledes end de andre, og det påvirker dem ikke på nogen måde.
Disse enkle eksempler forklarer kernebegrebet SQL og MongoDB.
Lad os se kontrasten !!
SQL DBMS
SQL DBMS har struktureret forespørgselssprog, dvs. MySQL til databehandling.
Der er ingen tvivl om kraften i MySQL-sprog, det er det mest anvendte blandt brugerne af DBMS, og det er alsidigt at anvende. Til kompleks datahåndtering er det det bedste valg. Men der er også en begrænsning af det, og det er dets stive skema.
På grund af dets komplekse skema kan man ikke skifte mellem flere strukturer, de skal kun holde fast ved en struktur, som de følger fra begyndelsen. Ifølge det første eksempel ville skiftende struktur være det samme som at skifte sprog, hvor alle kun kender en, og på denne måde vil det skabe anarki og rod.
NoSQL DBMS
NoSQL DBMS udgør et dynamisk skema.
Ustrukturerede data kan let gemmes på flere måder, dvs. de kan lagres som et nøgleværdipar eller kunne være en kolonne og dokumentorienteret. Dette kunne forklares yderligere, da brugeren ville være i stand til at oprette Mongo-dokumenter uden at være begrænset til en foruddefineret struktur, i modsætning til den typiske DBMS.
Dokumenterne ville have deres egen struktur, der ville være unik i sin art. Felterne kan tilføjes når som helst under processen, og syntaksen varierer i hver anden database.
Skalerbarhed Kontrast mellem SQL og NoSQL DBMS
SQL DB'er er vertikalt skalerbare i modsætning til NoSQL, som er vandret skalerbar.
Lodret skalerbar betyder, at data kan indlæses på en enkelt server ved at øge RAM. I mellemtiden betyder vandret skalerbar, at flere servere kan bruges, dvs. øge trafikken ved hjælp af sharding. Derfor kunne SQL DBMS være stærk, men NoSQL er bedst til at ændre datasæt.
Datastrukturer
SQL DBMS er baseret på tabeller, mens NoSQL DB'er er baseret på dokumenter, nøgleværdipar, grafer og kolonneorientering.
SQL DBMS er et godt valg til typiske datatransaktioner som regnskab og banksystem. I mellemtiden, for big data, ville NoSQL fremhæve den rationelle DBMS.
Typiske eksempler af RDBMS inkluderer MySQL, Oracle, Maria DB og MS SQL Server. NoSQL eksempler inkluderer MongoDB, Neo4J, CouchDB, RavenDB Cassandra, HBase, BigTable og Redis.
Konklusion
Alle de ovennævnte detaljer er samlet i en nøddeskal for at gøre det let for dig.
MySQL: Plus-punkterne
Nedenfor er fordelene ved SQL-databaser:
- Gammel er guld: MySQL er gammel, og derfor har den en ganske stærk grund med hensyn til enormt samfund og test.
- Stabil : MySQL er stabil, da den har flere brugere.
- Kompatibel : Det er bredt tilgængeligt på alle større platforme og rammer inklusive Win, Mac, BSD, Solaris og Linux. Flere sprog har en forbindelse med dem inklusive C ++, C #, Java , Perl, Python og PHP.
- Billig : MySQL er open source og uden omkostninger.
- Kopierbarhed : Det kan reproduceres blandt mere end en node.
- Sharding : MySQL har høj sharding-kapacitet, og det gør det igen pålideligt for virksomhederne.
MongoDB: Plus-punkterne
Dette er fordelene ved MongoDB:
- MandVen ordning: Som nævnt før gør dens dynamiske skema detfor det mestefleksibel DBMS til en bruger.
- Skalerbarhed : Dens vandrette skalerbarhed hjælper med at reducere arbejdsbyrden.
- Ledelse : MongoDB kræver ikke noget administrativt værktøj. Det er brugervenligt af både producenter og administratorer.
- Hurtig : Dens forespørgsler bliver udført på ingen tid.
- Flexibdet : Dets dokument- og søjleretning gør det fleksibelt og let at bruge DBMS til en bruger.
At være slutbruger, hvad vælger du?
MySQL ville være det rigtige valg for de brugere og virksomheder, der har brug for stive skemaer og foruddefinerede strukturer for deres virksomheder.
For eksempel applikationer og software, der har brug for lange transaktioner, dvs. dem, der faktisk bruges i bank- og regnskabssystemer. Systemerne, der har overvågningstjenester, understøtter MySQL DBMS.
Mens MongoDB ville være det bedste valg for virksomheder, der har rigelig vækst, og de ville kræve alsidige skemaer.
Hvis det er vanskeligt at definere skemaet, da det ændres på ingen tid, ville MongoDBs dynamiske skema fungere bedst i denne situation. Denne tilstand forekommer ofte i mobilappbranchen, analytiske systemer og indholdsstyringssystemer.
Dette var kun en introduktion til at få et tip om, hvad denne tutorial ville bringe dig i det lange løb. Tjek vores kommende vejledning for at vide mere om installationsvejledningen til MongoDB på Windows.
PREV-vejledning | NÆSTE vejledning
Anbefalet læsning
- 20+ MongoDB-vejledning til begyndere: Gratis MongoDB-kursus
- Dybdegående formørkelsesvejledninger til begyndere
- MongoDB Sharding Tutorial med eksempel
- MongoDB Opret databasevejledning
- Implementering i MongoDB: Trin-for-trin vejledning
- MongoDB Opret sikkerhedskopi af database
- Hvad er MongoDB-replikering
- MongoDB Regular Expression $ regex med eksempel