NoSql är inte en ersättning för SQL-databaser men är ett giltigt alternativ för många situationer där standard SQL inte är den bästa metoden för att lagra dina data.
Eftersom vi fick lära oss att närhelst du behöver lagra data i ett "datalager" och fråga efter dessa data för extraktion, är SQL den bästa lösningen, du behöver bara bestämma vilken SQL Engine du ska använda och spelet är över.
2012 var detta förslag fel, jag menar att du inte längre kan anta att SQL är det "enda sättet" att lagra data, men du bör veta att det finns andra alternativ och de kallas NO SQL. Under denna term har vi olika lagringsmekanismer som inte är baserade på SQL, och i .NET har vi en exceptionell produkt som heter RavenDB (du kan hitta en riktigt bra introduktion till RavenDb i Mauro-bloggen).
Den första stora skillnaden med standard SQL är frånvaron av ett schema
En av de mest irriterande begränsningarna för SQL Server är behovet av att ange det exakta formatet för den data du vill lagra i din lagring. Detta är nödvändigt av många goda skäl, men det finns situationer där du verkligen inte bryr dig om det, speciellt om din programvara till stor del är baserad på OOP-konceptet. Anta att du har det här objektet
1: class player
2: {
3: public String Name { get; set; }
4:
5: public DateTime RegistrationDate { get; set; }
6:
7: public Int32 Age { get; set; }
8: }
För ett ögonblick finns det ingen oro för att det här objektet är dåligt inkapslat (det har en offentlig metod för att skaffa och installera det), utan bara fokuserat på behovet av att "förvara" det här objektet någonstans. Om du använder ett standard SQL-förråd är det första du behöver göra att skapa en tabell, sedan definiera kolumnerna, definiera den maximala längden för kolumnen Namn och slutligen välja den ORM som ska användas eller skapa ett dedikerat datalager, och slutligen kan du spara objektet.
Om du arbetar med en kråka är detta den enda koden du behöver
1: var store = new DocumentStore { Url = "http://localhost:8080" };
2: store.Initialize();
3: using (var session = store.OpenSession())
4: {
5: var player = new Player
6: {
7: Age = 30,
8: RegistrationDate = DateTime.Now,
9: Name = "Alkampfer",
10: };
11: session.Store(player);
12: session.SaveChanges();
13: }
Servern tar helt enkelt objektet och sparar det.
För att spara ett objekt i datalagret behövs bara två funktioner:"Spara" för att berätta för arkivet vilket objekt du vill spara, och "SaveChanges", som faktiskt utför sparandet.
Vad får du med detta enkla kodfragment? Gå bara till standardwebbläsaren på serveradressen så bör du se innehållet i databasen.
Databasinnehåll efter enkel objektinfogning
I figuren kan du se innehållet i databaskråkan, den innehåller en spelare och en liten 1:a bredvid objektet är Id, som Raven använder internt för att unikt identifiera detta objekt. Ett annat objekt, kallat Sys Doc Hilo / Players, tar hand om att generera en identifierare för Players-objektet med Hilo-algoritmen.
Detta är allt, det finns inget behov av att definiera schemat, det finns inget behov av att ha en speciell Id-egenskap eller något annat krav för att göra objektet kompatibelt med förvaret, anrop bara Store-metoden för vilket .NET-objekt som helst och ditt objekt finns i databasen, Period!