multi language database design

[Verwijderd]

Ja ik heb al op search geklikt en wat gevonden... maar ik wou weten of dit nu net niet iets te genormalisseerd was:

tblContent
-------------
id, int
tekst, string
fkLang, int
fkVeld,int
fkTabel,int
fkPktabel,int

tblLanguage
----------------
id,int
taal,string

tblVeld // bvb omschrijving1, omschrijving2,categorienaam,typenaam,opmerkingen
---------
id,int
veld,string

tblTabellen
-------------
id,int
veld,string

wordt dit te complex?
Kan ik dit maskeren door een goede business logic op te zetten!? (juiste classes enal)
thx!

[whoami]

[rml][ Alg] Generiek multi-language systeem[/rml]

[Verwijderd]

jaja, heb gekeken....
maar dat hield geen rekening met verschillende tabellen voor content + verschillende velden daarmee

en ik wou geen oud thread oprakelen

[whoami]

Waarom wil je verschillende tabellen voor je content in op te slaan?

[Verwijderd]

bvb
je hebt een tabel producten, een tabel categorien, een tabel personeel
product heeft een omschrijving (meerdere talen) en heeft een tweede omschrijving (meerdere talen)

categorie heeft categorienaam,en omschrijving(ook meerdere talen)
en personeel heeft algemene omschrijving (ook meerdere talen)
you get my point?

[whoami]

Wel, in dat ander topic is het toch ook zo?

Je hebt daar ook Categorieën, Kenniscentra, Skills, etc..... (Ok, stond misschien niet in het topic) die allemaal in verschillende talen moeten kunnen opgeslagen worden.

Ook daar maak ik gebruik van een tabel waar alle 'content' in opgeslagen is in de verschillende talen.

Bv, stel je hebt dit record in tblCategorie:

CategorieId : 1 (Primary Key)
CategorieNaam : 1
CategorieOmschr : 2

Je hebt dan bv volgende records in de tabel tblContent:

ContentId TaalId Tekst
1 1 Dit is een categorie
1 2 This is a category
2 1 Dit is een omschrijving
2 2 This is an description

Ik haal daar ook al m'n gegevens dmv stored procedures op. Mijn applicatie zelf hoeft dus totaal niet te weten hoe die gegevens intern zijn opgeslagen.
Vb van zo'n procedure

code:

CREATE PROCEDURE GET_Category ( @p_CategoryId, @p_LanguageId )
AS
BEGIN

    SELECT tblCategory.CategoryId,
                tblContentNaam.Tekst AS CategoryNaam,
                tblContentDescr.Tekst AS CategoryDescr
     FROM  tblCategory,
               tblContent AS tblContentNaam,
               tblContent AS tblContentDescr
     WHERE tblCategory.CategoryNaam = tblContentNaam.ContentId
     AND      tblCategory.CategoryOmschr = tblContentDescr.ContentId
     AND     tblContentDescr.TaalId = @p_LanguageId
     AND     tblContentNaam.TaalId = @p_LanguageId

END

[djluc]

In het topic: [rml][ Alg] Generiek multi-language systeem[/rml] staan een paar opmerkingen over het gebruik van XML in deze situatie. Het is een topic uit 2002, en ik vraag me af of er op dit moment wel mensen zijn die denken dat je met XML hier een voordeel kunt halen.

Ik zou het sowieso gebruiken omdat ik met een Filemaker database werk, die kan je heel eenvoudig XML uit laten spugen. Op het intranet maken we gebruik van IE6 dus XSL gaat ook gebruikt worden. Maar voor mysql zie ik nog niet zo snel de voordelen omdat mysql zelf geen XML kan geven.

[Folkert]

Een algemene opmerking denk ik over het gebruik van XML en database... Ik heb ook meerdere sites gemaakt met verschillende talen. Heb een onderscheid gemaakt in content en begrippen op de site. Content staat in de database en begrippen in een xml bestand dat makkelijk in te delen is voor een taal.

Alle content uit een database met een kolomnaam van iets van taal.
Middels een session laat ik de database filteren.

Select bodytekst from content where taal = Session("taal")
(om een beeld te krijgen...)
Ook het xml bestand wordt gefilterd dmv de sessie...

Alle losse begrippen in een xml bestand dat ik per pagina include. Een snelle en eenvoudige manier... voor mij althans...

[djluc]

En maak je dan gebruik van XSL of maak je gebruik van bijvoorbeeld een PHP XML parser?

[whoami]

Mijn tegenvraag: wat is het nut van XML in deze situatie?

djluc, je zegt dat je het zou gebruiken omdat Filemaker dat heel makkelijk kan uitspugen maar wat is het functioneel nut in deze situatie? Wat kan XML in deze situatie dat je met een 'gewone' RDBMS niet kan oplossen?
Je hebt het hier enkel over de technische mogelijkheid om xml 'uit te spugen'. Echter, ik vind dat dat geen doorslaggevend argument mag zijn. Het is niet omdat iets technisch mogelijk is, dat het daarom ook nodig is.

Ik zie XML eerder als een manier om gegevens uit te wisselen.

[djluc]

Wat kan XML in deze situatie dat je met een 'gewone' RDBMS niet kan oplossen?

Ik vind het fijner werken dan CDML en omdat het mogelijkheden bied om clientside bijvoorbeeld te sorteren.

Verder is Filemaker niet zomaar een relationele database, het werken er mee is duidelijk anders dan met bijvoorbeeld MySQL, dat is in het begin heel raar als je MySQL en PHP gewend bent maar na een tijdje wordt je er erg handig in, en ga je de werkwijze wel waarderen.

Het is niet omdat iets technisch mogelijk is, dat het daarom ook nodig is.

We gaan ook werken met bijvoorbeeld trees, en dat gaat gemakkelijker in XMl, verder werkt het fijner om alles op dezelfde manier te doen. Anders krijg je allerlei technieken door elkaar, verder is deze klus ook heel erg bedoeld om te leren, en XML lijkt me heel erg nuttig, dus genoeg redenen voor mij.

[ Voor 20% gewijzigd door djluc op 25-05-2003 21:57 ]

[Folkert]

djluc schreef op 25 mei 2003 @ 17:58:
En maak je dan gebruik van XSL of maak je gebruik van bijvoorbeeld een PHP XML parser?

geen xsl, gewoon een xml parser... (ik werk alleen met asp, maar dat maakt verder niks uit)

ASP:

<%
If Session("taal") = "" Then
   Session("taal") = "nl"
End if

'Hier wordt het XML-bestand vermeld

xmlfilename = "taal.xml"

'Hier wordt een object aangemaakt die de XML opslaat
Set doc = Server.CreateObject("MSXML2.DOMDocument")

'Hier wordt gezegd dat ASP moet wachten tot XML klaar is
doc.async = False

'Hier wordt XML geladen en anders komt er een fout-melding
If Not Doc.Load(server.MapPath(xmlfilename)) Then
   Response.Write "Heeft de XML-file niet kunnen laden.<br>"
   Response.End
End If

'Hier wordt gezegd dat we Xpath gebruiken
doc.setProperty "SelectionLanguage", "XPath"

'Hier worden de juiste tags gekozen uit de XML-file
Set selectednode = doc.selectSingleNode("/talen/taal[@xml:lang='" & Session("taal") & "']")

'Hier worden alle tags gekozen
Set selectednodes = doc.documentElement.selectNodes("/talen/taal")

Function getstring(instring)
   'Deze functie zorgt ervoor dat de waarde van de tags in instring komt en HTML-klaar is
   temp = selectednode._
   selectSingleNode _
   (instring).text
   getstring = _
   server.htmlencode(temp)
End Function
'Hier wordt het bestand gemaakt in HTML
%>

en de XML ziet zo uit:

XML:

<?xml version="1.0" encoding="UTF-8"?>
<talen>
    <taal xml:lang="nl" engname="Dutch" langname="Nederlands" charset="Windows-1252">
        <!-- TOPBALK -->
        <home>Home</home>
        <informatie>Informatie</informatie>
        <vacatures>Vacatures</vacatures>
        <contact>Contact</contact>
        <sitemap>Sitemap</sitemap>
        <taalwissel>English version</taalwissel>
    </taal>
    <taal xml:lang="gb" engname="English" langname="English" charset="Windows-1252">
        <!-- TOPBALK -->
        <home>Home</home>
        <informatie>Information</informatie>
        <vacatures>Vacancies</vacatures>
        <contact>Contact</contact>
        <sitemap>Sitemap</sitemap>
        <taalwissel>Nederlandse versie</taalwissel>
    </taal>
</talen>

en in het asp document roep je het bijv. vacature element op dmv:

ASP:

<%=getstring("vacatures")%>

Kwam dit stukje tegen op internet een tijdje geleden en het werkt erg goed!

[ Voor 98% gewijzigd door Folkert op 25-05-2003 22:34 ]

[Creepy]

djluc schreef op 25 May 2003 @ 21:56:
[...]

Ik vind het fijner werken dan CDML en omdat het mogelijkheden bied om clientside bijvoorbeeld te sorteren.

Fijner werken.. das persoonlijk, en het wel of niet gebruik maken van XML of een (R)DBMS heeft vrij weinig te maken met dingen client side of server side doen (sorteren bijv. kan je ook clientside afvangen i.p.v. in de DMBS).

Verder is Filemaker niet zomaar een relationele database, het werken er mee is duidelijk anders dan met bijvoorbeeld MySQL, dat is in het begin heel raar als je MySQL en PHP gewend bent maar na een tijdje wordt je er erg handig in, en ga je de werkwijze wel waarderen.

Let wel op dat er aan de werkwijze van filemaker ook wat haken en ogen kleven. Zo gaat filemaker (eh, filemaker 4 in elk geval ) altijd uit van 1 centrale tabel waar je altijd je relaties mee legt (een stervorm dus..), dus een ECHT relationeel database systeem wil ik het niet noemen..

We gaan ook werken met bijvoorbeeld trees, en dat gaat gemakkelijker in XMl,

In een RDBMS is een tree nou ook niet zo heel moeilijk hoor

verder werkt het fijner om alles op dezelfde manier te doen. Anders krijg je allerlei technieken door elkaar, verder is deze klus ook heel erg bedoeld om te leren, en XML lijkt me heel erg nuttig, dus genoeg redenen voor mij.

Dus voor jou persoonlijk.. ok.. XML omdat je het gemakelijker vind, maar waarom zou de topicstarten dan XML moeten gaan gebruiken?
Ook ik zie XML puur en alleen voor het uitwisselen van gegevens, maar niet voor opslag van gegevens. Als er veel data opgeslagen moet worden zal een (goed geconfigureerd) (R)DBMS de benodigde data velen malen sneller op kunnen halen dan als er gebruik gemaakt word van XML.

[Folkert]

Creepy schreef op 25 May 2003 @ 23:05:
[...]
Dus voor jou persoonlijk.. ok.. XML omdat je het gemakelijker vind, maar waarom zou de topicstarten dan XML moeten gaan gebruiken?
Ook ik zie XML puur en alleen voor het uitwisselen van gegevens, maar niet voor opslag van gegevens. Als er veel data opgeslagen moet worden zal een (goed geconfigureerd) (R)DBMS de benodigde data velen malen sneller op kunnen halen dan als er gebruik gemaakt word van XML.

Dat ben ik volledig met je eens! Veel data is inherent aan een database. XML is voor mij ook zeker geen optie. Aangezien een site met meerdere talen niet alleen bestaat uit content maar ook kleine elementen als plaatjes, knoppen, en andere korte stukken tekst, kies ik voor dat soort dingen XML omdat dat erg makkelijk aan te passen is, snel, dynamisch etc. Maar om nou de content in XMl te proppen...hm, nee...

[Verwijderd]

waarschijnlijk ga ik de interface dan ook in xml stoppen.
Eventueel zou de admin dit kunnen aanpassen met behulp van load xml document en save xml document