Trött på alla no-sql kuksugare

Vad är det för fel på SQL? Det är en an de bästa DSLerna som finns för att hantera data.

Gillar inte att skriva SQL? Använd dapper, linq eller något av alla misslyckade ORMs där ute.
Men ge fan i databasen.

SQL databaser har Atomicity, Integrity, Consistency och Durrability.

SQL databaser har snapshots och transaktioner som kan rullas tillbaka.

SQL databaser har index som gör att man kan göra sökningar visslande snabbt.

SQL databaser har nycklar eftersom relationer alltid finns i data ändå, även om den ligger i platta filer.

SQL databaser möjliggör att man kan joina, aggregera och skapa projektioner på data. Det är enkelt och kraftfullt.

SQL databaser har replikering och backups en disk skulle crasha.

De flesta SQL databaser har turing kompletta skriptspråk som man kan använda för att processa data i själva databasen villket går betydligt snabbare än att tanka över den till nån app och spara tillbaka den.

Det är mer än vad någon jävla mongodb eller annan document/event store ens kan drömma om att uppnå.

Inte skalbart? Men använd en skalbar SQL databas då! Det finns massor. Cockroach db, redshift mfl.

De flesta tjänster blir ändå aldrig så feta att de växer ur en databas. Och när de gör det, ja då tjänar vi så mycket pengar att vi kan bygga ett nytt jävla system ändå.

Så håll käften med din fancy pants nosql data store.

Håller med OP. SQL är förbannat bra. Särskilt med de stora databasmotorerna som Oracle, DB2 mm.

Jag är ingen databasexpert på något sätt och vis, men kan arbeta med relationsdatabaser tillräckligt bra för att åstadkomma det jag behöver. Jag tänker ändå att det antagligen finns en anledning till varför man föredrar NoSQL i vissa avseenden.

Hur skulle en traditionell relationsdatabas stå sig i t.ex. ElasticSearch där du måste kunna slå på data dynamiskt och skapa upp olika filter etc?

SQL är bra men känns uråldrat

Vad är det som känns föråldrat med SQL?

Som vanligt finns det inte ett verktyg som passar alla situationer.

Jag tror att någon nosql med tillhörande ramverk är att föredra för det devopsteam som saknar databaskunskaper. Det funkar bra i normalfallet.

Det mest önskvärda scenariot är dock microservices, med egna små databaser, byggda helt för ett specialiserat ändamål. Då kan man blandmissbruka motorer och tekniker.

Något att tänka på, är att inte bli för nishad. Man blir kanske personberoende och det kan vara svårt att hitta lösningar för en liten motor få använder.

Personligen kommer den första kärleken alltid vara måttstocken ingen kan mäta sig med. Oracle RDB (Digitals databasmotor från början, ej att förväxla med vanliga Oracle). SQL Server är rätt nice den med, men mest för att den kan jag hyfsat utan och innan.

Det är kanske andra som vill vara "special snowflakes" likt som hur andra går loss på php.

Du skriver SQL-databaser, men du verkar mena relationsdatabaser.
Och beroende på implementationen kan de ha allt du skriver om:
SQL databaser har Atomicity, Integrity, Consistency och Durrability.

SQL databaser har snapshots och transaktioner som kan rullas tillbaka.

SQL databaser har index som gör att man kan göra sökningar visslande snabbt.
Men det beror inte på att man kan använda SQL för att hämta data, utan det beror på implementationen av databasen.
Det finns databaser utan referentiell integritet, med dålig indexhantering, atomicity och 'durrability', det har inget med query-språket att göra. Inte alla relationsdatabaser har two-phase commit, eller rollback.

Och innan du pratar om Dinky Toys som 'Cockroach db, redshift ' borde du kolla in DB2, gärna på ZOS, eller någon av Oracles större implementationer.

Inte alla bygger en liten webshop, somliga bygger banker, eller bokningssystem för flygbolag, då är det andra krav på skalbarhet och konsistens. Hundratusentals transaktioner per sekund är en annan värld, när timestamp på milliskeundnivå ändå inte blir unikt, och det tar längre tid att skapa en GUID än att processa transaktionen.
Lyssningstips: https://kodsnack.se/377/

SQL är ju hur bra som helst.

Det finns de som behöver ”skalbara” databaser men mitt problem är att det är allt för många som använder dem när det bara gör saker och ting krångligare och när man med en SOA infrastruktur ändå inte kommer upp i de belastningarna och datamängderna att det är något problem.

Som jag sa, de flesta som väljer detta by default för att vara ”skalbara” de tänker inte på alla korttransaktioner någonsin gjorda på en typisk E-handels sajt i sverige ryms i en vanlig SQL databas. Eventuellt att du vill arkivera data efter 4 år. Inget strörre problem där.

Så när man har så mycket transaktioner att man måste använda en skalbar databas. Ja då har man en annan budget och förhoppningsvis tid att lägga på att optimera det här systemet. Men det tillför inte mycket för ett mindre företag att hålla på med såntdär. Och man underskattar hur mycket problem, overhead och merkostnader en komplex arkitektur ger upphov till.

Det är en viss tröskel att lära sig och de flesta inom IT är, milt uttryckt, apdåliga. Det hjälper inte att om man är milt uttryckt apdålig så blir det också långt ifrån uppenbart varför SQL är ganska vettigt. Så går det när brancher växer snabbt. Behovet av resurser är (framförallt var) väldigt mycket större än tillgängligheten av (rimliga) resurser.

Dock inget att haka upp sig på. Som du ser har SQL överlevt. Av den enkla anledningen att de du kallar "kuksugare" fick backa i takt med att de förstod vad de höll på med (alternativt gick i KK).

Håller med, non-sql var väl mycket av en fluga för några år sedan, då allt skulle göras i mern eller mean stacks. Det är så den här branschen fungerar, och har alltid gjort, plötsligt kommer någonting nytt och häftigt, som används i något framgångsrikt projekt och sen ska hela branschen apa efter. Efter några år så lägger sig det hela, och sådant som funnits länge och alltid funkat återkommer.