SQL utf-8 eller utf-16?

[Gjest Slettet+9871234]

Å konvertere SQL/XML til HTML er trivielt. Å konvertere HTML til XML er noe helt annet, og gir vanligvis ingen andre resultater enn langvarig hodepine. (Med mindre det er ryddig HTML du har laget selv, og ingenting annet).

 

Jeg ser foreløpig ingen grunn till å konvertere HTML til XML bortsett fra å lagre HTML som XML datatypen i PostgreSQL, eventuelt etter at HTML koden er kjørt gjennom en translatør som rydder opp i det meste av koden. Jeg begynner i det små.

 

En viktig grunn er jo at man kan bruke XPath etc.

 

Går det ikke, er vi vel enige om at TEXT er et godt nok format.

 

Takk for glimrende svar så langt .

 

Jeg lar denne tråden leve videre, ettersom XML og JSON er ganske nye datatyper i PostgreSQL slik jeg ser det.

[terjeelde]

Godt oppsummert av Djn.

 

Når det gjelder å lage sitt eget språk i XML, så er det ikke slik at det som er mulig, nødvendigvis er bra. Og at det *kan* være bra, betyr ikke at det alltid er bra, eller at det er bra alle steder.

 

Min erfaring sålangt er at for alle steder jeg har sett god bruk av XML, så er det gjerne 20-25 steder jeg har sett dårlig bruk.

 

La meg slenge på et eksempel. Yr.no deler værvarsel i XML-format. Dette er en av de beste brukene jeg har sett. Implementasjonen er lett å skjønne ved å lese filene, og dokumentasjonen er god.

 

Likevel, det ville vært like lett å jobbe med f.eks JSON eller YAML-data. Det er ikke XML som gjør løsningen bra, men at flinke folk har gjort en god jobb.

 

Og selv om data leveres i XML-format, så parser og henter jeg det ut, og legger det i tabeller i en PostgreSQL-server. Informasjonen som er i filen passer å levere i en fil - en sammenhengende enhet med informasjon - men når jeg skal bruke data lokalt trenger jeg ikke å samla data på samme måten, og kan spre det utover tabeller på den måten jeg ønsker å ha det selv.

 

Tilsvarende vil jeg bli overrasket om yr-folka primært lagrer rådata i XML.

[Djn]

Jeg jobber med biologiske data selv, og er forsåvidt glad for at det kommer i flate tekstfiler - en tab-separert tekstfil med halvveis ok kolonnenavn (og helst en separat beskrivelse) er i praksis mye enklere å angripe enn et vilkårlig XML-format ... og blir gjerne mye mer kompakt, som er en fordel når man tikker over 660 000 felter for hver av 500+ prøver.

 

Men ja, hvis du kan få din HTML konvertert til XML på en overkommelig måte er det for all del noe som kan bli nyttig - hvis du har noe med genereringen av HTMLen å gjøre kan du jo forsøke å endre den til XHTML i utgangspunktet, også. Det er ikke at jeg er negativ til selve idéen, jeg bare syntes det var vært å nevne at du så ut til å undervurdere konverteringsjobben.

 

(Og hvis ikke, vel - TEXT er tolerant.)

Endret 13. mai 2013 av Djn

[Gjest Slettet+9871234]

Korrekt XHTML er også alltid korrekt XML.

Korrekt HTML og XML er begge korrekt SGML, som er grunnen til at de ser nokså like ut.

Korrekt XHTML er korrekt HTML, enskjønt det er noen viktige forskjeller i parsingen (som, for å være artig, avhenger av MIME-typen det sendes med: XHTML sendt som text/html blir tolket som HTML)

Korrekt HTML kan, men må ikke (og ifølge standarden bør ikke) være lovlig XHTML.

 

Jeg vet det.

 

"Hvorfor bruker en SQL lærebokforfatter som kjenner ulike databaser og jobber med Oracle XML om HTML dokumenter?" Nei, si det? Det er konkret og beviselig feil, så jeg håper han mente XHTML og det bare gikk litt fort i svingene.

 

At det er mulig å få XSLT til å produsere lovlig HTML er en bivirkning av at HTML har en del lovlige-men-ikke-anbefalte varianter som lar det overlappe med XHTML.

Er det noen som bruker XHTML noe særlig nå? Jeg bruker det aldri, men prøver å bruke HTML som nå er en levende standard (hvor blant annet Opera er med om jeg husker riktig) og noen har forlatt betegnelsen HTML5,

 

Og forøvrig mener jeg HTML5 burde ta opp i seg noen triks fra SGML - slik som <aside>dette</> , eller kanskje til og med <aside/dette/ .

 

Enig bortsett fra at det burde stått HTML?? og ikke HTML5.

 

Ikke desto mindre er lenkene mellom HTMLdokumenter svært lite avanserte i forhold til XLink mellom XML dokumenter http://www.forumnorw....php?f=57&t=737 som det muligens aldri blir noe av. For ytterliger informasjon søk:

 

advanced semantic linking.

Endret 13. mai 2013 av Slettet+9871234

[terjeelde]

Jeg har ikke helt fått med meg hva du prøver å gjøre, og hvorfor du trenger xpath for å gjøre det?

 

Nysgjerrig, så jeg spør.

 

Om det bare er for test og læring, så får du tommel opp fra meg.

 

Om det er til en faktisk løsning som skal brukes til noe, så er jeg lanskje litt mer skeptisk.

 

Merk forresten at de fleste XML-bibliotek har en litt så-som-så sikkerhetshistorikk. Ikke nødvendigvis noe problem, men greit å ha i tankene om du vil legge inn XML fra kilder du ikke er trygg på.

 

Og for ordensskyld: jeg har gjort mye av dette. Jeg har laget websites som spytter ut XML, og fra det via XSLT-transforms til HTML, osv. Det er ikke noe stort problem, men det er langt fra behagelig. Livet er rett og slett for kort.

 

Jeg vil mye heller ha et behagelig templating-språk, som en designer kan bruke direkte, og son lar meg fokusere på andre ting.

[Gjest Slettet+9871234]

Likevel, det ville vært like lett å jobbe med f.eks JSON eller YAML-data. Det er ikke XML som gjør løsningen bra, men at flinke folk har gjort en god jobb.

 

Der er jo en rekke (M)L teknologier som:

1. http://www.matml.org/
   
2. http://www.xbrl.org/
   

Hvordan skal slike data lagres i en SQL (XML) database?

[terjeelde]

Form Follows Function

 

Det er vanskelig å svare på hvordan det skal lagres, uten å vite hvordan du skal bruke det.

 

Blir litt som å spørre hvordan du skal normalisere norsk for lagring i en database.

 

Hvis det bare skal lagres, og aldri behandles eller hentes ut, så kan du spare mye plass på å skrive det til /dev/null.

 

Det finnes forresten en del XML-databaser, de kan være verdt å se på hvis du primært skal behandle XML.

[Gjest Slettet+9871234]

Jeg har ikke helt fått med meg hva du prøver å gjøre, og hvorfor du trenger xpath for å gjøre det?

 

Mange ting, men en er å transformere mine over 30 000 (bokmerker) favoritter (6MB) til XML dokumenter ved et program som heter Favorez

 

http://download.cnet...4-10176921.html

 

Nyere Java Script / PHP versjon som jeg ikke har brukt: http://sourceforge.n...cts/favorez-js/

 

Bruker ikke HTML filen som eksporteres fra nettleseren.

 

Gammel Favorez kan lagre favorittene mine i ulike formater.

 

Jeg vil altså ha dem i en SQL database der jeg kan bruke XPath (eventuelt XQuery) og andre XML kommandoer som måtte komme til i fremtidige versjoner av PostgreSQL.

 

Det er bare et eksempel på bruk.

 

Det finnes forresten en del XML-databaser, de kan være verdt å se på hvis du primært skal behandle XML.

 

Langt fra. XML data vil kun ta opp et par felter (kolonner).

Endret 13. mai 2013 av Slettet+9871234

[GeirGrusom]

Der er jo en rekke (M)L teknologier som:

1. http://www.matml.org/
   
2. http://www.xbrl.org/
   

Hvordan skal slike data lagres i en SQL (XML) database?

Er det XML derivater så kan man trygt lagre det i et XML-felt. HTML er ikke en XML derivat.

 

<p>hei!<br></p> er gyldig HTML men ikke gyldig XML.

<div id='foo' /> er gyldig XML, men ikke gyldig HTML.

 

Hvis det er tekst, men ikke HTML så må du enten transformere det til XML, eller lagre det som tekst og indeksere det på en annen måte.

[Gjest Slettet+9871234]

Ser dere mulighetene:

 

About JSON. PostgreSQL 9.2 has a new built-in type for JSON documents.

In theory this works like the XML type, you can create columns with the

json type today. However, there is very little function support in this

release. Your best option if you need JSON processing in PostgreSQL today

is to install PLV8 to embed the v8 Javascript engine into PostgreSQL and

then use Javascript stored procedures of your own devising. PLV8 can be

downloaded from http://code.google.com/p/plv8js/wiki/PLV8

 

Postgres 9.3 feature highlight: JSON operators

Endret 13. mai 2013 av Slettet+9871234

[GeirGrusom]

Ved første øyekast ser det ut som et sikkerhetshull.

[terjeelde]

Bookmarks ville jeg nok lagret i vanlige tabeller, og ser ikke helt noe behov for XML.

 

Ved første øyekast ser det ut som et sikkerhetshull.

 

Støttes.

 

Og ved andre øyekast ser det ut som en komplisert måte å gjøre enkle jobber vanskelige på.

[Gjest Slettet+9871234]

Er det XML derivater så kan man trygt lagre det i et XML-felt. HTML er ikke en XML derivat.

 

<p>hei!<br></p> er gyldig HTML men ikke gyldig XML.

<div id='foo' /> er gyldig XML, men ikke gyldig HTML.

 

Hvis det er tekst, men ikke HTML så må du enten transformere det til XML, eller lagre det som tekst og indeksere det på en annen måte.

 

Ja da, der er mange slike oversettere.

 

Jeg har nevnt en som går fra HTML-> mange ting, deriblant XML.

[Gjest Slettet+9871234]

Ved første øyekast ser det ut som et sikkerhetshull.

Det er aldri sikrere enn koden applikasjonen er skrevet i.

 

Stikkord:

1. cURL
   
2. Prepared statements.
   

Bookmarks ville jeg nok lagret i vanlige tabeller, og ser ikke helt noe behov for XML.

 

Det spørs hva de skal bukes til. Regner med å lagre hele filen på 6 Mb i et XML datafelt. Da kan jeg bruke XTekonologier på feltet, SQL kommandoer, lagrede prosedyrer og triggere etc.

Endret 13. mai 2013 av Slettet+9871234

[GeirGrusom]

Ja da, der er mange slike oversettere. Jeg har nevnt en som går fra HTML-> mange ting, deriblant XML.

 

Jeppjepp. Man må nesten bare se om det er verdt bryet. Personlig kan jeg ikke se at det generelt er noen god idé å lagre HTML i databasen. Jeg var innleid som konsulent et sted der det på et tidspunkt ble lagret HTML i databasen. Den lagret en HTML form i databasen, som deretter ble presentert for brukeren som postet data fra formen til applikasjonslaget. Det var mildt sagt galskap.

I samme løsningen var det også en funksjon som het ToHtml() som var implementert på et datagrunnobjekt de hadde. Heldigvis var den funksjonen tatt ut av bruk for en god stund siden, men det var artig lesestoff.

 

Men generelt så burde man ikke lagre presentasjonsdata i databasen direkte på den måten. Det blir bare et sirkus ut av det senere.

Endret 13. mai 2013 av GeirGrusom

[terjeelde]

Det spørs hva de skal bukes til. Regner med å lagre hele filen på 6 Mb i et XML datafelt. Da kan jeg bruke XTekonologier på feltet, SQL kommandoer, lagrede prosedyrer og triggere etc.[

 

Hvis du skal ha hele filen på 6MB i et datafelt, hva skal du da med databasen egentlig?

Endret 13. mai 2013 av terjeelde

[Gjest Slettet+9871234]

Jeppjepp. Man må nesten bare se om det er verdt bryet. Personlig kan jeg ikke se at det generelt er noen god idé å lagre HTML i databasen. Jeg jobbet som konsulent et sted der det på et tidspunkt ble lagret HTML i databasen. Den lagret en HTML form i databasen, som deretter ble presentert for brukeren som postet data fra formen til applikasjonslaget. Det var mildt sagt galskap.

I samme løsningen var det også en funksjon som het ToHtml() som var implementert på et datagrunnobjekt de hadde. Heldigvis var den funksjonen tatt ut av bruk for en god stund siden, men det var artig lesestoff.

 

Du har mange nyttige tanker GG, men hadde jeg hørt 100 % på det hadde jeg aldri fått gjort noe. ToHtml() kjenner den.

 

Men generelt så burde man ikke lagre presentasjonsdata i databasen direkte på den måten. Det blir bare et sirkus ut av det senere.

 

Langt fra enig der. Jeg er enig at

 

Innsamling -> Lagring -> Presentasjon av data er viktig. Se på hvordan deg gjøre is drupal og phpBB. Ting har nok utviklet seg siden den steinalderen du drev i.

 

Drupal har på sett og vis sitt eget datasespråk. Jeg har til hensikt å studere drupal kjernen og kanskje litt til for å få noen ideer om presentasjon.

Endret 13. mai 2013 av Slettet+9871234

[Gjest Slettet+9871234]

Hvis du skal ha hele filen på 6MB i et datafelt, hva skal du da med databasen egentlig?

 

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.
   

[GeirGrusom]

Langt fra enig der. Jeg er enig at

 

Innsamling -> Lagring -> Presentasjon av data er viktig. Se på hvordan deg gjøre is drupal og phpBB. Ting har nok utviklet seg siden den steinalderen du drev i.

 

Drupal har på sett og vis sitt eget datasespråk. Jeg har til hensikt å studere drupal kjernen og kanskje litt til for å få noen ideer om presentasjon.

 

Drupal er vel et CMS og har et eller annet DSL på toppen. phpBB bruker UBB-kode som er et DSL for å abstrahere vekk rå HTML. HTML kan vel lagres for caching, eventuelt så kan klientkoden inneholde implementasjonen av DSL-en.

Jeg synes ikke det er noe i veien med å gjøre det slik, men å lagre ren HTML i en database synes jeg ikke er en god idé.

[Gjest Slettet+9871234]

Jeg synes ikke det er noe i veien med å gjøre det slik, men å lagre ren HTML i en database synes jeg ikke er en god idé.

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)