Skulle ni säga att keyvalues i sql alltid är av ondo?

Håller på och bygger ett litet data input verktyg där man kan mata in fält. Tanken är att man ska kunna ha olika grupper av fält för olika ”kunder” och att dessa ska matas in med olika periodicitet t.ex. dagligen, veckovis, månatligen osv.

Kund 1 ska t.ex
Mata in temp på köttkylen varje dag.
Mata in pengarna på banken en gång i månaden.
Mata in antal kasserade enheter en gång i veckan.

Så jag skapade 3 tabeller:

input_field_key (int id, varchar name,ä)
input_field_value(int id, int key_id, date created_at, decimal value)
input_field_setting(int id, int key_id, int user_id, varchar period_type)

Begränsningen är att man endast kan mata in decimals, men det är önskvärt i denhär lösningen.

Man ska visa en reminder i portalen om vad som behövs göras idag. Det betyder att man behöver kolla upp och hitta alla values som inte finns under en viss period tillbaka i tiden, för varje ”setting” som kunden har.

Alternativet är ju att lägga datat en json eller nånting. Hur skulle ni göra?

Kan ju säga att det jag egentligen är ute efter är väl ett slags dynamiskt formulär, men där man bara kan stoppa in siffror.

Value tabellen behöver också ett user_id i det här fallet, annars går det inte att filtera ut inmatningarna för att visa dem.

Key-values har sina användningsområden och beroende på vad du kör med för databasmotor och index, är det mer eller mindre användningsbart.

En nackdel med att ha en key value-struktur, är just att man låser sig till en datatyp. Vad händer den dagen då du vill lägga till en ny nyckel med ett värde som inte passar in i den datatyp du valt?

Jag har dykt på två varianter på key-value-databaser inom relationsdatabasvärlden. Den ena kör med en key- och en value-tabell, där den senare är NVARCHAR(8000), den andra lösningen kör med en key-tabell och flera value-tabeller, där varje tabell har sin datatyp. I den förstnämnda lösningen måste man hålla på med en massa konverteringar och i den andra lösningen blir det en massa tabeller istället.

I det här fallet skulle jag definitivt köra på en gammal relationsdatabasmodell och inte key/values. En tabell per "sak", dvs en fridge-tabell, en bank-tabell och en scrapped-tabell. Lägg till en datumtabell att jämföra med så blir det enkelt mha en LEFT JOIN att se vad som saknas.

Jag vet inte om jag hade haft en settingstabell precis sådär som du har valt det. En sak är ju att ha det lättläst (period type), men det krävs logik att tolka det, vilket tar tid och prestanda. Jag hade nog lagrat period som antal dagar (timmar, minuter eller vad nu minsta periodlängden är). Lätt att konvertera till jämförbar datumtid.

Kanske tycker du jag är omständig, men jag tror starkt på att var sak har sin plats och man tjänar i slutänden på att ha ordning och reda i databaser. Går snabbare och effektivare då.

Varför anvönder du inte en NoSQL/schema-less dokument-databas istället? Det borde passa betydligt bättre. Mongo DB eller Couch DB är bra alternativ i så fall. Då kan du spara data av olika datatyper i samma dokumenttyp. Du kan även ha olika fält i olika dokument, även om de är av samma typ.

Det vore ett betydligt bättre system än att försöka få in det i SQL.

Har övervägt det. Grejen är att resten av appen är byggd med sql och datat ska aggregeras och läggas in i andra tabeller på samma sql server.

Hade det varit postgres hade jag dock använt deras json, men nu är det sqlserver och en rätt gammal dessutom.

TexasSwede har delvis rätt.

Men key-values har sina fördelar.

Tror Du är på rätt spår med SQL - och det är trots allt en sedan länge etablerad industri-standard.

Men var medveten om att världen håller långsamt på att förändas / gravitera mot NoSQL och graph databases, returnerande resultat i ett "icke-tabulärt" format, som JSON.

Nackdelen är att om Du kommer från en traditionell relations-värld så kan inlärningskurvan vara oerhört brant. Så beroende på projektets storlek och uppskattade 'livslängd', är det frågan om det är värt 'investeringen'.

https://neo4j.com/developer/graph-database/

Hugget som stucket skulle jag vilja säga.

[RANT]Världen förändras, för att dagens utvecklare är historielösa och för det mesta bara fokuserar att bygga nytt och i den andan bara jobbar med det senaste och häftigaste i teknikväg. Då väljer man inte relationsdatabasteknik för man tror att det är en föråldrad teknikstack.[/RANT]

Jag är dock inte emot nya sätt att lagra/hantera data. Jag ser det som en verktygslåda där man ska välja rätt verktyg till uppgiften. NoSQL och liknande löser vissa problem som relationsdatabaser har, men de har också ett antal problem som relationsdatabaserna har löst. Sedan kan man så klart välja rätt teknik, men göra en usel lösning, men hey, vilken utvecklare har inte lyckats med det? :-)

Jag tror dock att micro services är det smartaste tänket på mycket länge. Små fristående tjänster som gör en enda sak, men de gör det bra. Bort med alla tunga monoliter. Då kan man välja rätt teknikstack till respektive modul och faktiskt få till något som går att underhålla, uppgradera, skala och är driftsmässigt stabilare.

*ger mig själv smisk på fingrarna för att jag hamnade lite off topic, så slipper mods göra det*

Mycket visdom där Du.


Japp, vi kallar dem 'resume (CV) builders' eller 'drive-by developers / consultants'


Jo, vi alla har nog lyckats med det mer än en gång. "Om det är av misstagen man lär sej, så borde man ligga skapligt hyfsat till"

Tror inte det finns nåt tvivel om att graph-teknologi är här för att stanna - vi blir inte av med det.

Ref. 'The Panama papers' och filmen 'The Laundromat':

https://en.wikipedia.org/wiki/Panama_Papers

https://en.wikipedia.org/wiki/The_Laundromat_(film)

https://www.youtube.com/watch?v=w1fiM1NkpeM

Graph-databaser - anväda rätt - kan helt enkelt 'se' associationer och korrelationer som en traditionell relational (SQL) databas inte kan.

Finns en anleding till att LinkedIn, Facebook och Google använder dem.

Nånsin undrat varför LinkedIn eller Facebook plötsligt skickar dej ett meddelande, out of the blue, "you might know this person" eller "baserat på produkter Du köpt tidigare, detta kanske kan intressera dej" ?

Associationer.


Amen brother, amen. We got to break the monolith. Rekomenderar boken 'Working Effectively with Legacy Code' av Michael Feathers:

https://www.thriftbooks.com/w/workin.../item/4691187/

Nu blir vi nog båda dinkade för 'off topic' ska Du se ;-)

Jag tycker det är en bra och snygg lösning för det specifika problemet.
Jag hade antagligen gjort något liknande själv.
SQL är ju väldigt beprövat och effektivt. Det blir dock extra viktigt i en sådan lösning att du har indexerat dina fält. Du kan gärna indexera alla fält du har där, då får du ju också fördelen att exakt alla värden i din databas är indexerade.

Att välja en NVARCHAR(8000) gör du inte, NVARCHAR är 1-4000, max.

Men om du gör en key-value så kan du välja en nvarchar(255) t ex, så även värdet blir indexerbart.

Jag har t ex byggt en liknande lösning där jag importerade data från XML-filer. Ca 75.000.000 dokument per dag innehållande ca 50 värden i olika scheman. För att sedan pivotera de relevanta, ca 35, värdena till en transaktionstabell där sedan ett hundratal affärsregler applicerades och ca 7 minuter senare ca 10.000 aggregerade "köp" trycktes in i navision.

Byggde detta med en serie tabeller
Jobb (ID och metadata om jobbet),
Batch(Jobbid, id, metadata om batchen),
Document(jobbid, batchid, metadata om dokumentet),
Valuetype(id och beskrivning av datatyp för specifikt xml-element/-attribut), och
Values(documentid, valuetypeid, värdet)

2 minuter TSQL och 5 minuter SSIS-tasks, 45 minuter trist hämtande av XML-data från en webbservice... Som lätt kunnat minskas ner till någon minut om kunden velat ändra webbservices att leverera CSV. Dock så blev min lösning med TSQL och SSIS ca 3 timmar snabbare än tidigare lösning...

Jag antar att det där var riktat till mig :-)

Nej, om jag byggde något från början, skulle jag inte använda mig av NVARCHAR(8000). Jag är av den gamla skolan som ser till att minst en rad får plats på en 8kbytes-page, inklusive header och då är en kolumn på 16kbytes lite för mycket. Man har förmodligen några fler kolumner som ska in där också.

Ibland ärver man dock färdiga lösningar som kostar alldeles för mycket tid att rätta till, även om man vill. Som ogenomtänkta key-value-databaser med massa page-splits :-)

facebook använder många olika databastyper, men deras primära databastyp som används för lagring av inlägg är en relationsdatabas.

Närmare specifikt MySQL fast dom har bytt ut InnoDB (databasmotorn) till sin egenskrivna som heter MyRocks. Detta på grund av de höga datamängderna som InnoDB sparar.

Efter lite googling på nätet så sparade dom ca 50% lagringsutrymme med sin egna hemmaskrivna dbmotor.

http://myrocks.io/