robo 3t formerly robomongo tutorial
Alt du trenger å vite om Robo 3T - Tidligere Robomongo:
I juni 2017 ble Robomongo kåret til et helt nytt navn kalt “Robo 3T”. Dette er utgivelsen av Robo 3T 1.1-versjonen støttet av 3.4-versjonen av MongoDB.
Les gjennom => Serie med detaljerte MongoDB-opplæringsprogrammer
Beslutningen om å endre navnet er tatt i lys av at programvaren har vært gjennom noen grunnleggende endringer og har forbedret seg mye med hensyn til feil og feil .
Den fremtredende endringen som må nevnes er at selskapet endret navn fra Robomongo til Robo 3T på grunn av noen endringer i produktets varemerke.
Du kan henvise her for mer informasjon om denne bekymringen.
Hva du vil lære:
- Hva i all verden handler dette Robo 3T-verktøyet om?
- Hvorfor Robo 3T?
- Om MongoDB
- Forord
- Fordeler med MongoDB over typiske RDBMS
- Hvorfor MongoDB over RDBMS?
- Områder der MongoDB kan brukes
- Hvorfor kalles MongoDB som en NoSQL-database?
- Datamodellering i MongoDB
- Omfattende kontrast mellom SQL vs NoSQL MongoDB
- Kontrast mellom SQL- og MongoDB-utsagn
- Teoretisk oversikt over forskjeller
- Dialektforskjellen: språkene
- SQL DBMS
- NoSQL DBMS
- Skalerbarhet Kontrast av SQL og NoSQL DBMS
- Datastrukturer
- Konklusjon
- Anbefalt lesing
Hva i all verden handler dette Robo 3T-verktøyet om?
Robo 3T er en gratis og lett GUI for MongoDB. Det er et MongoDB-styringsverktøy som har en skall-sentrisk kryssplattform og støttes av JSON dvs. JavaScript-objektnotasjon. Dette verktøyet er ikke typisk for MongoDBs andre administrative verktøy for brukergrensesnitt, det vil si at skallet kan bli innebygd i Mongo Shell med mye tilgang i både Mongo CLI og Mongo GUI.
Ved hjelp av dette mongo-skallet kan en bruker se, redigere og slette mongo-dokumenter. Videre er Robo 3T et frivillig open source-prosjekt, og det er gratis for publikum.
beste app for å sjekke CPU temp
Den kan spres på nytt og kan også endres på nytt ved å følge vilkårene for generell offentlig lisens versjon 3, som er publisert av Free Software Foundation.
Denne programvaren er utgitt og kan distribueres med det formål å hjelpe folk som kan få hjelp fra den. Derfor har den ingen garanti for grossering av den, i henhold til reglene fra GNU.
For mer informasjon om GNU, kan du sjekke ut GNU-lisenser
Hvorfor Robo 3T?
Robo 3T er en gratis og maskinvennlig programvare som bruker et lite antall ressurser tilgjengelig på en maskin. Det er høyt verdsatt og anerkjent som det verdensberømte prosjektet med høyest suksessforhold når det gjelder å gi topp produksjon.
Fremfor alt, av Robo 3T, trenger ikke brukeren å gå gjennom den rotete prosedyren for å bruke tabeller og rader, som vanligvis brukes i rasjonelle databaser. I motsetning til dem er det bygget på arkitektur Mongo samlinger og Mongo dokumenter.
Bransjer som bruker Robo 3T
Om MongoDB
MongoDB er laget som en åpen kildekodedatabase som støtter Mongo-dokumentasjon. Derfor sies det å være en dokumentdatabase. Som vi nevnte tidligere, er det en arkitektur for Mongo-samlinger og -dokumenter, der databasen inneholder samlinger, som til slutt bærer Mongo-dokumenter i dem.
Antall felt og størrelsen varierer fra ett Mongo-dokument til et annet. Rammeverket til MongoDB er basert på Compiler språk C ++.
Den foreslåtte opplæringen vil avklare hvert konsept i detalj og vil gi en klar forståelse av metodene og prosedyrene for å lage og administrere en svært effektiv og brukervennlig database.
Det vil bli laget ved å holde øye med å holde konseptuell håndtering av MongoDB for brukere som ønsker å lære det på en mye enklere måte som mulig. På slutten av denne omfattende guiden vil brukeren kunne teste sin ekspertise på et praktisk stadium.
Forord
Om DB:
Databasen er bærer av samlinger. DB i systemet inneholder flere sett med filer. MongoDB har muligheten til å ha flere databaser samtidig. Det sikrer enkel skalerbarhet og effektiv utførelse.
Hva er samlingen?
I MongoDB er samlingen en pakke med mongodokumenter.
Det er det samme som RDBMS-tabellen i typiske databaseholdere. Samlingen i MongoDB inneholder ikke noen form for skjema og er tilstede i en enkelt database. Mongo-dokumenter som er tilstede i samlinger har forskjellige felt. Vanligvis har mongodokumenter i samlinger analoge funksjoner.
Hva er Mongo Document?
Mongo-dokumenter er bærere av samlingen og har dynamisk skjema, det vil si at Mongo-dokumenter ikke er bundet til å ha samme pakke med felt eller arkitekturer. De er programmert som nøkkelverdipar.
Et eksemplar av Mongo-dokumentet:
Følgende utdrag er en illustrerende mongo-dokumentstruktur av bloggen, som viser nøkkelverdiparet av det med komma i tilfeller.
{ _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 kodebiten er _id et heksadesimalt tall som totalt har 12 byte. Det klarer eksklusiviteten i Mongo-dokumentet. Brukeren må legge til _id under innsetting av et mongodokument. Hvis brukeren ikke gjør det, velger MongoDB automatisk særegen ID for hvert mongo-dokument.
I mellomtiden, av 12 byte, er de første fire bytene reservert for en gjeldende tidsstempel, tre ved siden av disse fire er reservert for maskin-id, to ved siden av disse tre er reservert for en prosess med server og til slutt de utelatte tre byte brukes som en verdi som økes.
Fordeler med MongoDB over typiske RDBMS
Vanligvis er skjemaet til RDBMS utformet på en slik måte at det viser antall tabeller og deres forhold mellom dem. I mellomtiden, som nevnt tidligere, er det ingen forholdsskjema til stede i MongoDB.
La oss diskutere hvorfor MongoDB er et bedre valg for dataforsker enn typiske RDBMS:
- For det første mangler MongoDB skjema. Mongo-dokumentene er innehaveren av samlinger og antall felt, og størrelsen varierer fra ett Mongo-dokument til et annet.
- Det er en oversiktlig arkitektur av et enkelt objekt i MongoDB.
- Det mangler kompleks sammenføyning.
- Den har omfattende søkeevne på grunn av tilstedeværelsen av eiendommen som sier at mongo-dokumenter har en evne til dynamiske spørsmål ved hjelp av dokumentbasert spørrespråk som er effektivt som MySQL.
- Det kan gjøre tuning.
- Den har den enkleste skalerbarheten.
- For konverterings- og kartleggingsformål er det ikke behov for objekter.
- Få tilgang til data raskere enn vanlig DBMS.
Hvorfor MongoDB over RDBMS?
MongoDB har dokumentorientert lagring der data behandles i pakken med JSON-stilte dokumenter.
Videre kan indeksen tildeles på alle attributter. Det sikrer øyeblikkelig tilgjengelighet og kan lage enorme kopier. Det kan deles automatisk og ha rike spørsmål.
Fremfor alt kan brukeren få profesjonell støtte fra MongoDB.
Områder der MongoDB kan brukes
MongoDB er fremtiden som big data er fremtiden. MongoDB behandler store data effektivt.
Den har evnen til effektiv innholdsadministrasjon og utførelse på et sted. MongoDB er det beste alternativet å bruke i mobil- og sosiale medier. Det fungerer som et datahub og administrerer brukerdataene på sitt beste.
Hvorfor kalles MongoDB som en NoSQL-database?
I motsetning til RDBMS, der brukeren må lære MySQL, krever ikke MongoDB at brukeren har masse MySQL-kunnskap for å begynne å jobbe eller stole på at noen andre jobber med databasen for dem.
MongoDB er ikke en rasjonell database, derfor kalles den som en NoSQL-database. Det gir et sukk av avslapning til brukerne på grunn av sin mindre komplekse arkitektur.
Det er ingen bruk av poster som må være bundet av de samme kolonnenavnene og typene og de som dreier seg rundt bordet. Figurene nedenfor vil forklare alt. Disse to utdragene er eksempler på de to tabellene, der den ene tilhører kunden og den andre tilhører bestillinger.
I begge tabellene er det tilstedeværelsen av et gjensidig forhold.
Kundetabell
Kunde ID | Kundenavn | Bestillings ID |
---|---|---|
Primærnøkkel | Primærnøkkel | |
1 | Adam Gilchrist | 1 |
to | Rickey Ponting | to |
3 | Shane Warne | 3 |
Bestill tabell
Bestillings ID | Produkt | Mengde |
---|---|---|
1 | iPhone X | 5 |
to | Samsung S9 | 10 |
3 | HP Pavilion x360 | femten |
Mens du er i MongoDB, er det ingen rasjonelle egenskaper som RDBMS. Gi et innblikk i disse to utdragene.
Kundetabell
Kunde-ID 01 | Kundenavn Adam Gilchrist | BestillingsID 001 | Byen USA |
Kunde-ID 02 | Kundenavn Rickey Ponting | BestillingsID 002 | Status privilegium |
Kunde-ID 03 | Kundenavn Shane Warne | BestillingsID 003 |
Bestill tabell
BestillingsID 001 | Produkt iPhone X | Mengde 5 | Forsendelsesdato 14. august 2018 |
BestillingsID 002 | Produkt Samsung S9 | Mengde 10 | |
BestillingsID 003 | Produkt HP Pavilion x360 | Mengde femten |
Derfor, i NoSQL, er det første man må tenke på fraværet av kolonner med spesifikke kolonnenavn. I tillegg er det et nøkkelverdipar i alle felt. For det andre, i kundetabellen, er de første tre nøklene og radene like, og den fjerde, dvs. status og by, skiller seg fra de to første radene og er ikke tilbøyelig til den tredje raden.
I mellomtiden, i tabellen som tilhører bestillingsdetaljene, har andre og tredje rad verdier som ikke har noe forhold til den fjerde kolonnen.
I et nøtteskall gjør alle disse egenskapene NoSQL, det beste valget i forhold til typisk DBMS. Verden revolusjonerer og teknologien transformerer seg stadig med den. I denne raske tiden trenger næringslivet de raskeste løsningene for programvaren.
Ved hjelp av DBMS som MongoDB, som er en NoSQL DB, kan raskere svingtid være mulig på grunn av dens mindre kompleksitet sammenlignet med RDBMS. Når vi må gjennomgå innsatsen, potensialet, tiden og pengene som man må bære mens man bruker RDBMS, kommer MongoDB over det på kort tid.
Datamodellering i MongoDB
Data til stede i MongoDB har det enkleste skjemaet. En typisk SQL DBMS der en bruker må erklære skjema for en tabell før innsetting av data starter.
Som vi studerte, er MongoDBs samlinger dokumentorienterte og binder ikke brukeren til den typiske dokumentstrukturen som RDBMS. Fleksibilitet er den mektigste egenskapen til MongoDB, å bruke den over RDBMS.
En bruker må vurdere følgende punkter for å gjøre datamodellering i MongoDB:
- Finn ut de avgjørende behovene til ønsket applikasjon. For dette formålet må man gi et blikk på forretningsbehovene for anvendelse og finne ut de ønskede dataene og dens typer for den. Etter dette må man sørge for at dokumentarkitekturen blir funnet ut i henhold til formålet.
- Finn ut hentemønstrene til dataene. Hvis det er behov for kompleks bruk av søk, så søk etter indekser i datamodellen for å sikre effektiviteten til spørringene.
- Sist, men ikke minst, er å sikre innsatser, oppdateringer og slettinger som skjer i DBMS. Dette kan sikres ved å revurdere bruken av indekser og innebygd skjæring hvis den må være til stede i datamodelleringsdesignet. Dette er veldig viktig for å forbedre effektiviteten i MongoDBs miljø.
Omfattende kontrast mellom SQL vs NoSQL MongoDB
Forskjellen mellom ord og syntaks
SQL-vilkår / syntaks | MongoDB vilkår / syntaks |
---|---|
Database | Database |
Bord | Samling |
Rad | Dokument |
Kolonne | Felt |
Indeks | Indeks |
Bord | $ oppslag eller innebygde dokumenter |
Transaksjoner | Transaksjoner |
Flere DBMS og deres kjørbare filer
Database navn | Databaseserver | Databaseklient |
---|---|---|
MySQL | Mysqld | Mysql |
Oracle | Oracle | Sqlplus |
MongoDB | Mongod | Mongo |
DB2 | DB2 Server | DB2-klient |
Informix | IDS | DB-Access |
Presedenser og eksempler:
Tabellene ovenfor illustrerer begrepene, syntaksen, konseptet og utsagnene til flere typer DBMS.
La oss vurdere eksemplene på SQL og MongoDB for ytterligere presiseringer.
La oss se på et eksempel på SQL, som har personer med tabellnavn, mens MongoDB har en samling navnefolk som det samme som Tabeller over SQL.
MongoDBs samling har følgende prototype:
{ _id: ObjectId(“59z12ad6444n59ac2758a5x7”), user_id:'john25', age: 25, status: 'A' }
Kontrast mellom SQL- og MongoDB-utsagn
SKAP og ALTER
SQL-skjemaerklæringer | MongoDB-skjemaerklæringer |
---|---|
OPPRETT TABELLmedarbeider ( id MEDIUMINT IKKE NULL AUTO_INCREMENT, user_id Varchar (30), aldersnummer, status char (1), HOVEDNØKKEL (id) ) | db.employee.insertOne {{ id: 'john25', navn: john, status: 'A' }) Du kan imidlertid også eksplisitt opprette en samling: db.createCollection (“ansatt”) |
ALTER TABLE ansatt LEGG til join_date DATETIME | db.medarbeider.updateMange ( {}, {$ set: {last_name: Adam}} ) |
ALTER TABLE ansatt DROP COLUMN join_date | db.medarbeider.updateMange ( {}, {$ unset: {“Age”: “”}} ) |
SETT INN
SQL INSERT-uttalelser | Uttalelser fra MongoDB insertOne () |
---|---|
INSERT INTO-medarbeider (user_id, alder, status) VERDIER ('test001', Fire fem, 'TIL') | db.medarbeider.insertOne ( { user_id: “john25”, alder: 45, status: “A”} ) |
Noen SELECT-spørsmål fra SQL og MongoDB
SQL SELECT-utsagn | MongoDB finne () uttalelser |
---|---|
Å VELGE * FRA ansatt | db.medarbeider.find () |
VELG id, bruker-ID, status FRA ansatt | db.ansatt.find ( {}, {user_id: 1, status: 1} ) |
VELG bruker_id, status FRA ansatt | db.ansatt.find ( {}, {user_id: 1, status: 1, _id: 0} ) |
Å VELGE * FRA ansatt WHERE status = 'A' | db.ansatt.find ( {status: “A”} ) |
OPPDATERING Uttalelser om SQL og MongoDB
SQL Update-uttalelser | MongoDB updateMany () uttalelser |
---|---|
OPPDATERER ansatt SET status = 'C' HVOR alder> 25 | db.medarbeider.updateMange ( {alder: {$ gt: 25}}, {$ set: {status: 'C'}} ) |
OPPDATERER ansatt SET alder = alder + 3 WHERE status = 'A' | db.medarbeider.updateMange ( {status: 'A'}, {$ inc: {age: 3}} ) |
Slett poster av SQL og MongoDB
SQL Slett uttalelser | Uttalelser fra MongoDB deleteMany () |
---|---|
SLETT FRA ansatt WHERE status = 'D' | db.employee.deleteMany ({status: 'D'}) |
SLETT FRA ansatt | db.employee.deleteMany ({}) |
Teoretisk oversikt over forskjeller
Når en bruker får et behov, der han må gjennom en katarsis der han må ta en beslutning fra mange gode muligheter foran seg, så må han velge at enten må han fylle for RDBMS (SQL) eller Ikke-rasjonell DBMS (NoSQL).
Det er noen forskjeller, og ved å gruble på dem, kan en tilsvarende bruker ta en levedyktig beslutning, i henhold til hans behov.
La oss ha en oversikt over det store bildet sammenstøt mellom disse to forskjellige datastrukturene.
Dialektforskjellen: språkene
La oss ta et eksempel på township, hvor ingen er tospråklige, hver person snakker det samme språket, og det er den eneste formen for kommunikasjon mellom dem.
I et nøtteskall står det at dette er det eneste mediet de forstår hverandre fra. Hvis byen plutselig blir utsatt for et annet helt nytt språk, må det være anarkisk for dem å adoptere det på et øyeblikk, ettersom de ikke forstår det eller bare noen få forstår det.
Tenk nå på et eksempel på en annen by, der et samfunn er tospråklig og de snakker flere språk. Hver person som bor i samfunnet samhandler forskjellig med andre, og det finnes ingen universell måte å kommunisere på. Det er som om en familie er annerledes enn de andre, og det påvirker dem ikke på noen måte.
Disse enkle eksemplene forklarer kjernekonseptet til SQL og MongoDB.
La oss se kontrasten !!
SQL DBMS
SQL DBMS har et strukturert spørrespråk, dvs. MySQL for databehandling.
Det er ingen tvil om kraften til MySQL-språket, det er det mest brukte blant brukerne av DBMS, og det er allsidig å ta i bruk. For komplisert datahåndtering er det det beste valget. Men det er også en begrensning av det, og det er dets stive skjema.
På grunn av det komplekse skjemaet kan man ikke bytte mellom flere strukturer, de må bare holde seg til en struktur som de følger fra begynnelsen. I følge det første eksemplet ville endring av struktur være det samme som å endre språk der alle bare kjenner ett, og på denne måten vil det skape anarki og rot.
NoSQL DBMS
NoSQL DBMS utgjør dynamisk skjema.
Ustrukturerte data kan lett lagres på flere måter, dvs. de kan lagres som et nøkkelverdipar eller kan være en kolonne og dokumentorientert. Dette kan forklares nærmere fordi brukeren ville være i stand til å opprette Mongo-dokumenter uten å være begrenset til en forhåndsdefinert struktur, i motsetning til det typiske DBMS.
Dokumentene ville ha sin egen struktur som ville være unik i sitt slag. Feltene kan legges til når som helst under prosessen, og syntaksen varierer i annenhver database.
Skalerbarhet Kontrast av SQL og NoSQL DBMS
SQL DB-er er skalerbart vertikalt i motsetning til NoSQL, som er horisontalt skalerbart.
Vertikal skalerbar betyr at data kan lastes på en enkelt server ved å øke RAM. I mellomtiden betyr horisontal skalerbar at flere servere kan brukes, dvs. øke trafikken ved hjelp av skjæring. Derfor kan SQL DBMS være kraftig, men NoSQL er best for å endre datasett.
Datastrukturer
SQL DBMS er basert på tabeller mens NoSQL DB-er er basert på dokumenter, nøkkelverdipar, grafer og kolonneorientering.
SQL DBMS er et godt valg for typiske datatransaksjoner som regnskap og banksystem. I mellomtiden, for store data, ville NoSQL utpeke den rasjonelle DBMS.
Typiske eksempler av RDBMS inkluderer MySQL, Oracle, Maria DB og MS SQL Server. NoSQL eksempler inkluderer MongoDB, Neo4J, CouchDB, RavenDB Cassandra, HBase, BigTable og Redis.
Konklusjon
Alle de ovennevnte detaljene er satt sammen i et nøtteskall for enkel forståelse.
MySQL: Plus-poengene
Nedenfor er fordelene ved SQL-databaser:
- Gammelt er gull: MySQL er gammel, og har derfor en ganske sterk grunn når det gjelder stort fellesskap og testing.
- Stabil : MySQL er stabil ettersom den har flere brukere.
- Kompatibel : Den er allment tilgjengelig på alle større plattformer og rammer, inkludert Win, Mac, BSD, Solaris og Linux. Flere språk har en forbindelse med dem inkludert C ++, C #, Java , Perl, Python og PHP.
- Billig : MySQL er åpen kildekode og gratis.
- Replikerbarhet : Det kan være replikerbart blant mer enn en node.
- Sharding : MySQL har høy skjæringsevne, og det gjør det igjen pålitelig for virksomheten.
MongoDB: Pluspoengene
Dette er fordelene med MongoDB:
- MannVennordning: Som nevnt tidligere, gjør det dynamiske skjemaet detdet mestefleksibel DBMS for en bruker.
- Skalerbarhet : Dens horisontale skalerbarhet hjelper til med å redusere arbeidsmengden.
- Ledelse : MongoDB krever ikke noe administrativt verktøy. Det er brukervennlig av både produsenter og administratorer.
- Rask : Spørsmålene blir utført på kort tid.
- Flexibde : Dokument- og kolonneorienteringen gjør den fleksibel og enkel å bruke DBMS for en bruker.
Å være sluttbruker, hva velger du?
MySQL ville være det riktige valget for de brukere og bedrifter som trenger stive skjemaer og forhåndsdefinerte strukturer for deres virksomheter.
For eksempel applikasjoner og programvare som trenger lange transaksjoner, dvs. de som faktisk brukes i bank- og regnskapssystemer. Systemene som har overvåkingstjenester støtter MySQL DBMS.
Mens MongoDB ville være det beste valget for bedrifter som har rikelig vekst, og de ville kreve allsidige skjemaer.
Hvis det er vanskelig å definere skjemaet etter hvert som det blir endret på kort tid, vil MongoDBs dynamiske skjema fungere sitt beste i denne situasjonen. Denne tilstanden skjer ofte i mobilappindustrien, analytiske systemer og innholdsstyringssystemer.
Dette var bare en introduksjon for å få et snev av hva denne opplæringen ville gi deg i det lange løp. Ta en titt på vår kommende veiledning for å vite mer om Installasjonsveiledning for MongoDB på Windows.
PREV Opplæring | NESTE veiledning
Anbefalt lesing
- 20+ MongoDB-opplæring for nybegynnere: Gratis MongoDB-kurs
- In-Depth Eclipse Tutorials For Beginners
- MongoDB Sharding Tutorial med eksempel
- MongoDB Opprette databaseopplæring
- Distribusjon i MongoDB: trinnvis veiledning
- MongoDB Lag sikkerhetskopi av database
- Hva er MongoDB-replikering
- MongoDB Regular Expression $ regex med eksempel