[SQL Yukon] XML, OO of Relationeel

[Verwijderd]

Binnenkort gaan wij het intranet van ons bedrijf herschrijven naar .NET. We wachten hiermee tot ASP.NET 2.0 uitkomt. Rond deze zelfde tijd zal ongeveer Yukon uit komen, de nieuwe versie van SQL Server.

Nu kunnen met deze nieuwe versie van SQL Server op drie manieren data opslaan.

- Relationeel
- Als object
- Als XML

Beetje brede vraag, maar als wij documenten willen opslaan die in Word gemaakt worden willen opslaan, hoe kunnen wij deze dan het beste opslaan?

Het kan op alle drie de manieren. Het maakt niet zoveel uit of een manier een paar procenten sneller is al een andere manier.

Zelf heb ik deze afwegingen gemaakt.

Relationeel:
De tekstbestanden worden in tabellen als binary opgeslagen. Als string kan niet omdat je dan puur ASCII tekst opslaat en daarmee opmaak en figuren kwijt bent, daarom als binary. Nadeel hiervan is dat als je het wilt converten naar een andere format dat je in je software die de tekstbestanden uitleest een converter moet maken.

Object:
Voordat je hem als object gaat opslaan zal je eerst een Klasse document moeten gaan ontwerpen en implementeren in je software. Dit wordt sowieso gedaan bij het herschrijven van het intranet naar .NET Framework. Nadeel hiervan is dat objecten opslaan in Yukon een ENORME druk op je performance legt. Scalability is hierdoor in het geding.

XML:
Als XML is lekker snel en open als standaard. Meeste programmatuur kan met XML overweg en het is makkelijk te programmeren om met XML om te gaan. Vooral kijkend naar de toekomst zou je kunnen zeggen dat XML de standaard wordt om zulke documenten in op te slaan. Enige nadeel hierbij een XML definitie moet opstellen.

Dit is hoe ik erover denk. Ik kan dus niet tot een goed onderbouwde beslissing komen. Wat zijn jullie gedachtes hier over?

[ACM]

Is het verschil tussen Relationeel, OO en XML in Yukon echt zo groot dat je er bij de anderen niet over nadenkt om uberhaupt wat over de performance/scalability te zeggen en je het bij OO ineens met hoofdletters en onderstreept moet aangeven?

Je hebt nooit een productieversie van Yukon in handen gehad, dus hoe kan je uberhaupt daar nu al een echt zinnige uitspraak over doen?
Als je het vergelijkt met opslaan op een fileserver, dan zijn alle methoden sloom

Persoonlijk zou ik in eerste instantie kiezen voor het opslagformaat dat het beste aansluit bij je applicatie, als je daar het liefst XML in binnenhaalt, dan knikker je de boel in XML, als je de objecten uit de Yukon-db direct kan gebruiken als object in je .NET-app, dan heb je daar weer een conversieslag minder.
Heel simpel gezegd: volgens mij wordt het allemaal min of meer hetzelfde opgeslagen maar heeft de OO-manier als nadeel dat de data nog op je DB moet worden omgezet naar een intern dataformaat, maar weer als voordeel dat je je niet druk hoeft te maken om conversies van binaire of tekstuele data naar een FileObject ofzo.
Oftewel, _als_ de OO-manier inderdaad direct toepasbaar is binnen je app, dan kan dat een voordeel hebben boven de anderen (scheelt je conversiewerk), als je de boel sowieso moet converteren, dan zie ik weinig voordeel in de OO manier.

Het opstellen van een XML-definitie lijkt me niet een nadeel, das weinig meer dan het bedenken van een goede relationele structuur of het uitwerken van een paar simpele ValueObject-klassen... Als je alleen maar files wilt opslaan is het weinig meer dan een stukje metadata (owner, datum, etc en uiteindelijk de blob).

Vergeet niet bij de "toekomstgerichtheid van XML" dat je waarschijnlijk een stukje metadata en een datablob hebt die je opslaat, of wilde je de documenten helemaal gaan lopen converteren naar XML
En dan is het echt nauwelijks meer toekomstgericht (in een database) dan de interne formaten van die database...

[Verwijderd]

ACM schreef op 26 januari 2004 @ 12:24:
Je hebt nooit een productieversie van Yukon in handen gehad, dus hoe kan je uberhaupt daar nu al een echt zinnige uitspraak over doen?
Als je het vergelijkt met opslaan op een fileserver, dan zijn alle methoden sloom

Tijdens Dev Days is door Microsoft gezegd dat als je objecten gaat opslaan je performence het raam uit vliegt

[Verwijderd]

ACM schreef op 26 januari 2004 @ 12:24:
Oftewel, _als_ de OO-manier inderdaad direct toepasbaar is binnen je app, dan kan dat een voordeel hebben boven de anderen (scheelt je conversiewerk), als je de boel sowieso moet converteren, dan zie ik weinig voordeel in de OO manier.

Je kunt ook een mapping aanmaken tussen je XML en je Objecten. Soort van XML definitie maar dan naar objecten. Dus je kan dan nog steeds die conversieslag van XML naar OO buiten je objecten houden.

Het opstellen van een XML-definitie lijkt me niet een nadeel, das weinig meer dan het bedenken van een goede relationele structuur of het uitwerken van een paar simpele ValueObject-klassen... Als je alleen maar files wilt opslaan is het weinig meer dan een stukje metadata (owner, datum, etc en uiteindelijk de blob).

Je wilt toch zoveel mogelijk onderdelen van je word document apart opslaan. Het is toch heel moeilijk om zoveel mogelijk onderdelen van een word document te ontleden en om te zetten naar xml tags. Zie zelf de XML opmaak van een Word 2003 bestand.

Vergeet niet bij de "toekomstgerichtheid van XML" dat je waarschijnlijk een stukje metadata en een datablob hebt die je opslaat, of wilde je de documenten helemaal gaan lopen converteren naar XML
En dan is het echt nauwelijks meer toekomstgericht (in een database) dan de interne formaten van die database...

We willen word documenten opslaan zodat het de komende jaren uitstekend samen werkt met .NET Framework met ASP.NET en ADO.NET in het bijzonder. Daarom wil ik het van zoveel mogelijk kanten bekijken.

[ACM]

Verwijderd schreef op 26 januari 2004 @ 12:33:
Je wilt toch zoveel mogelijk onderdelen van je word document apart opslaan. Het is toch heel moeilijk om zoveel mogelijk onderdelen van een word document te ontleden en om te zetten naar xml tags. Zie zelf de XML opmaak van een Word 2003 bestand.

Die heb ik nooit bekeken, maar is dat meer dan (enorm vereenvoudigd):

XML:

<worddoc>
  <author>ACM</author>
  <startdate>...</startdate>
  <documentblob>binary data</documentblob>
</worddoc>

Ik bedoel daar vooral mee, wordt de tekst _echt_ in XML omgezet (dus dat je dingen als <opmaak type='gewoon'>deze string bevat een</opmaak> <opmaak type='bold'>dik gedrukt woord</opmaak> zou kunnen tegenkomen als je een zin met een stukje bold-tekst hebt?

We willen word documenten opslaan zodat het de komende jaren uitstekend samen werkt met .NET Framework met ASP.NET en ADO.NET in het bijzonder. Daarom wil ik het van zoveel mogelijk kanten bekijken.

Uiteraard, maar daar doel ik niet op
Bovenstaand XML-voorbeeldje zou valide XML kunnen zijn, maar toch is het totaal niet toekomstveilig dat die binaire blob later nog terug te lezen is (wat juist het voordeel van XML had moeten zijn ), simpelweg omdat je er geen decodeer-routine meer voor hebt...

[Verwijderd]

ACM schreef op 26 januari 2004 @ 12:40:
[...]

Die heb ik nooit bekeken, maar is dat meer dan (enorm vereenvoudigd):

XML:

<worddoc>
  <author>ACM</author>
  <startdate>...</startdate>
  <documentblob>binary data</documentblob>
</worddoc>

Ik bedoel daar vooral mee, wordt de tekst _echt_ in XML omgezet (dus dat je dingen als <opmaak type='gewoon'>deze string bevat een</opmaak> <opmaak type='bold'>dik gedrukt woord</opmaak> zou kunnen tegenkomen als je een zin met een stukje bold-tekst hebt?

Dit is de XML code van een word document met 1 regel arial tekst.
http://paste.pcwereld.be/showpaste.php?p=983

Ik heb maar even op en paste website gezet omdat ik nog even wil wachten met gebanned worden ;-)

Uiteraard, maar daar doel ik niet op
Bovenstaand XML-voorbeeldje zou valide XML kunnen zijn, maar toch is het totaal niet toekomstveilig dat die binaire blob later nog terug te lezen is (wat juist het voordeel van XML had moeten zijn ), simpelweg omdat je er geen decodeer-routine meer voor hebt...

Met deze beredenering zou XML dus afvallen omdat je alle voordelen van XML kwijt bent.

[4of9]

volgens de presentaties op de devdays zullen de 2 nieuwe methoden (XML en OO) nooit de relationele kant vervangen, hoogstens aanvullen, zeker vanwege performance.

(We krijgen een paar queries over een XML document te zien die 20 minuten duurde en gewoon uit de database 5 seconden ofzo.)

[ACM]

Verwijderd schreef op 26 januari 2004 @ 14:26:
Dit is de XML code van een word document met 1 regel arial tekst.
http://paste.pcwereld.be/showpaste.php?p=983

Ik heb maar even op en paste website gezet omdat ik nog even wil wachten met gebanned worden ;-)

Wow... das een aardige lap code voor 1 regeltje tekst Staan alle gedefinieerde fonts en tekens er in enzo, daar lijkt het wel op iig

Met deze beredenering zou XML dus afvallen omdat je alle voordelen van XML kwijt bent.

Sja, ik wil alleen aangeven dat je moet uitkijken met XML als een toekomstgerichte oplossing te accepteren als je er vervolgens niks anders mee doet dan je ook met een eenvoudige SQL-tabel of OO-valueobject kan bereiken

XML is niet perse onbruikbaar ofzo, maar biedt denk ik weinig voordelen t.o.v. de andere functionaliteit van je RDBMS. Dan kan je beter een XML-DB (of OO-DB) gebruiken als je dat wilt uitbuiten

[EfBe]

Verwijderd schreef op 26 januari 2004 @ 11:59:
Binnenkort gaan wij het intranet van ons bedrijf herschrijven naar .NET. We wachten hiermee tot ASP.NET 2.0 uitkomt.

Dan is dat dus niet binnenkort. ASP.NET, .NET 2.0 en Whidbey komen tegen het eind van het jaar pas (en als je pech hebt pas Q1 2005)

Rond deze zelfde tijd zal ongeveer Yukon uit komen, de nieuwe versie van SQL Server.

Dit is dus het probleem. Boze tongen beweren dat MS het niet af krijgt voor de gestelde datum. Er wordt al gefluisterd (maar het blijven geruchten ) dat MS wel eens eerst whidbey zou kunnen releasen en daarna Yukon, terwijl ze tegelijkertijd gereleased zullen moeten worden (althans, dat is de planning). Op zich lijkt me dat laatste onzin, want whidbey zit vol met Yukon spul.

Nu kunnen met deze nieuwe versie van SQL Server op drie manieren data opslaan.

- Relationeel
- Als object
- Als XML

Beetje brede vraag, maar als wij documenten willen opslaan die in Word gemaakt worden willen opslaan, hoe kunnen wij deze dan het beste opslaan?

Wat wil je ermee doen en wat staat er in die worddocs? Als je nu eens begint met het feit dat Word alleen nuttig is voor het tikken van teksten die op papier behoren te worden afgedrukt, kom je al snel uit op het feit dat het geen data opslag medium is, je kunt nl. geen reet met de data die in worddocs zit (ja, middels automation extra code, wat omslachtig werkt).

Worddocs in databases opslaan is sowieso niet erg handig. Je kunt ze veel beter in een directory laten staan en indexeren met index server. Die dan querien at runtime met een paar regeltjes code en je hebt zo je docs tevoorschijn. Als die worddocs in een database zitten, op wat voor wijze dan ook, dan heb je altijd ellende want veel extra code nodig dat totaal overbodig is, immers indexserver regelt het voor je, automatisch, admin-free.

Dus, als die worddocs zijn bedoeld voor het opslaan van data, omdat de werknemer alleen word snapt, dan doe je jezelf een veel groter plezier door een applicatie te schrijven die die data opslaat middels een eigen userinterface dan dat je word gebruikt als vergaarbak en daar dan met vieze scripts middels automatisch in moet poeren, want daar word je niet vrolijk van.

Wil je PER SE die docs opslaan in je database, en nogmaals, ik zou echt niet weten waarom, dan zou ik ze opslaan als blobs. Heb niet de illusie dat je de data IN een doc kunt querien, ook niet in Yukon, daarvoor is het wordformat (ook de xml drap) niet geschikt voor.

Maar nogmaals, als je op ASP.NET 2.0 wacht, heb je nog een klein jaartje de tijd.

[Verwijderd]

4of9 schreef op 26 januari 2004 @ 16:41:
volgens de presentaties op de devdays zullen de 2 nieuwe methoden (XML en OO) nooit de relationele kant vervangen, hoogstens aanvullen, zeker vanwege performance.

(We krijgen een paar queries over een XML document te zien die 20 minuten duurde en gewoon uit de database 5 seconden ofzo.)

Je schets hiermee een verkeerd beeld. Die query van 20 minuten was om te laten hoe je NIET met XML moet werken binnen Yukon. Nadat er indexen gebouwd waren etc duurde de query nog maar 3 minuten. Hoe lang de query er over zou doen als de data relationeel was opgeslagen is niet getoond.

[Verwijderd]

ACM schreef op 26 januari 2004 @ 17:11:
Sja, ik wil alleen aangeven dat je moet uitkijken met XML als een toekomstgerichte oplossing te accepteren als je er vervolgens niks anders mee doet dan je ook met een eenvoudige SQL-tabel of OO-valueobject kan bereiken

XML is niet perse onbruikbaar ofzo, maar biedt denk ik weinig voordelen t.o.v. de andere functionaliteit van je RDBMS. Dan kan je beter een XML-DB (of OO-DB) gebruiken als je dat wilt uitbuiten

Bij XML functionaliteit is geen sprake meer van een RDMS. Wanneer zou je dan wel gegevens in XML formaat opslaan? Alleen bij gebruik van XHTML?

[Verwijderd]

EfBe schreef op 26 januari 2004 @ 17:26:

Wat wil je ermee doen en wat staat er in die worddocs? Als je nu eens begint met het feit dat Word alleen nuttig is voor het tikken van teksten die op papier behoren te worden afgedrukt, kom je al snel uit op het feit dat het geen data opslag medium is, je kunt nl. geen reet met de data die in worddocs zit (ja, middels automation extra code, wat omslachtig werkt).

Worddocs in databases opslaan is sowieso niet erg handig. Je kunt ze veel beter in een directory laten staan en indexeren met index server. Die dan querien at runtime met een paar regeltjes code en je hebt zo je docs tevoorschijn. Als die worddocs in een database zitten, op wat voor wijze dan ook, dan heb je altijd ellende want veel extra code nodig dat totaal overbodig is, immers indexserver regelt het voor je, automatisch, admin-free.

Dus, als die worddocs zijn bedoeld voor het opslaan van data, omdat de werknemer alleen word snapt, dan doe je jezelf een veel groter plezier door een applicatie te schrijven die die data opslaat middels een eigen userinterface dan dat je word gebruikt als vergaarbak en daar dan met vieze scripts middels automatisch in moet poeren, want daar word je niet vrolijk van.

Wil je PER SE die docs opslaan in je database, en nogmaals, ik zou echt niet weten waarom, dan zou ik ze opslaan als blobs. Heb niet de illusie dat je de data IN een doc kunt querien, ook niet in Yukon, daarvoor is het wordformat (ook de xml drap) niet geschikt voor.

Maar nogmaals, als je op ASP.NET 2.0 wacht, heb je nog een klein jaartje de tijd.

Daar heb je wel gelijk in, waarom moeilijk doen als het makkelijk kan.

Nu ik een paar dagen met het idee heb rond gelopen vraag ik me eigenlijk af of Yukon wel een toegevoegde waarde heeft bovenop SQL Server 2000. Lijkt wel alsof relationeel altijd de beste keuze is. Ik heb altijd als standpunt gehad dat data genormaliseerd moet worden en daarna relationeel moet worden opgeslagen. Dan is je data altijd het meest onafhankelijk. XML output kan met SQL 2000 ook prima.

Link: http://www.databasejourna...mssql/article.php/2204421

En als je met OO je performence neer schiet (quote van MS) dan is dat eigenlijk nooit te gebruiken.

[ACM]

Verwijderd schreef op 26 januari 2004 @ 21:37:
Bij XML functionaliteit is geen sprake meer van een RDMS. Wanneer zou je dan wel gegevens in XML formaat opslaan? Alleen bij gebruik van XHTML?

De XML-functionaliteit wordt alsnog naar een RDBMS gemapped of niet dan? Of je het nou zelf mapped of door je DB laat doen... sja.

Anyway, er zijn zat gevallen waar XML wel degelijk zinvol is, datauitwisseling (SOAP, RPC met XML etc) (langdurige) opslag van metadata (een "dump" van een bibliotheek ofzo).

Maar je moet altijd proberen te achterhalen wat de beste tool voor de taak is, als een RDBMS eigenlijk beter is, dan moet je niet gaan klooien met XML.
Als een Object-storage beter is (maar dan heb ik het over een echte ODBMS) dan moet je dat gebruiken. En als XML beter is, dan moet je dat gebruiken

Maar het hangt allemaal van je requirements af, ik zou iig de boel niet laten afhangen van "dan moet ik een Klasse schrijven" of "dan moet ik helemaal een dtd gaan zitten opstellen"

[Verwijderd]

ACM schreef op 26 januari 2004 @ 22:57:
[...]

De XML-functionaliteit wordt alsnog naar een RDBMS gemapped of niet dan? Of je het nou zelf mapped of door je DB laat doen... sja.

Dat weet ik eerlijk gezegd niet. Ik dacht dat het een XML dabase was, maar de demonstratie van Yukon leek er meer op alsof het een soort van work-around-approach was inderdaad.

Anyway, er zijn zat gevallen waar XML wel degelijk zinvol is, datauitwisseling (SOAP, RPC met XML etc) (langdurige) opslag van metadata (een "dump" van een bibliotheek ofzo).

Als data uitwisseling inderdaad, maar wanneer om XML in de database opslaan?

[EfBe]

ACM schreef op 26 januari 2004 @ 22:57:
[...]
De XML-functionaliteit wordt alsnog naar een RDBMS gemapped of niet dan? Of je het nou zelf mapped of door je DB laat doen... sja.

Nee. Dit had je ook zelf kunnen bedenken, ACM
Het relationele model bestaat uit 'relations' en 'relationships'. (In het Nederlands hebben we voor beide hetzelfde woord, vandaar dat ik de engelse termen gebruik) Een relation is de relationship tussen 2 of meerdere attributes. Die wordt ook wel 'entity' genoemd of 'table'. Attributes hebben onderling ook relationships buiten een vastgestelde table/entity (inter-table relationships). Zodoende kun je dus on the fly nieuwe tables maken, we kennen dat beter als een resultset van een select. Daarom heet het ook het relationele model.

Nou, in dat model is geen plaats voor een attribute dat eigenlijk een relation is, het hele model bestaat uit relations tussen attributes niet tussen een attribute en een entity. (Als je praat over 'die 2 tabellen hebben een 1:n relatie dan lieg je in feite, want 2 (of meerdere) fields hebben een 1:n relatie, en omdat ze in die tabellen zitten hebben die tabellen dat dus ook). Indien je Xml gaat toevoegen in een field/attribute, heb je in dat attribute een nieuwe relation, table geplaatst.

Je praat in dat geval niet over het relationele model, maar over het post-relational model. Vroeger had je uniVerse (http://www-306.ibm.com/software/data/u2/universe/) en tegenwoordig is in om meer met buzzwords te spreken, dus is het Xml voor en na, het idee is hetzelfde.

Je kan dus in geen geval spreken over een relational model, want dat is het niet, de data in een attribute is wel query-baar maar maakt niet direct deel uit van het relationele model. (je kunt niet attribute's contents joinen met een table bv.)

Anyway, er zijn zat gevallen waar XML wel degelijk zinvol is, datauitwisseling (SOAP, RPC met XML etc) (langdurige) opslag van metadata (een "dump" van een bibliotheek ofzo).

XML is zelden nuttig: het is traag, onbeholpen in het gebruik in code, vreet ruimte en zet je aan tot het ondoordacht samenschrapen van data zonder enige relatie. XML is ALLEEN nuttig wanneer je een uniform overdrachtprotocol nodig hebt, bv tussen systemen of services. Het is verder nuttig bij de truuk van data conversie naar HTML omdat XSL dan zo makkelijk te gebruiken is (maar semantisch is dat natuurlijk een giga-hack). Data in XML opslaan is het meest domme dat je kunt doen: het kost mega veel resources om de data flexibel te gebruiken. Voor config filetjes, ala, maar ook daar heb je al problemen bij de interpretatie van de data an sig, en in een database al helemaal. Het lijkt wellicht leuk, dat een RDBMS xml support, maar het komt tegen een giga-prijs: de resources die verbruikt worden om XML support te kunnen leveren op een niveau zodat je geen last hebt van de crappy interpretatie mogelijkheden zijn enorm.

[ACM]

EfBe schreef op 27 januari 2004 @ 10:17:
Nee. Dit had je ook zelf kunnen bedenken, ACM

Je hebt gelijk, maar waar ik op doel (en ik kan dat niet eens onderbouwen, ik ken vrijwel niets van Yukon) is dat de XML, OO en RDBMS-representaties allemaal op dezelfde engine afgebeeld worden, en aangezien het van origine een RDBMS was, zal dat ook wel het beste de interne representatie beschrijven.
Je kan, denk ik, mbv een DTD een best aardige relationele omgeving voor een set XML-files opzetten, magoed, ik weet niet hoe Yukon dat intern allemaal gaat oplossen. Maar doorgaans werkt zoiets met meerdere frontends voor dezelfde backend

[EfBe]

Dat was ook mijn 1e idee mbt Yukon: dat ze EN een OO EN een relationele view op de data zouden leveren, waarom niet? Maar dat is niet het geval, zoals altijd volgt MS gewoon de marktleider als ze dat zelf niet zijn, en Oracle heeft dat bv ook niet.