Databasupplägg dynamiska attribut

Ursprungligen inskrivet av Wishie
Prova något nytt och testa en dokumentbaserad databas, de är gjorda för såna här tillämpningar. Jag jobbar mycket i Lotus Notes/Domino som är en helt dokumentbaserad databas, och det har helt klart sina fördelar. Det går otroligt snabbt att komma igång och hela databasen blir väldigt flexibel.

Jag kan försöka förklara lite kort vad det hela innebär.. Din databas består kort sagt av en klump dokument. Varje dokument kan man säga är en hashmap, en samling nycklar och värden. Svårare än så är det inte. I Lotus Notes t.ex. finns det vissa "nyckelfält" man brukar använda för att kunna ha olika typer av dokument. Då skapar man olika formulär för att skapa desa dokument, och varje dokument får sedan ett fält "Form" som innehåller formulärnamnet av det formulär det är skapat med.

Det finns flera open source-projekt som har egna, fristående implementationer av dokumentdatabaser, bland annat CouchDB som är inspirerat av just Lotus Notes. Så om du känner för att kolla på nåt nytt kan du ju kika på det.

http://couchdb.apache.org/

Ursprungligen inskrivet av Teknocide
Hmm! Nu kanske jag är ute och cyklar men visst kan man i C# ställa queries mot en XML-fil? Det borde vara supersmidigt..

Ursprungligen inskrivet av Phod
En dokumentbaserad databas kan ses som en förlängning av en relationsdatabas, d.v.s. man kan implementera en sådan som ett lager ovanpå en relationsdatabas. Nu har du inte sagt så mycket om hur dina användadefinierade attribut ska behandlas och presenteras, ej heller omfattningen av det hela. Det är sådant som spelar in när du ska välja om du ska bygga på en vanlig relationsdatabas på det sätt som du beskrivit, eller om du ska abstrahera det hela litet mer och implementera någon form av dokumentbaserad databas.

Ursprungligen inskrivet av Teknocide
Så här tänker jag:
Om inställningarna av någon orsak behöver ändras "on the fly", möjligen av flera användare samtidigt, så använd en databas. Om kravet däremot är att inställningarna endast ska kunna ändras av administratör eller enskild användare (namnuppgifter exempelvis) så kör med en fil per konto. Detta ger flest möjligheter i underhåll då admin kan göra ändringar direkt mot filen eller med ett [3:e parts] verktyg, strukturen på disk blir tydlig och användaren får rättigheter enbart mot sin egen fil.

Behövs användargrupper? Det kan fungera med XML också men så fort flera användare ska kunna uppdatera gruppdata samtidigt går flat file-alternativet mer eller mindre bort.

Ursprungligen inskrivet av Phod
Exakt! Detta är ett exempel på att XML förhindrar bra concurrency.

Ett annat exempel är om data från fler källor ska aggregeras. Då kan man få mycket I/O och högre minnesanvändning.

Nackdelarna med databasvägen, speciellt om du använder en dokumentbaserad modell, är att det kan bli mer och mer invecklat initialt arbete.

Så för att kunna göra en avvägning av vilken metod som lämpar sig bäst måste man alltså känna till flera parametrar.

Ursprungligen inskrivet av Phod
För det första skulle jag inte blanda XML- och relationsdatabaser. Det innebär ju dubbelt arbete. Vad är problemet med att använad XML till att lagra de attribut som får förekomma?

För det andra tycker jag det låter som om en relationsdatabas skulle passa bättre om du vill kunna köra globala sökningar utan att ha en monolitisk XML-fil. Men om du vill söka i en användarlista så lagras väl den i en XML-fil, och är kanske cachad i minnet, och då blir det inte så mycket filläsning.

Vad är det för operationer du vill köra på dina listor med attribut? Om du vill att administratören ska definiera dem och sätta värden så är det väl inte så svårt att implementera ett interface för en relationsdatabas? Eller vill du utföra mer komplicerade operationer?

En sak du måste tänka på om du implementerar en XML-baserad databas är att om flera processer kan uppdatera samma XML-fil samtidigt så måste du låsa de operationerna med en mutex, semafor eller liknande.

Ursprungligen inskrivet av Teknocide
Precis, här blir det problem. Det finns två scenarion:

Scenario 1: Du har alla användare i en stor XML-fil. Det går relativt snabbt att göra sökningar över användarbasen.
Problem 1: Concurrency. Användarna kan inte längre ändra sina egna uppgifter simultant eftersom alla delar på en enda fil. Admin kan dock utan problem göra ändringar, och med en fillåsmekanism kan man låta andra (moderatorer, enstaka superusers etc.) göra ändringar, bara de inte gör det samtidigt.

Scenario 2: Du har varje enskild användares data i en egen fil. Användare har tillgång till sina egna uppgifter och kan ändra vissa (väldigt enkelt att sätta med, exempelvis, ett restricted="true"-attribut på vissa element.
Problem 2: Hur söka på användare? Ska användare kunna söka på varandra? Då blir det antagligen segt. Man kan läsa in alla användarfiler i ett enda svep och sedan parsa; det blir relativt snabbt men tungrott för servern om användarbasen är stor. Ett annat alternativ är att cacha sökningar på något smart sätt.

Bägge scenariona är struliga.

edit: om det enbart rör sig om namnsökningar så är det en smal sak att skapa katalogstrukturer efter initialer/förnamn/efternamn. Att söka efter directories borde inte alls vara särskilt komplicerat, och begränsar urvalet betydligt.

Om man istället ska kunna hitta något random som alla användare som gillar rosa skor -- då användare ska kunna ha olika data -- blir det krångligare.

Ursprungligen inskrivet av Teknocide
Troligtvis.

För att göra valet enkelt: om du för att nå dina mål skulle behöva bygga ett helt databassystem för att hantera din XML-fil/filer så är det bättre att använda ett redan färdigt system. Jag har en förkärlek för flat-files och deras enkelhet, men det ska ju vara enkelt att implementera lösningen också

Ursprungligen inskrivet av Phod
Menar du att födelsedatumet används som en unik identifierare för en användare, eller vad är det som ligger i strängen?

Ursprungligen inskrivet av Phod
Aha, OK, då förstår jag! Du kan väl spara information om vilken datatyp attributet innehåller (om det inte är en sträng) och använda denna till att konveratera datan när du sparar i och hämtar från databasen?

Ursprungligen inskrivet av Phod
Du kan gå två vägar:

1) Att låta databasen vara typagnostisk och köra alla kontroller o.dyl. i C#, d.v.s. lagra allt som strängar. Det här är kanske ett fall där jag inte ser något fel med en sådan lösning, p.g.a. att datan till så stor grad är användardefinierad.

2) Att konvertera allt till de datatyper som stöds av databasen. Ett problem som detta kan innebära är att du kanske vill introducera någon slags egendefinierad datatyp, t.ex. klädstorlek. Då kan du inte dra nytta av de de datatyper som databasen stödjer och har ett fall där all kontroll av datatypen sker i C#.

Utan att veta mer om hur du planerar att bygga ditt system är det svårt att säga vad som är bäst, och jag antar att ditt sätt att konstruera det skiljer sig från det sätt jag skulle använda, så jag säger att du ska välja den metod som passar dig bäst. Var noga med att planera i förväg så går nog allt bra.

Ursprungligen inskrivet av Garret
Tänk på att om du sparar all data i databasen som strängar kommer du få problem med databassökningar. Du kan t.ex. inte jämföra om ett datum är större än ett annat då jämförelsen kommer göras på strängar och inte DateTime-objekt.

Ursprungligen inskrivet av Garret
Som vi gjorde på jobbet var att skapa en kolumn per datatyp, som tur var så hade vi endast ett fåtal datatyper som vi tillät. Det är inte en vacker lösning men det var den enklaste...utan att ta för mycket tid i anspråk.

Om du vill lägga in egendefinierade objekt i tabellen så kan du ändå inte styra hur jämförelserna görs av dessa i databasen. T.ex. någon skrev något om klädstorlekar, hur ska databasen veta att S är mindre än M. En strängjämförelse skulle säga att M är mindre än S.

Ursprungligen inskrivet av Garret
Det är en smaksak. Tre tabeller för samma sorts data men olika datatyp eller tre kolumner i samma tabell? Vilket sätt vill du "smutsa ner" din databas på?

Ursprungligen inskrivet av Phod
Förutsatt att du har rätt index lär det ju inte ta så lång tid, och då behöver du inte skriva flera olika frågor beroende på vilken typ av attribut du söker efter.