Gå til innhold

SQL utf-8 eller utf-16?


Gjest Slettet+9871234

Anbefalte innlegg

  1. Men det transformeres jo til XML.
  2. Jeg personlig ser generelt mange grunner for å lagre HTML i en database og URLer speielt.
  3. Jeg vil også tro at det går raskere og er kanskje i enkelte tileller mer fleksibelt å bruke XPath i SQL enn i applikasjonen (PHP, JS)

Data i databasen burde generelt ikke ha noen forbindelse til presentasjonslaget. Kanskje du vil presentere data med noe annet enn HTML en gang, eller bare endre hvordan postene blir seendes ut uten å måtte reformatere hele datasettet. HTML kan fint lagres som XML, men det er fortsatt HTML.

 

Det er selvsagt ikke en sort/hvitt problemstilling, men etter min mening generelt en god idé.

 

For spørringer så er det kanskje mulig at det er raskere å bruke XPath i databasen. Bare pass på å ikke ha mye forretningslogikk i databaselaget.

Lenke til kommentar
Videoannonse
Annonse
  1. Jeg vil også tro at det går raskere og er kanskje i enkelte tileller mer fleksibelt å bruke XPath i SQL enn i applikasjonen (PHP, JS)

 

Er det snakk om store xml-dokumenter og du kun skal hente ut små fragmenter er det nok noe å hente på å bruke XPath i databasen, så slipper man å skyfle store mengder xml som ingen vil ha rundt omkring. Men at det på noen som helst måte er fleksibelt, det sliter jeg litt med å se. Det er vel ikke noe standard måte å håndtere xml i databaser på, så koden er hardt bundet til postgresql (som vel forsåvidt er den mest sympatiske databasen å låse seg til), gjør du alle xml-krumspringene utenfor databasen kan du velge mellom ulike programmeringsspråk og xml-biblioteker. Det høres mer fleksibelt ut i mine ører.

 

Generelt er det veldig "enkelt" å gjøre komplekse ting i databasen med sql (og evt. xpath/xslt/whaterver), sql, xslt og xpath er kraftige språk, men det er ikke nødvendigvis lurt å gjøre det. Databasen vil ofte leve lengre enn applikasjonene som kjører på den. Xml i database var veldig "hot" for ca 10 år siden, enten det var lagring av xml, eller bare produksjon av xml fra vanlige resultatsett. Sitter nok mange utviklere i dag og river seg i håret over slike "geniale" arkitekturbeslutninger fattet på grunnlag av salgshype fra MS og Oracle for ti år siden.

Lenke til kommentar

Oppdatering:

  1. Nå kunne jeg svare med Øystein Sunde. Kjekt og ha og hvem vet hva det kommer ut av det.
  2. Men jeg kunne tilføye. Sammen med en rekke andre ting.
  3. Oppdatering lettere å ivareta i en databaser.
  4. Lage en Bot som oppdaterer databasen på en hub av URL'er.
  5. Hvordan tror du Google lager sin index, cache etc? Ikke det at jeg har til hensikt å konkurrere med G eller GG.

 

 

Ville det ikke vært mye enklere å ha en ok tabell-struktur? Lenke i et tekstfelt, beskrivelse i et annet, kanskje "lagt til" i et datofelt og "sist endret" i et annet, og hva som helst annet du måtte ønske. Da kan du trivielt filtrere, søke, legge til, oppdatere, automatisere og hente ut (evt til XML eller hva som helst annet) med greie, vel-dokumenterte, raske SQL-operasjoner. Sikkert er det også, om du gjør det riktig - akkurat den koden er veltestet.

 

Å bruke ett enkelt felt i databasen som om det var en tekstfil, for å å kjøre XML-verktøy i databasen (i stedet for i programmet rundt) virker som en veldig merkelig bruk av en databasemotor; litt som å støpe fast en lastebil i hagen fordi du har funnet en kjekk måte å bygge lydstudio på et lasteplan...

Lenke til kommentar

Å bruke ett enkelt felt i databasen som om det var en tekstfil, for å å kjøre XML-verktøy i databasen (i stedet for i programmet rundt) virker som en veldig merkelig bruk av en databasemotor; litt som å støpe fast en lastebil i hagen fordi du har funnet en kjekk måte å bygge lydstudio på et lasteplan...

 

Fantastisk bra ordlagt. :)

 

 

Får frem poenget godt; Det er ikke noe galt med lastebil (PostgreSQL) eller lydstudio (XML), men kombinasjonen henger ikke nødvendigvis sammen.

 

PostgreSQL er en kjempegod SQL-database, men det er SQL den er god til, ikke XML.

 

Vil du ha en database som primært skal jobbe med XML, så se f.eks på en av disse:

 

http://basex.org

http://exist-db.org/exist/apps/homepage/index.html

http://www.sedna.org

 

Jeg anbefaler mer enn gjerne PostgreSQL, og bruker halve dagene mine med den selv. Det er en fin database. Den passer jobben du vil gjøre (håndtere bookmarks), men den passer ikke til måten du vil gjøre det på. Da er det bedre å finne et verktøy som faktisk passer, og heller bruke PostgreSQL til det den er god til.

 

Ofte er det mange riktige måter å løse et problem på, men det som har blitt beskrevet er ikke en av dem. ;)

 

For erfaringens og læring er det ikke noe galt i å gjøre dette, det er mye å lære. Samtidig er det greit å ha klart for seg at dette ville blitt sett på som fullstendig uakseptabelt i en betalt stilling.

Lenke til kommentar
Gjest Slettet+9871234

Takk for glimrende innspill. :thumbs: til dere alle.

 

Vil du ha en database som primært skal jobbe med XML, så se f.eks på en av disse:

 

http://basex.org

http://exist-db.org/...page/index.html

http://www.sedna.org

 

Jeg kjenner XML databaser, og som notorisk lenke (favoritt) samler takker jeg for noen jeg eventuelt ikke har fra før, Har ikke tid til å sjekke. Det hadde jo gått raskt om favorittene mine var samlet i en fornuftig indeksert SQL database, antageligvis raskere enn ved google desktop søk eller søk i windows explorer. Den databasen kunne jo ligget på mitt Windows 8 nettbrett. Kjekt å ha noen ganger.

 

For erfaringens og læring er det ikke noe galt i å gjøre dette, det er mye å lære. Samtidig er det greit å ha klart for seg at dette ville blitt sett på som fullstendig uakseptabelt i en betalt stilling.

 

Jeg betaler med selv og hadde det vært en betalt stilling gjør jeg som forrest Gump det jeg blir spurt om. Det står endog i mine attester fra Norges Bank et jeg er svært fleksibel å jobbe med, da jeg lett legger til side lavere prioriterte til fordel for høyrere prioriterte oppgaver. Du får et rep punkt for de tre lenkene.

Endret av Slettet+9871234
Lenke til kommentar

Ville det ikke vært mye enklere å ha en ok tabell-struktur?

Dette kommer nok veldig an på hvaslags data det er snakk om og hvordan de skal brukes... umulig å si noe generelt. Hvis det er snakk om en lenkesamling skjønner jeg heller ikke helt pointet med xml ...

Lenke til kommentar
Gjest Slettet+9871234

Hvis det er snakk om en lenkesamling skjønner jeg heller ikke helt pointet med xml ...

 

Jeg tenker bare høyt. Lettere å lage et presentasjonslag og lettere med gjenbruk av data?

Lenke til kommentar
  1. Hvordan tror du Google lager sin index, cache etc? Ikke det at jeg har til hensikt å konkurrere med G eller GG.

De bruker nok helt sikkert ikke en sql-database til indeksen sin :-)

 

Hvis du har lyst til å sette deg inn i indekseringsteknologi kan jeg anbefale en titt på Elasticsearch.

Lenke til kommentar

Jeg tenker bare høyt. Lettere å lage et presentasjonslag og lettere med gjenbruk av data?

Hvis data alt er på xml-format, ikke skal være spesielt søkbart, og skal presenteres ut igjen som xml, så ja.

 

Men hvem vil se "rå" xml i et gui? Den korteste veien er nok fra xml til (x)html, kanksje via xslt, men hvordan det er så veldig mye enklere en alskens andre varianter, f.eks. fra et vanlig sql resultatsett ser jeg ikke. Og hvis gui-teknologien ikke involverer noe xml-aktig a'la html, fordi det er et C++ eller javaprogram f.eks., så blir det vel xml bare en omvei.

 

xml-data brukes mest til b2b, ikke gui (dog, en eller annen xml-variant til markup er ikke uvanlig i gui).

Lenke til kommentar
Gjest Slettet+9871234

Hvis du har lyst til å sette deg inn i indekseringsteknologi kan jeg anbefale en titt på Elasticsearch.

 

Takk det er svært aktuelt om jeg får bevare helsen. Jeg sitter for øvrig med en drøss med nettverks og lignende litteratur som jeg nok ikke helt forstå betydningen av. Blant annet kjøpte jeg nettopp boken;

 

Instant Cytoscape Complex Network Analysis

 

Building Machine Learning Systems with Python Raw

 

Raw vil si at jeg sitter med en foreløpig versjon. Jeg spiser stort sett en slik bok til ...

Lenke til kommentar

Ah, cytoscape. Jeg har moret meg med det selv i det siste - vi holder på å teste en (forsåvidt kjekk) analyse-plugin som gjør nyttige ting med biologiske data, og så produserer annoterte nettverk. (Jeg tror ikke jeg har lov til å være mer spesifikk enn det før den blir publisert).

 

Jeg ... ville ellers ikke ha brukt det selv, men så er jeg heller ikke voldsomt glad i å analysere biologiske nettverk. Det virker dog som et bra verktøy om du har noen store nettverk (uansett type) du skal se nærmere på. :)

 

 

Jeg tenker bare høyt. Lettere å lage et presentasjonslag og lettere med gjenbruk av data?

 

Nei, egentlig ikke - det å plukke ut data med SQL og pakke de inn i noe annet er veldig godt støttet på mange forskjellige måter, for eksempel i omtrent alle web-rammeverk de siste 15 årene (hvis du vil ha HTML); å starte med XML vil bare gjøre det vanskeligere.

Endret av Djn
Lenke til kommentar
  • 1 måned senere...

Takk det er svært aktuelt om jeg får bevare helsen. Jeg sitter for øvrig med en drøss med nettverks og lignende litteratur som jeg nok ikke helt forstå betydningen av. Blant annet kjøpte jeg nettopp boken;

 

Instant Cytoscape Complex Network Analysis

 

Building Machine Learning Systems with Python Raw

 

Raw vil si at jeg sitter med en foreløpig versjon. Jeg spiser stort sett en slik bok til ...

 

google: ORM, DB Objects, Templates, Caching, Validation, Ajax og Auth Module

 

For øyeblikket ser jeg ingen grunn til å være mer spesifikk og siden djevelen er i detaljene vil jeg også være varsom med eksakte råd.

Endret av fraktalridderen
Lenke til kommentar

Opprett en konto eller logg inn for å kommentere

Du må være et medlem for å kunne skrive en kommentar

Opprett konto

Det er enkelt å melde seg inn for å starte en ny konto!

Start en konto

Logg inn

Har du allerede en konto? Logg inn her.

Logg inn nå
  • Hvem er aktive   0 medlemmer

    • Ingen innloggede medlemmer aktive
×
×
  • Opprett ny...