NoSql er ikke en erstatning for SQL-databaser, men er et gyldigt alternativ til mange situationer, hvor standard-SQL ikke er den bedste tilgang til lagring af dine data.
Da vi blev lært, at når du har brug for at gemme data i et "datavarehus" og forespørge om disse data til udvinding, er SQL den bedste løsning, du skal kun beslutte, hvilken SQL Engine du skal bruge, og spillet er slut.
I 2012 var dette forslag forkert, jeg mener, at du ikke længere kan antage, at SQL er den "eneste måde" at gemme data på, men du skal vide, at der er andre alternativer, og de kaldes NO SQL. Under dette begreb har vi forskellige lagringsmekanismer, der ikke er baseret på SQL, og i .NET har vi et exceptionelt produkt kaldet RavenDB (du kan finde en rigtig god introduktion til RavenDb i Mauro-bloggen).
Den første store forskel med standard SQL er fraværet af et skema
En af de mest irriterende begrænsninger ved SQL Server er behovet for at specificere det nøjagtige format på de data, du vil gemme i dit lager. Dette er nødvendigt af mange gode grunde, men der er situationer, hvor du virkelig er ligeglad med det, især hvis din software i høj grad er baseret på OOP-konceptet. Antag, at du har dette objekt
1:klassespiller
2:{
3:offentlig strengnavn { get; sæt; }
4:
5:public DateTime RegistrationDate { get; sæt; }
6:
7:public Int32 Age { get; sæt; }
8:}
I et øjeblik er der ingen bekymring for, at dette objekt er dårligt indkapslet (det har en offentlig metode til at opnå og installere det), men kun fokuseret på behovet for at "gemme" dette objekt et sted. Hvis du bruger et standard SQL-lager, er den første ting, du skal gøre, at oprette en tabel, derefter definere kolonnerne, definere den maksimale længde for kolonnen Navn og til sidst vælge den ORM, der skal bruges eller oprette et dedikeret datalag, og endelig kan du gemme objektet.
Hvis du arbejder med en krage, er dette den eneste kode, du har brug for
1:var store =new DocumentStore { Url ="http://localhost:8080" };
2:store.Initialize();
3:bruger (var session =store.OpenSession())
4:{
5:var player =new Player
6:{
7:Alder =30,
8:RegistrationDate =DateTime.Now,
9:Navn ="Alkampfer",
10:};
11:session.Store(player);
12:session.SaveChanges();
13:}
Serveren tager simpelthen objektet og gemmer det.
For at gemme et objekt i datavarehuset er der kun brug for to funktioner:"Gem" for at fortælle lageret det objekt, du vil gemme, og "SaveChanges", som faktisk udfører lagringen.
Hvad får du med dette simple kodefragment? Bare gå til standardbrowseren på serveradressen, og du bør se indholdet af databasen.
Databaseindhold efter simpel objektindsættelse
I figuren kan du se indholdet af databasekragen, den indeholder en spiller og en lille 1 ud for objektet er Id, som Raven bruger internt til entydigt at identificere dette objekt. Et andet objekt, kaldet Sys Doc Hilo / Players, sørger for at generere en identifikator for Players-objektet med Hilo-algoritmen.
Dette er alt, der er ingen grund til at definere skemaet, der er ingen grund til at have en speciel Id-egenskab eller andre krav for at gøre objektet kompatibelt med depotet, bare kald Store-metoden for ethvert .NET-objekt og dit objekt er i databasen, Periode!