[MySQL] 2 tabellen combineren tot 1

[Verwijderd]

Okee

ik heb bij het opzetten van de database voor mijn website 2 tabellen gemaakt; 1 voor het menu, en 1 voor de content - dit omdat ik dacht dat dat in een later stadium handig zou kunnen zijn. Nu ik echter de site -en vooral het CMS- iets meer uitgewerkt heb, ben ik van mening dat het onzin is, en wil ik van deze 2 tabellen 1 maken.

mijn 2 tabellen op dit moment zijn 'menus' en 'content' . de nieuwe tabel moet 'data' gaan heten.

ik denk dat het zo het duidelijkste is (de conversie)

code:

content.pageid = menus.pageid > data.pageid
content.language = menus.language > data.language
content.pageheader > data.page_header
content.allowhtml > data.allowhtml
menus.subof > data.subof
menus.itemname > data.menu_itemname
menus.banner > data.banner
content.content > data.content
menus.lastupdate > data.lastupdate
(new) > data.keywords

ik zat zelf te denken om het e.e.a. met PHP om te zetten, maar volgens mij moet dit makkelijker kunnen (ingebouwde functie in mysql? of misschien in de SQL standaard?) ik heb al het e.e.a. uitgezocht enzo maar ik kom er niet echt uit.

iemand die hier ervaring mee heeft en mij kan vertellen wat ik het beste kan doen?

(disclaimer) search gebruikt niks nuttigs kunnen vinden; mysql.com/doc gecheckt - ook niks;

[Crazy D]

Volgens mij (= uit mn hoofd) kun je een select into doen met een join. Ik zou me alleen goed afvragen of het wel echt is wat je wilt. Imho is het logischer/handiger om het menu en de content apart te houden, zodat je (nu of in de toekomst) ook pagina's kunt maken die niet rechtstreeks in het menu hangen. Kun je natuurlijk wel weer stoeien met een visible ja/nee veld, maar dat is imho niet zo heel handig.
Gezien het language veld begrijp ik dat er meerdere talen mogelijk zijn, dan is het imho helemaal handiger om het apart te houden.

[Verwijderd]

Crazy_D schreef op 11 september 2002 @ 15:50:
Volgens mij (= uit mn hoofd) kun je een select into doen met een join. Ik zou me alleen goed afvragen of het wel echt is wat je wilt. Imho is het logischer/handiger om het menu en de content apart te houden, zodat je (nu of in de toekomst) ook pagina's kunt maken die niet rechtstreeks in het menu hangen. Kun je natuurlijk wel weer stoeien met een visible ja/nee veld, maar dat is imho niet zo heel handig.
Gezien het language veld begrijp ik dat er meerdere talen mogelijk zijn, dan is het imho helemaal handiger om het apart te houden.

zit zeker wat in... losse pagina's moet ook mogelijk zijn, dus dit is dan toch waarschijnlijk niet precies wat ik wil...

een veld bestaat op dit moment uit een combinatie pageid en language... bijv. pageid 100 kan er 2 keer zijn. is dus niet uniek. zodoende moet ik dan in beide tabellen pageid EN language hebben om de koppeling te kunnen maken. beetje vies...toch? of is dat alleen maar iets wat in m'n kop zit?

nog even de huidige tabelstructuur:

code:

CREATE TABLE content (
pageid varchar(5) NOT NULL,
allowhtml char(1) default '0',
language varchar(2) NOT NULL,
pageheader varchar(50) NOT NULL,
content TEXT NOT NULL,
lastupdate timestamp(14) );

CREATE TABLE menus (
pageid varchar(5),
subof varchar(5) NOT NULL,
language varchar(2) NOT NULL,
itemname varchar(20),
banner varchar(1),
subtitle varchar(70) );

ik heb zelf hier een beetje gemengde gevoelens over... ik weet niet precies waarom, maar er klopt naar mijn idee gewoon iets niet (te veel queries nodig om de zooi op te vragen...dubbele velden, etc)

[Verwijderd]

ik zou persoonlijk een pageID uniek maken, geen dubbele dus, en dan gewoon doornummeren door de talen heen (snap je!?)

code:

PageID  |Language  |...
-----------------------
0       |NL        |...
1       |NL        |...
3       |NL        |...
4       |EN        |...
5       |EN        |...
6       |EN        |...
7       |FR        |...
...     |...       |...

zo dus.
Omdat ik bijna zeker ben dat als je taal + pageID als key voor een page neemt je zeker een keer een fout maakt daarin, en op deze manier is het gewoon intuitiever...

[Crazy D]

Als je met meerdere talen werkt kom je al heel snel op een tabel waar je een dubbele key gebruikt: taalid + pageid

Je zou je tabellen dan zo op kunnen zetten (los polsje):
Talen: id, omschrijving
Menu: je menu tabel, zonder languageid dan. De titel ed. zou je dan in de menu tabel als "default" kunnen gebruiken voor het geval die niet in de specifieke taal beschikbaar is
Menutaal tabel: menuid, taalid, omschrijving.

En voor de content in de talen krjig je dus een contenttaal tabel met alleen taalid, pageid, en de content in die betreffende taal, waarbij je dan in de content tabel zelf die titel ed. als default kunt gebruiken (net als bij menu).

Snap je? (waarschijnlijk niet want mijn uitleg kwaliteiten zijn net zo goed als dat ik Russisch spreek...).

edit:
Mister R:
het voordeel van de pagina's hun eigen id houden en van taal-paginaid een unieke combie maken is dat je gewoon kunt verwijzen naar "joh kijk document 123 ff" en dat de gebruiker dan dat document krijgt in de taal die hij wil. Als je ze allemaal losse id's geeft moet je zeggen "joh kijk document 123 voor engels, 124 voor frans" etc wat erg onhandig werkt En er zullen vast nog wel betere redenen te verzinnen zijn maar dit zou voor mij al genoeg reden zijn om 1 document in verschillende talen wel hetzelfde id te geven.

edit 2:
en als je zelf een foutje maakt, en je hebt de db 'goed' aangemaakt zodat de combinatie van taal en pageid uniek moet zijn, mekkert je database vanzelf wel

[Verwijderd]

Crazy_D schreef op 11 september 2002 @ 16:22:
edit 2:
en als je zelf een foutje maakt, en je hebt de db 'goed' aangemaakt zodat de combinatie van taal en pageid uniek moet zijn, mekkert je database vanzelf wel

hoe doek da?

[ Voor 0% gewijzigd door Verwijderd op 11-09-2002 16:58 . Reden: smily gefixt ]

[Pogostokje]

Constraints bouwen.

[Crazy D]

Door die 2 velden saampjes primary key te maken (in phpmyadmin bij het aanmaken dus de bullets onder "primary" bij die 2 velden aan te bulletten...).