[MySQL] LIKE query op komma-gescheiden veld

[plakbandrol]

Ik heb een column waar waardes inkomen die door een komma gescheiden zijn; bijvoorbeeld

,1,2,5,7,8,9,11,15,103,

in een andere tabel staan nummers die hiermee vergeleken moeten worden, ik wil nu dat sql de waardes geven die overeenkomen

dus in tabel1:
ID code
1 ,2,5,3,7,8,9,11,15,103,
2 ,3,38,3,13,

en in tabel2:
ID match
1 6
2 10

nou wil ik dus kijken welke waardes uit tabel 2 voorkomen in tabel 1, normaalgesproken doe ik dat met een query als:

select * from tabel1 where tabel2.match like tabel1.code

maar het probleem is dat als ik zoek naar de waarde 1, hij ook een resultaat geeft als er 10 of 100 voorkomt, hoe maak ik hem duidelijk dat het losse waardes zijn door komma gescheiden?

eigenlijk zou ik een query moeten hebben in de trent van

select * from tabel1 where tabel2.match like ','+tabel1.code+','

maar die + werkt natuurlijk niet in sql.. maar hoe kan ik dit anders oplossen?

[whoami]

Klinkt als een slecht datamodel....

[Jelmer]

Ik sluit me in eerste instantie geheel aan bij whoami.

Daarnaast heb je in SQL de concat() functie om dingen aan elkaar te plakken.

[plakbandrol]

whoami schreef op 29 maart 2004 @ 11:54:
Klinkt als een slecht datamodel....

hoezo, is komma gescheiden waardes nou zoiets vreemds?

[Brakkie]

Klinkt als iets heel fouts. Maar alsje het toch wilt zou ik het zo doen.

De waarde uit tabel 1 en tabel 2 selecteren. Van allebei een array bouwen. En dan met array_diff() aan de slag gaan.

[ Voor 15% gewijzigd door Brakkie op 29-03-2004 12:02 ]

[mulder]

in een database wel, daar heb je nl 'records' voor

[plakbandrol]

Don Facundo schreef op 29 maart 2004 @ 12:00:
in een database wel, daar heb je nl 'records' voor

is ook mogelijk, maar dan krijg ik een aparte tabel van 2 columns met enorm veel records, dit leek me een simpelere oplossing

[whoami]

plakbandrol schreef op 29 maart 2004 @ 12:03:
[...]

is ook mogelijk, maar dan krijg ik een aparte tabel van 2 columns met enorm veel records, dit leek me een simpelere oplossing

Zoals je ziet, levert jouw oplossing dus meer problemen op, dan dat je er voordeel mee haalt.
Wat versta jij onder 'enorm veel records'? 1000? 10.000? 100.000? Da's allemaal niet zoveel, en je kan op die manier veel sneller, makkelijker, flexibeler zoeken dan als je gaat prutsen met comma-separated values enzo.

[plakbandrol]

whoami schreef op 29 maart 2004 @ 12:08:
[...]


Zoals je ziet, levert jouw oplossing dus meer problemen op, dan dat je er voordeel mee haalt.
Wat versta jij onder 'enorm veel records'? 1000? 10.000? 100.000? Da's allemaal niet zoveel, en je kan op die manier veel sneller, makkelijker, flexibeler zoeken dan als je gaat prutsen met comma-separated values enzo.

veel in verhouding tot de andere tabellen, maar op die manier moet ik via een subquery zoeken, of dat nou veel flexibeler is weet ik niet, maar een LIKE query is ook niet echt elegant dat klopt

[Anoniem: 13701]

Dit lijkt me inderdaad ook niet zo goede manier op het op te lossen, dan maar veel records in een db, is misschien wel groter, maar het lijkt me niet dat er dan miljoenen records inkomen (correct me if I'm wrong).

Het is ook vrij logisch dat als je like '1' doet dat dan ook de waarden 10 en 100 enz voorkomen. Je zou dit kunnen oplossen door een except erbij te plaatsen die waarden like '10' doet excepten. Ik weet overigens niet of dat deze query goed wordt uitgevoerd, ben ook niet in de positie om dat te testen.

edit:

Doh...mysql ondersteund geen except denk ik zomaar...:(

[ Voor 10% gewijzigd door Anoniem: 13701 op 29-03-2004 12:14 ]

[whoami]

plakbandrol schreef op 29 maart 2004 @ 12:11:
[...]

veel in verhouding tot de andere tabellen, maar op die manier moet ik via een subquery zoeken, of dat nou veel flexibeler is weet ik niet, maar een LIKE query is ook niet echt elegant dat klopt

Een LIKE query is helemaal niet bedoeld voor situaties zoals diegene in jouw topicstart.

Mits je goeie indexen maakt en gebruikt, is de oplossing die geen gebruik maakt van comma sep. values, veruit de beste.

[Anoniem: 13701]

Ben ik geheel mee eens. Via complexe queries zulke problemen oplossen kan nooit goed zijn.

[plakbandrol]

Ik zal anders even kort de context toelichten, ik heb een tabel met allemaal tv programma's, nu wil ik dat een gebruiker zoekwoorden kan opgeven zodat hij tv programma's teruggeeft die daaraan voldoen..

naast een zoekwoord kan er ook een genre worden opgegeven, en de zenders waarin gezocht moet worden, ik wil dus dat als een gebruiker opgeeft dat er gezocht moet worden in zender 4,5 en 6, dat mysql dan alleen een match geeft bij een programma die op één van deze zenders komt.

het is misschien niet de mooiste oplossing, maar als het betrouwbaar werkt, en niet langzamer is dan zie ik het probleem ook niet, een aparte tabel voor zoiets simpels is ook niet de mooiste oplossing imho

[whoami]

Dat is het probleem: het is niet betrouwbaar, het is trager, en het is niet onderhoudbaar.
Een aparte tabel is wel de beste en eenvoudigste oplossing. Jij doet veel te moeilijk voor zo iets simpels.

Lees misschien eens iets over normaliseren.

[ Voor 48% gewijzigd door whoami op 29-03-2004 12:36 ]

[plakbandrol]

whoami schreef op 29 maart 2004 @ 12:35:
Dat is het probleem: het is niet betrouwbaar, het is trager, en het is niet onderhoudbaar.

niet betrouwbaar? zolang die values op dezelfde manier erin komen kan ik me geen scenario voorstellen waardoor dit fout kan gaan, onderhoudbaar is niet belangrijk, en trager weet ik niet, een subquery in een andere tabel is volgens mij ook niet de meest snelle manier.

Een aparte tabel is wel de beste en eenvoudigste oplossing. Jij doet veel te moeilijk voor zo iets simpels.

Maar is een aparte tabel niet moeilijker dan dit?

Lees misschien eens iets over normaliseren.

al gebeurd

[plakbandrol]

maargoed ik zal het wel met een aparte tabel proebren voordat ik flames krijg

[whoami]

plakbandrol schreef op 29 maart 2004 @ 12:38:
[...]

niet betrouwbaar? zolang die values op dezelfde manier erin komen kan ik me geen scenario voorstellen waardoor dit fout kan gaan, onderhoudbaar is niet belangrijk, en trager weet ik niet, een subquery in een andere tabel is volgens mij ook niet de meest snelle manier.

Onderhoudbaarheid is in ieder software-project belangrijk.
Je kan het nog op andere manieren ook oplossen dan met een subquery vermoed ik, maar je zult in ieder geval tot een oplossing komen. Iets wat je nu nog niet hebt.

Maar is een aparte tabel niet moeilijker dan dit?

Nee.

[Anoniem: 17852]

whoami schreef op 29 maart 2004 @ 12:08:
[...]


Zoals je ziet, levert jouw oplossing dus meer problemen op, dan dat je er voordeel mee haalt.

Meer problemen om dat íe uit het hoofdje niet deze query kan bouwen?

Is dat jou conclusie zonder dat je enig idee hebt welk datamodel er achter gaat en welke functionaliteiten reeds geschreven zijn? pfffff...

In dit geval even als volgt coderen:

code:

where table2.match like (concat('%,', table1.code, ',%'))

Problem solved!

[whoami]

Anoniem: 17852 schreef op 29 maart 2004 @ 12:43:
[...]


Meer problemen om dat íe uit het hoofdje niet deze query kan bouwen?

Is dat jou conclusie zonder dat je enig idee hebt welk datamodel er achter gaat en welke functionaliteiten reeds geschreven zijn? pfffff...

Pffff, zal ik je eens wat zeggen?
Hoe ga je op een flexibele manier een andere query maken ?
Hoe ga je te werk als er records moeten toegevoegd worden?
Hoe snel gaat dit werken? Kan je indexen gebruiken?
Wat als je wilt weten hoeveel keer code 'xxx' voorkomt ?

code:

where table2.match like (concat('%,', table1.code, ',%'))

Problem solved!

Ja, dit gaat lekker snel als een een paar records hebt....
Dit resulteert hoedanook in een table scan.

[ Voor 3% gewijzigd door whoami op 29-03-2004 13:11 ]

[plakbandrol]

Anoniem: 17852 schreef op 29 maart 2004 @ 12:43:
[...]


Meer problemen om dat íe uit het hoofdje niet deze query kan bouwen?

Is dat jou conclusie zonder dat je enig idee hebt welk datamodel er achter gaat en welke functionaliteiten reeds geschreven zijn? pfffff...

In dit geval even als volgt coderen:

code:

where table2.match like (concat('%,', table1.code, ',%'))

Problem solved!

[whoami]

Tja, de makkelijkste oplossing kiezen is niet altijd de beste. Vroeg of laat loop je tegen dit probleem aan hoor.

Maar goed, jij je zin. 't Is jouw probleem.

Ik ben blij dat je niet in m'n team zit.

[ Voor 13% gewijzigd door whoami op 29-03-2004 13:04 ]

[Janoz]

Waarom gebruik je eigenlijk een database?

Als je toch geen gebruik van relaties, indices, subqueries en integriteits controle gebruik wilt maken en de daadwerkelijke logica toch in je eigen programma wilt proppen kun je net zo goed met platte bestanden gaan werken. Heb je ook niet meer die 'querie overhead'. Ik kan trouwens nog zo 10 problemen opnoemen waar je tegenaan zult lopen, maar aangezien er in dit draadje een hoog koppigheid gehalte hangt laat ik dat maar achterwege. Verder sluit ik me aan bij whoami, ik ben blij dat jullie geen collega van mij zijn....

[Anoniem: 17852]

whoami schreef op 29 maart 2004 @ 12:50:
[...]

Pffff, zal ik je eens wat zeggen?

Tuurlijk!

Hoe ga je op een flexibele manier een andere query maken ?

Heb je enig idee waar je op doelt? Klinkt voor mij net zo vaag als: Hoe ga je nu gebruik maken van je Playstation?

Hoe ga je te werk als er records moeten toegevoegd worden?

In een genormaliseerd model gebruik je dan queries... ik denk dat je die hier ook nodig hebt... Misschien zien ze er iets anders uit.

Hoe snel gaat dit werken? Kan je indexen gebruiken?

Hangt van de snelheid van je database-server af in combinatie met het aantal records lijkt me. Ik kan je wel vertellen dat ik op een database met gebruik van een REGEXP i.p.v. like met +5000 records binnen tienden van een seconde blijf.

Wat als je wilt weten hoeveel keer code 'xxx' voorkomt ?

... ik begrijp je echt niet. In een genormaliseerde database maak in dit geval gebruik van een koppeltabel (tabel1_tabel2_koppeling) met hierin ID1 en ID2.

Nu hebben we de foreign_id ingebakken in tabel2. Maakt dat alles nu helemaal anders? Je kan toch nog steeds SQL gebruiken?

code:

select count(*) from table2 where table2.match like concat('%,', id, ',%') ;

Ja, dit gaat lekker snel als een een paar records hebt....

Geven we toch een ander voorbeeld... kijken hoe je dat oplost:

je hebt een nieuwstabel (met id, titel, datum, tekst)
en een agenda (met id, datum, titel, locatie, tekst)
en een memo (met id, datum, titel, tekst)
+ nog eens 20 functionaliteiten.......

en een rubriekentabel die je op de site hanteert... (met id, rubriek_naam, rubriek_omschrijving).

Nu wil je voor alle functionaliteiten gebruik gaan maken van de rubriekentabel om deze te kunnen rubriceren.

Normaliseren tot het diepste nivo? of is het in dit geval handiger om bij elke functionaliteit een veldje rubriek te maken (varchar 255 bijv.) met daarin alle foreign_id's...

Ik weet wel waar ik voor kies: normaliseren hoeft het me niet onnodig lastig maken... daar is het immers niet voor bedoeld.

[Anoniem: 17852]

Janoz schreef op 29 maart 2004 @ 13:10:
Waarom gebruik je eigenlijk een database?

Als je toch geen gebruik van relaties, indices, subqueries en integriteits controle gebruik wilt maken en de daadwerkelijke logica toch in je eigen programma wilt proppen kun je net zo goed met platte bestanden gaan werken. Heb je ook niet meer die 'querie overhead'. Ik kan trouwens nog zo 10 problemen opnoemen waar je tegenaan zult lopen, maar aangezien er in dit draadje een hoog koppigheid gehalte hangt laat ik dat maar achterwege. Verder sluit ik me aan bij whoami, ik ben blij dat jullie geen collega van mij zijn....

Fijn dat iedereen op jouw perfecte nivo kan programmeren, en dat ze niet door fouten te maken hoeven te leren!!

Is die arrogante houding echt nodig? ...wat mij betreft: ´schop een modje'......???????!!!!!!

edit:

Valt me nu eigenlijk pas op dat je nog iets tussen de regels zegt ook: daadwerkelijk logica hoort in een database? Heb je dan nog wel een programmeertaal nodig????!!!!

[ Voor 11% gewijzigd door Anoniem: 17852 op 29-03-2004 13:23 . Reden: iets opgevallen ]

[gorgi_19]

Anoniem: 17852 schreef op 29 maart 2004 @ 13:21:
Fijn dat iedereen op jouw perfecte nivo kan programmeren, en dat ze niet door fouten te maken hoeven te leren!!

Blijft de vraag waarom je nog een database gebruikt, aangezien je niet of nauwelijks van die mogelijkheden gebruikt maakt?

Valt me nu eigenlijk pas op dat je nog iets tussen de regels zegt ook: daadwerkelijk logica hoort in een database? Heb je dan nog wel een programmeertaal nodig????!!!!

Datalogica is iets anders dan business logica.

[ Voor 27% gewijzigd door gorgi_19 op 29-03-2004 13:24 ]

[curry684]

Okee na de onzin hierboven heb ik weinig zin om genuanceerd te reageren: dit is een van de meest onzinnige datamodellen die ik hier in Programming & Webscripting ooit langs heb zien komen, en dat zegt wel wat

Feit: LIKE is rampzalig traag. Het is alleen enigszins vooruit te branden als je alleen een procentje achterin hebt ('Piet%') omdat er dan indexes gebruikt kunnen worden. Met een procent ervoor moet iedere record gescanned en geprocessed worden, wat rampzalig traag is. Not to mention type-unsafe, unmaintainable en onacceptabel error-prone: Murphy stelt dat er ooit iemand ",5,684.0,zaad,10,5,<dikke html code erbij etc.>" in je tabel gaat slingeren.

plakbandrol schreef op 29 maart 2004 @ 12:39:
maargoed ik zal het wel met een aparte tabel proebren voordat ik flames krijg

Er is hier niemand aan het flamen. Jij komt op een publiek forum vragen om hulp, en mensen leggen je uit dat je een idioot datamodel aan het gebruiken bent, en steken er zelfs tientallen minuten in om je uit te leggen hoe je wel stabiele, maintainable en snelle databases bouwt. Als dat al flamen is...

[Janoz]

Anoniem: 17852 schreef op 29 maart 2004 @ 13:13:
[...]

Tuurlijk!

[...]

Heb je enig idee waar je op doelt? Klinkt voor mij net zo vaag als: Hoe ga je nu gebruik maken van je Playstation?

Dat bepaalde standaard methodieken je vaag in de oren klinken was al redelijk duidelijk...

[...]

In een genormaliseerd model gebruik je dan queries... ik denk dat je die hier ook nodig hebt... Misschien zien ze er iets anders uit.

Je snapt het probleem niet. Het gaat niet over hoe je de daadwerkelijken verandering toepast, maar hoe je het in je ontwerp verwerkt...

[...]

Hangt van de snelheid van je database-server af in combinatie met het aantal records lijkt me. Ik kan je wel vertellen dat ik op een database met gebruik van een REGEXP i.p.v. like met +5000 records binnen tienden van een seconde blijf.

Een database heeft meer dan alleen records. Het heeft ook views, indexes, constraints enz enz. Dat je binnen tienden van seconden blijft is heel leuk, maar ik ben benieuwd naar:
1 Hoe leesbaar je queries zijn
2 Hoe snel de querie uitgevoerd zou worden met fatsoenlijke indices en een genormaliseerd datamodel
3 Of je daadwerkelijk ruimte bespaart. Wat ga je bijvoorbeeld doen waneer je geconcateneerde string meer dan 255 tekens heeft, ga je er dan een text van maken?

[...]

... ik begrijp je echt niet. In een genormaliseerde database maak in dit geval gebruik van een koppeltabel (tabel1_tabel2_koppeling) met hierin ID1 en ID2.

Nu hebben we de foreign_id ingebakken in tabel2. Maakt dat alles nu helemaal anders? Je kan toch nog steeds SQL gebruiken?

code:

select count(*) from table2 where table2.match like concat('%,', id, ',%') ;

* Janoz knipperd heel hard met zijn ogen. Zie ik hier iemand die serieus probeert te beweren dat een querie met een like niet significant trager is dan een integer vergelijking op een index veld?

[...]


Geven we toch een ander voorbeeld... kijken hoe je dat oplost:

je hebt een nieuwstabel (met id, titel, datum, tekst)
en een agenda (met id, datum, titel, locatie, tekst)
en een memo (met id, datum, titel, tekst)
+ nog eens 20 functionaliteiten.......

en een rubriekentabel die je op de site hanteert... (met id, rubriek_naam, rubriek_omschrijving).

Nu wil je voor alle functionaliteiten gebruik gaan maken van de rubriekentabel om deze te kunnen rubriceren.

Wat bedoel je met rubriek? Onderwerp? In dat geval zou ik gewoon aan alle tabellen een rubriek ID meegeven.

Normaliseren tot het diepste nivo? of is het in dit geval handiger om bij elke functionaliteit een veldje rubriek te maken (varchar 255 bijv.) met daarin alle foreign_id's...

zie boven. * Janoz knippert verder.

Ik weet wel waar ik voor kies: normaliseren hoeft het me niet onnodig lastig maken... daar is het immers niet voor bedoeld.

Arthur beste vent, ik raad je aan eens een boek te lezen voordat je weer zulke onzin gaat verkondigen, Je hebt blijkbaar ook niet helemaal begrepen waar normaliseren wel voor bedoeld is.

[whoami]

Anoniem: 17852 schreef op 29 maart 2004 @ 13:13:

In een genormaliseerd model gebruik je dan queries... ik denk dat je die hier ook nodig hebt... Misschien zien ze er iets anders uit.

Ja, maar je mag iedere keer je komma-gescheiden veld gaan aanpassen. Dat gaat lekker bij het verwijderen: record ophalen, door veld lopen, waarde zoeken, verwijderen, ervoor zorgen dat je komma's goed staan,etc....

Hangt van de snelheid van je database-server af in combinatie met het aantal records lijkt me. Ik kan je wel vertellen dat ik op een database met gebruik van een REGEXP i.p.v. like met +5000 records binnen tienden van een seconde blijf.

Performance van queries hangt (naast de kracht van je DB server) vooral af van je datamodel, en de indexen die je gemaakt hebt en die kunnen gebruikt worden.
Als je een LIKE gebruikt, die begint met een wildcard, dan kan je het gebruik van indexen al vergeten, waardoor het DBMS een table scan zal moeten doen. Dwz, alle records 1 voor 1 overlopen, en kijken of ze aan die voorwaarde voldoen. Lekker snel....

... ik begrijp je echt niet. In een genormaliseerde database maak in dit geval gebruik van een koppeltabel (tabel1_tabel2_koppeling) met hierin ID1 en ID2.

Door gebruik te maken van een koppeltabel kan je veel snellere queries schrijven, en heb je constraint-checking.

Nu hebben we de foreign_id ingebakken in tabel2. Maakt dat alles nu helemaal anders? Je kan toch nog steeds SQL gebruiken?

Een veld met waarden die er komma-gescheiden in gepropt zijn, kunnen geen gebruik maken van foreign constraints.

Geven we toch een ander voorbeeld... kijken hoe je dat oplost:

je hebt een nieuwstabel (met id, titel, datum, tekst)
en een agenda (met id, datum, titel, locatie, tekst)
en een memo (met id, datum, titel, tekst)
+ nog eens 20 functionaliteiten.......

en een rubriekentabel die je op de site hanteert... (met id, rubriek_naam, rubriek_omschrijving).

Nu wil je voor alle functionaliteiten gebruik gaan maken van de rubriekentabel om deze te kunnen rubriceren.

Normaliseren tot het diepste nivo? of is het in dit geval handiger om bij elke functionaliteit een veldje rubriek te maken (varchar 255 bijv.) met daarin alle foreign_id's...

Wat denk je zelf? Normaliseren natuurlijk. Die andere oplossing resulteert in trage queries, en een beperking: wat als je nog een rubriek wilt toevoegen, en je varchar(255) veld bevat al 253 karakters?

Ik weet wel waar ik voor kies: normaliseren hoeft het me niet onnodig lastig maken... daar is het immers niet voor bedoeld.

Normaliseren maakt het je makkelijk. Het is misschien initieel wat meer werk, maar je voorkomt er problemen mee, en zorgt voor een veel performanter systeem.
Maar goed, nu ben ik zeker van m'n eerdere stelling.

_{Leuk, ben je een reactie aan het typen, komt er ff iemand wat vragen en ondertussen is alles wat je zegt, al door anderen gezegd.}

[ Voor 3% gewijzigd door whoami op 29-03-2004 13:30 ]

[curry684]

Anoniem: 17852 schreef op 29 maart 2004 @ 13:21:
[...]
Fijn dat iedereen op jouw perfecte nivo kan programmeren, en dat ze niet door fouten te maken hoeven te leren!!

Het feit dat plakbandrol hier binnen komt met een fout datamodel is geen probleem. Waar Janoz op doelt is dat ie ondanks afraden door 3+ professionele ontwikkelaars koppig aan dat foute datamodel vasthoudt. Dan geven we het op ja, als je niet van je fouten wil leren.

edit:

Valt me nu eigenlijk pas op dat je nog iets tussen de regels zegt ook: daadwerkelijk logica hoort in een database? Heb je dan nog wel een programmeertaal nodig????!!!!

Triggers en stored procedures zijn inderdaad uitgevonden om logica in databases in te bouwen waar die inherent is aan de data. Applicatie-specifieke logica en de feitelijke business rules horen echter client-side (of middle-tier) te blijven, en daarvoor blijf je dus hoe dan ook je programmeertalen nodig hebben.

[Anoniem: 17852]

gorgi_19 schreef op 29 maart 2004 @ 13:22:
[...]
Blijft de vraag waarom je nog een database gebruikt, aangezien je niet of nauwelijks van die mogelijkheden gebruikt maakt?
[...]

Kom op nou.. normaliseren hoef je toch niet tot het stomste nivo uit te voeren? Ik kreeg laatst een database met n.a.w. gegevens (perfect genormaliseerd):
aanhef in een aparte tabel met koppeltabel
titulatuur in een aparte tabel met koppeltabel
voorvoegsels in een aparte tabel met koppeltabel
...
lekker als een een CSV bestandje met load data into table infile '' wilt inlezen

Je database normaliseren doe je net zolang als dat het nuttig is....

[gorgi_19]

Anoniem: 17852 schreef op 29 maart 2004 @ 13:28:
[...]

Kom op nou.. normaliseren hoef je toch niet tot het stomste nivo uit te voeren? Ik kreeg laatst een database met n.a.w. gegevens (perfect genormaliseerd):
aanhef in een aparte tabel met koppeltabel
titulatuur in een aparte tabel met koppeltabel
voorvoegsels in een aparte tabel met koppeltabel
...
lekker als een een CSV bestandje met load data into table infile '' wilt inlezen

Je database normaliseren doe je net zolang als dat het nuttig is....

Nee, en normaliseren wordt ook zelden tot het allerlaagste niveau gedaan. En je ontwijkt de vraag: Waarom gebruik je een database als je toch niet van de mogelijkheden gebruikt maakt? Levert alleen maar overhead op.

Verder vind ik dit ook een vrij apart model, om eerlijk te zijn.

[ Voor 5% gewijzigd door gorgi_19 op 29-03-2004 13:31 ]

[Janoz]

Anoniem: 17852 schreef op 29 maart 2004 @ 13:21:
[...]


Fijn dat iedereen op jouw perfecte nivo kan programmeren, en dat ze niet door fouten te maken hoeven te leren!!

Natuurlijk mag je fouten maken. Er is echter een groot verschil tussen een fout maken en iets fout aanleren. Als je iets aanleerd kun je het beter goed aanleren ipv fout.

Is die arrogante houding echt nodig? ...wat mij betreft: ´schop een modje'......???????!!!!!!

D'r is er hier 1tje begonnen met een arrogante houding, en dan kun je inderdaad enig repliek verwachten.

edit:

Valt me nu eigenlijk pas op dat je nog iets tussen de regels zegt ook: daadwerkelijk logica hoort in een database? Heb je dan nog wel een programmeertaal nodig????!!!!

Zie gorgi_19

[whoami]

curry684 schreef op 29 maart 2004 @ 13:28:
[...]

(Applicatie-specifieke logica en de feitelijke business rules horen echter client-side (of middle-tier) te blijven, en daarvoor blijf je dus hoe dan ook je programmeertalen nodig hebben.

Hmmm, ik denk dat we hier nog wel eens een apart discussie-topic kunnen over openen.
Je kan bepaalde BL evengoed in je database kwijt hoor, dat kan behoorlijk voordelig zijn voor de performance, al boet je dan wel wat aan flexibiliteit in.

[Creepy]

Anoniem: 17852 schreef op 29 maart 2004 @ 13:13:
[...]
Hangt van de snelheid van je database-server af in combinatie met het aantal records lijkt me. Ik kan je wel vertellen dat ik op een database met gebruik van een REGEXP i.p.v. like met +5000 records binnen tienden van een seconde blijf.

Ik hoop dat je je realiseert dat dat enorm traag is. 5000 records is niks in een beetje database. En als je daar een paar tienden van seconden over doet.......

[...]

... ik begrijp je echt niet. In een genormaliseerde database maak in dit geval gebruik van een koppeltabel (tabel1_tabel2_koppeling) met hierin ID1 en ID2.

Nu hebben we de foreign_id ingebakken in tabel2. Maakt dat alles nu helemaal anders? Je kan toch nog steeds SQL gebruiken?

code:

select count(*) from table2 where table2.match like concat('%,', id, ',%') ;

Maar het komt de snelheid helemaal niet ten goede. Index e.d. zijn niet (goed) te gebruiken. Vandaar: traagheig.

[...]


Geven we toch een ander voorbeeld... kijken hoe je dat oplost:

je hebt een nieuwstabel (met id, titel, datum, tekst)
en een agenda (met id, datum, titel, locatie, tekst)
en een memo (met id, datum, titel, tekst)
+ nog eens 20 functionaliteiten.......

en een rubriekentabel die je op de site hanteert... (met id, rubriek_naam, rubriek_omschrijving).

Nu wil je voor alle functionaliteiten gebruik gaan maken van de rubriekentabel om deze te kunnen rubriceren.

Normaliseren tot het diepste nivo? of is het in dit geval handiger om bij elke functionaliteit een veldje rubriek te maken (varchar 255 bijv.) met daarin alle foreign_id's...

Ik weet wel waar ik voor kies: normaliseren hoeft het me niet onnodig lastig maken... daar is het immers niet voor bedoeld.

toon volledige bericht

Door het NIET te doen maak je het jezelf ook onnodig lastig. Voor kleine projectjes en databases zal het niet veel uitmaken en ben je qua werk misschien eerder klaar. Maar als je later wilt opschalen naar iets veel groters wordt het veel te traag en ben je meer tijd aan het ombouwen.

Ik ben het met je eens dat ie iets kan "dood" normaliseren. Maar het niet doen en dan roepen dat het minder makkelijk is om een CVS bestand te importeren...

Ow, jou houding is net zo arrogant als die van Janoz

Edit: lekker Creep, eerst de *COMPLETE* draad lezen voordat je antwoor geeft

[ Voor 8% gewijzigd door Creepy op 29-03-2004 13:37 ]

[curry684]

Anoniem: 17852 schreef op 29 maart 2004 @ 13:28:
[...]

Kom op nou.. normaliseren hoef je toch niet tot het stomste nivo uit te voeren? Ik kreeg laatst een database met n.a.w. gegevens (perfect genormaliseerd):
aanhef in een aparte tabel met koppeltabel
titulatuur in een aparte tabel met koppeltabel
voorvoegsels in een aparte tabel met koppeltabel

Ik vind vooral de eerste 2 extreem correct dat het een aparte tabel is, ik snap alleen de koppeltabel er even niet zo snel bij. De 3e is twijfelachtig als ik goed interpreteer, maar voor puristen zeker correct.

Maar je draait van het verhaal af. Of je inderdaad titulatuur in een aparte tabel weg moet normaliseren staat hier niet ter discussie, dat zou een valide geschil zijn namelijk. Hier staat ter discussie of je 2 tabellen moet koppelen door middel van de langzaamst mogelijke string-based methode of door het koppelen van primary keys aan foreign keys middels indexed joins, wat nu juist het grapje is waar relationele database management systemen volledig voor geoptimaliseerd zijn.

Je vergelijkt nogal appels met peren dus.

[curry684]

whoami schreef op 29 maart 2004 @ 13:32:
[...]


Hmmm, ik denk dat we hier nog wel eens een apart discussie-topic kunnen over openen.
Je kan bepaalde BL evengoed in je database kwijt hoor, dat kan behoorlijk voordelig zijn voor de performance, al boet je dan wel wat aan flexibiliteit in.

Zoals ik al zei zijn triggers en SP's bedoeld om data-inherente business logic uit te voeren, wat bijvoorbeeld ook kan inhouden dat je automatisch een maandbalans opmaakt en de maand boekhoudkundig sluit zodra er een boeking in de volgende maand gedaan wordt. Dat kan en mag je zeker in de database-tier doen.

Indien je echter die maandstaat automatisch door wilt mailen moet het in de middle- of clienttier, daar mist de DB de flexibiliteit en mogelijkheden voor.

[gorgi_19]

whoami schreef op 29 maart 2004 @ 13:32:
Hmmm, ik denk dat we hier nog wel eens een apart discussie-topic kunnen over openen.
Je kan bepaalde BL evengoed in je database kwijt hoor, dat kan behoorlijk voordelig zijn voor de performance, al boet je dan wel wat aan flexibiliteit in.

In het kader van even spammen..

http://www.asp.net/Forums...?tabindex=1&PostID=514918 is ook wel een interessante discussie om dan even door te lezen.

[Anoniem: 17852]

curry684 schreef op 29 maart 2004 @ 13:35:
[...]

Maar je draait van het verhaal af. Of je inderdaad titulatuur in een aparte tabel weg moet normaliseren staat hier niet ter discussie, dat zou een valide geschil zijn namelijk. Hier staat ter discussie of je 2 tabellen moet koppelen door middel van de langzaamst mogelijke string-based methode of door het koppelen van primary keys aan foreign keys middels indexed joins, wat nu juist het grapje is waar relationele database management systemen volledig voor geoptimaliseerd zijn.

Je vergelijkt nogal appels met peren dus.

Ik ben niet van mening dat de oplossing de meest mooie is in dit specifieke geval; maar als iemand met zo´n eenvoudige vraag komt moet het toch niet zo moeilijk zijn om te zeggen:

Je querie zou je kunnen schrijven als like concat ( ....etc.....)
Dit is echter niet zo´n mooie oplossing, daar je beter gebruik kan maken van een extra tabel........ etc......

Meneer leert iets over concat, over like, over relationele databases i.p.v. dat ie van whoami ALS ENIGE REACTIE krijgt dat z´n datamodel slecht is....

[ Voor 4% gewijzigd door Anoniem: 17852 op 29-03-2004 13:54 . Reden: datamodel was slecht i.p.v. waardeloos. ]

[whoami]

Wat leer je dan over relationele databases als je geen opmerkingen krijgt over je slechte datamodel? Hoe kan je een relationele DB gebruiken als je datamodel waardeloos is?
Hij heeft met die concat enkel geleerd om voor 'de gemakkelijke oplossing' te kiezen, ipv wat meer moeite te doen, en een RDBMS te gebruiken zoals het hoort.
Met jouw 'concat-oplossing', heeft de TS helemaal niks geleerd over relationele databases.
En, als je 't mij vraagt is het belangrijker dat je het concept van RDBMS goed leert toepassen, dan dat je iets leert over 'concat' en 'like'.
Waarom zou je 'm iets fouts aanleren en aanreiken? Op die manier heeft ie 'een oplossing', en leert ie het verkeerd.
Waarom zou ik 'm een verkeerde oplossing aanreiken, die hij dan zal gebruiken? Ik ga m'n naam niet verbinden aan waardeloze oplossingen hoor.

[ Voor 10% gewijzigd door whoami op 29-03-2004 13:57 ]

[gorgi_19]

Meneer leert iets over concat, over like, over relationele databases i.p.v. dat ie van whoami ALS ENIGE REACTIE krijgt dat z´n datamodel slecht is....

Doordat de basis fout was, moest hij zich in lastigere hoeken gaan drijven. Naar verwachting komt hij nog meer problemen tegen in de toekomst.

Daar lag de kern van het probleem.

[ Voor 7% gewijzigd door gorgi_19 op 29-03-2004 13:58 ]

[Anoniem: 17852]

WHOAMI....even serieus... ik heb hieronder je VOLLEDIGE eerste reactie gekwoot, dus vertel dan maar even wat hij precies van je leert:

whoami schreef op 29 maart 2004 @ 11:54:
Klinkt als een slecht datamodel....

[ Voor 2% gewijzigd door Anoniem: 17852 op 29-03-2004 14:00 . Reden: typo ]

[gorgi_19]

Anoniem: 17852 schreef op 29 maart 2004 @ 14:00:
WHOAMI....even serieus... ik heb hieronder je VOLLEDIGE eerste reactie gekwoot, dus vertel dan maar even wat hij precies van je leert:

Je mag toch aannemen dat hij weet wat een datamodel is. En om een heel verhaal te gaan tikken over normaliseren enzo, terwijl hij driekwart al weet, is zonde van de tijd.

[whoami]

Anoniem: 17852 schreef op 29 maart 2004 @ 14:00:
WHOAMI....even serieus... ik heb hieronder je VOLLEDIGE eerste reactie gekwoot, dus vertel dan maar even wat hij precies van je leert:


[...]

Denk je dat ik iedere keer hetzelfde ga zeggen als ik zo'n topic tegenkom? Met zo'n post kan ik een reactie uitlokken van de TS.
Aan de hand van z'n reactie hierop kan ik zien of hij meer wil leren over deze materie, of hij er al wat vanaf weet, etc....

[Creepy]

Anoniem: 17852 schreef op 29 maart 2004 @ 14:00:
WHOAMI....even serieus... ik heb hieronder je VOLLEDIGE eerste reactie gekwoot, dus vertel dan maar even wat hij precies van je leert:


[...]

En van jou originele reply leert ie wat???

Anoniem: 17852 schreef op 29 maart 2004 @ 12:43:
[...]


Meer problemen om dat íe uit het hoofdje niet deze query kan bouwen?

Is dat jou conclusie zonder dat je enig idee hebt welk datamodel er achter gaat en welke functionaliteiten reeds geschreven zijn? pfffff...

In dit geval even als volgt coderen:

code:

where table2.match like (concat('%,', table1.code, ',%'))

Problem solved!

[Anoniem: 17852]

Creepy schreef op 29 maart 2004 @ 14:06:
[...]
En van jou originele reply leert ie wat???
[...]

Ik denk dat als iemand zich blind heeft zitten staren op een (erg) eenvoudige query, waarvan íe het gevoel heeft dat het moet kunnen werken, maar de oplossing gewoonweg niet ziet, dat ie wel wat leert.... en dan met alle input nog meer enthousiasme GoT bezoekt en nog meer probeert te leren......

mooi he?

[whoami]

Anoniem: 17852 schreef op 29 maart 2004 @ 14:19:
[...]


Ik denk dat als iemand zich blind heeft zitten staren op een (erg) eenvoudige query, waarvan íe het gevoel heeft dat het moet kunnen werken, maar de oplossing gewoonweg niet ziet, dat ie wel wat leert.... en dan met alle input nog meer enthousiasme GoT bezoekt en nog meer probeert te leren......

Met jouw post leert hij anders ook niet echt iets bij hoor, behalve dan dat je helemaal geen goed data-model nodig hebt.

[Janoz]

Ik denk eerder dat hij meer heeft aan de korte reply van Whoami. Deze dwingt hem namelijk om na te denken over de keuzes die hij heeft gemaakt. Dat lijkt mij een stuk leerzamer dan het overnemen van een lelijk lapmiddel..

[Anoniem: 17852]

whoami schreef op 29 maart 2004 @ 14:21:
[...]


Met jouw post leert hij anders ook niet echt iets bij hoor, behalve dan dat je helemaal geen goed data-model nodig hebt.

Welles!

[Anoniem: 17852]

Janoz schreef op 29 maart 2004 @ 14:23:
Ik denk eerder dat hij meer heeft aan de korte reply van Whoami. Deze dwingt hem namelijk om na te denken over de keuzes die hij heeft gemaakt. Dat lijkt mij een stuk leerzamer dan het overnemen van een lelijk lapmiddel..

Een meningsverschil lijkt me geen probleem op een MB

[Creepy]

Anoniem: 17852 schreef op 29 maart 2004 @ 14:24:
[...]


Welles!

Nietus

Ik moet er wel even bijzeggen dat ik het met whoami eens bent. Je leer de TS ook niks, behalve iets wat hij eigenlijk niet moet doen. Dat kan niet de bedoeling zijn lijkt me.

[curry684]

Anoniem: 17852 schreef op 29 maart 2004 @ 14:24:
[...]


Welles!

Okeeeeee...... dan maar dicht

edit:
En nog maar even open, wellicht dat we hier alsnog wat educatiefs van kunnen maken

[ Voor 26% gewijzigd door curry684 op 29-03-2004 15:02 ]

[whoami]

Anoniem: 17852 schreef op 29 maart 2004 @ 14:24:
[...]


Welles!

Oja?
Waar leg jij 'm dan uit dat hij beter een goed genormaliseerd datamodel kan gebruiken?
Ik stel zelfs vast dat je in één van je volgende posts nog bezig bent met het 'aanraden' van een niet genormaliseerd db-model, en gebruik zou maken van comma-sep. velden.

[Grijze Vos]

Anoniem: 17852 schreef op 29 maart 2004 @ 13:28:
[...]

Kom op nou.. normaliseren hoef je toch niet tot het stomste nivo uit te voeren? Ik kreeg laatst een database met n.a.w. gegevens (perfect genormaliseerd):
aanhef in een aparte tabel met koppeltabel
titulatuur in een aparte tabel met koppeltabel
voorvoegsels in een aparte tabel met koppeltabel
...
lekker als een een CSV bestandje met load data into table infile '' wilt inlezen

Je database normaliseren doe je net zolang als dat het nuttig is....

Helaas ben jij er kennelijk nog niet helemaal over uit in hoeverre dat nuttig is. Er zijn verschillende normaalvormen hoor. In het geval van die NAW gegevens, vind ik persoonlijk de data-redundancy van namen niet zo erg. Grotendeels, omdat gelijke namen geen onderliggend verband hebben. Mensen met dezelfde achternaam zijn niet per se familie van elkaar.

[Anoniem: 17852]

Grijze Vos schreef op 29 maart 2004 @ 14:38:
[...]
Helaas ben jij er kennelijk nog niet helemaal over uit in hoeverre dat nuttig is. Er zijn verschillende normaalvormen hoor. In het geval van die NAW gegevens, vind ik persoonlijk de data-redundancy van namen niet zo erg. Grotendeels, omdat gelijke namen geen onderliggend verband hebben. Mensen met dezelfde achternaam zijn niet per se familie van elkaar.

Ik was eigenlijk van mening dat het complete onzin was om namen te gaan normliseren, immers de hoeveelheid data die je bespaart is zo goed als nihil, bovendien wordt het een stuk lastiger om bijvoorbeeld alle buitenlands-talige naamgevingen te gaan onderhouden.
Er scheelt hier blijkbaar flink wat verschil van mening:

curry684 schreef op 29 maart 2004 @ 13:35:
[...]

Ik vind vooral de eerste 2 extreem correct dat het een aparte tabel is, ik snap alleen de koppeltabel er even niet zo snel bij. De 3e is twijfelachtig als ik goed interpreteer, maar voor puristen zeker correct.

Erger nog: als je in een groot bedrijf werkt, en je hebt een nieuwe aanhef nodig... mag iedereen die dan aanmaken; wijzigen ....etc? Qua rechtenstructuur v.w.b. onderhoud geeft dit wellicht flinke complicaties die in dit geval (n.a.w) beter kunt vermijden. (je moet er dan niet aan denken dat iemand een aanhef gaat wijzigen.........

[curry684]

Anoniem: 17852 schreef op 29 maart 2004 @ 14:52:
Erger nog: als je in een groot bedrijf werkt, en je hebt een nieuwe aanhef nodig... mag iedereen die dan aanmaken; wijzigen ....etc? Qua rechtenstructuur v.w.b. onderhoud geeft dit wellicht flinke complicaties die in dit geval (n.a.w) beter kunt vermijden. (je moet er dan niet aan denken dat iemand een aanhef gaat wijzigen.........

Dat onderhoud valt best mee: je mag in een historische relationele database gewoon nooit iets deleten, en dit soort dingen niet wijzigen. Punt. Alle problemen opgelost, en over 10 jaar klopt al je historische data nog steeds \o/

[plakbandrol]

wat een discussie is hier losgebarsten zeg

ten eerste ben ik niet koppig, ik had alleen al alles gebouwd op deze manier, het is alsof ik een grote puzzel heb en ik moet het laatste stukje weten, en jullie zeggen gooi die hele puzzel maar omver alleen omdat er een elegantere manier is

een aantal mensen loopt op basis van 1 detail de meest extreme oordelen te geven, zoals dat ik helemaal geen database hoef te gebruiken als ik dit op deze manier doe, terwijl het totaal niet duidelijk is hoe mijn database eruit ziet, hoe de omliggende scripts eruit zien, hoeveel records er worden gebruikt, hoeveel users het moeten gebruiken, enz enz

in sommige gevallen kies ik inderdaad voor een simpele praktische oplossing in plaats van een oplossing die puur op basis van theoretische regels de voorkeur zou hebben.

LIKE is inderdaad trager dan een een subquery op een andere tabel, maar in mijn geval gaat het om een varchar van hoogstens 30 tekens, verspreid over maximaal 2000 records. De querytijd bedraagt op dit moment nabij de 1/10 sec, en om nou de totale database structuur omver te gooien alleen om een snelheidswinst van 0,002 sec te krijgen vind ik persoonlijk wat ver gaan

owja, dit is het moment de totale query, waarschijnlijk erg inefficient, maargoed, ben benieuwd hoe dit zonder db had gemoeten (zoals iemand voorstelde)

SELECT distinct tvgids_progdb.id,
tvgids_progdb.toegevoegd,
tvgids_progdb.ref_id as ref_id,
tvgids_progdb.tijd_start,
tvgids_progdb.tijd_eind,
tvgids_progdb.genre as genre,
tvgids_progdb.omschrijving as omschrijving,
tvgids_zenders.naam_kort as zender,
tvgids_zenders.naam as zender_lang,
tvgids_progdb.naam,
tvgids_alerts.keyword as keyword,
TO_DAYS(tijd_start-interval 3 hour)-TO_DAYS(now()) as tot,
SEC_TO_TIME( UNIX_TIMESTAMP( tijd_eind ) - UNIX_TIMESTAMP( tijd_start ) ) AS Tijdsduur

FROM tvgids_progdb, tvgids_zenders,tvgids_alerts
WHERE tvgids_alerts.user_id = $id
and TO_DAYS(tvgids_progdb.tijd_start-interval 3 hour) - TO_DAYS(now()) < 2
and tvgids_progdb.zender = tvgids_zenders.id
and ((tvgids_alerts.start_enable = 0 and tvgids_alerts.eind_enable = 0)
or (tvgids_alerts.start_enable = 1 and tvgids_alerts.eind_enable = 1 and TIME_FORMAT(tvgids_progdb.tijd_start,'%T') BETWEEN tvgids_alerts.start AND tvgids_alerts.eind) or
(tvgids_alerts.start_enable = 1 and tvgids_alerts.eind_enable = 0 and TIME_FORMAT(tvgids_progdb.tijd_start,'%T') > tvgids_alerts.start) or
(tvgids_alerts.start_enable = 0 and tvgids_alerts.eind_enable = 1 and TIME_FORMAT(tvgids_progdb.tijd_start,'%T') < tvgids_alerts.eind))
and ((tvgids_alerts.zender_enable = 1 and tvgids_alerts.zender like concat('%,', tvgids_progdb.zender, ',%')) or (tvgids_alerts.zender_enable = 0))
and tvgids_progdb.status = 1
and tvgids_progdb.tijd_eind > now( )
and ((tvgids_alerts.exact = 1 and tvgids_progdb.naam = tvgids_alerts.keyword) or
(tvgids_alerts.exact = 0 and tvgids_progdb.naam rlike tvgids_alerts.keyword))

order by tvgids_progdb.tijd_start
limit 100

toon volledige bericht

en het resultaat is een mooie xml/rss tv-gids tracker voor trillian

[ Voor 50% gewijzigd door plakbandrol op 01-04-2004 00:36 ]

[bigtree]

Programmeren / modelleren is keuzes maken. Daar ontkom je niet aan en de programmeur die nog nooit op een keuze is teruggekomen, werpe de eerste steen... niemand?

Dat je als programmeur de vrijheid hebt om je datamodel en applicatie in grote mate (soms zelf volledig) zelf in te richten, neemt niet weg dat je daar niet onbeperkt misbruik van kunt maken. Het is een balans zien te vinden tussen 'eenvoudig', 'onderhoudbaar' en 'performant'. Het spijt me dit te moeten zeggen, maar de door jou gekozen oplossing is geen van drieën. Het is niet eenvoudig, omdat je niet met een 'standaard' query af kon. Daarnaast zul je relatief ingewikkelde code uit moeten voeren als één gekoppeld record verwijderd moet worden uit een set. Om over onderhoudbaar (wat als een andere programmeur je code te zien krijgt) of performant nog maar te zwijgen.

Ik zit soms ook in de situatie dat ik een op het oog beste keuze achteraf betreur. Code herschrijven is niet leuk. Maar geeft wel een voldaan gevoel als je beseft dat het er beter van is geworden.

[.oisyn]

*Eens met bigtree*. Goed programmeren is een kunst, een kunstenaar flikkert ook weleens een schilderij weg als ie er gaanderweg achter komt dat ie eigenlijk verkeerd begonnen is. Natuurlijk is dat niet leuk omdat je dan al die tijd voor niets hebt gewerkt, maar je moet maar zo denken dat het toch niet voor niets is geweest: je hebt er namelijk van geleerd, en je bent er uiteindelijk een betere programmeur van geworden

(
Dit geldt natuurlijk ietwat meer in de hobbysfeer dan in de commerciele sfeer waar je vaak aan deadlines vast zit. Een leuk feitje overigens: John Carmack, lead programmer bij id software en vader van onder andere Quake en Doom en pionier in de 3d games wereld, heeft ontzettend veel code weggegooid en herschreven. Een aardige quote uit een artikel van Michael Abrash, toen nog id employee (het gaat over Quake I):

When I arrived at id at the beginning of March, John already had an engine prototyped and a plan in mind, and I assumed that our work was a simple matter of finishing and optimizing that engine. If I had been aware of id’s history, however, I would have known better. John had done not only DOOM, but also the engines for Wolf 3D and several earlier games, and had actually done several different versions of each engine in the course of development (once doing four engines in four weeks), for a total of perhaps 20 distinct engines over a four-year period. John’s tireless pursuit of new and better designs for Quake’s engine, from every angle he could think of, would end only when we shipped.

)

[ Voor 3% gewijzigd door .oisyn op 01-04-2004 01:30 ]

[whoami]

plakbandrol schreef op 01 april 2004 @ 00:21:
een aantal mensen loopt op basis van 1 detail de meest extreme oordelen te geven, zoals dat ik helemaal geen database hoef te gebruiken als ik dit op deze manier doe, terwijl het totaal niet duidelijk is hoe mijn database eruit ziet, hoe de omliggende scripts eruit zien, hoeveel records er worden gebruikt, hoeveel users het moeten gebruiken, enz enz

Een goed datamodel kiezen is echt geen detail hoor...
Als je een app bouwt, met een achterliggende DB dan staat of valt de stabiliteit en performance door je datamodel.

in sommige gevallen kies ik inderdaad voor een simpele praktische oplossing in plaats van een oplossing die puur op basis van theoretische regels de voorkeur zou hebben.

De oplossing die geopperd werd, is echt niet enkel puur op basis van theoretische regeltjes hoor, maar het is een oplossing die in de praktijk allang zijn nut bewezen heeft.

owja, dit is het moment de totale query, waarschijnlijk erg inefficient, maargoed, ben benieuwd hoe dit zonder db had gemoeten (zoals iemand voorstelde)

Janoz stelde voor om geen DB te gebruiken, omdat jij op de manier waarop je mee bezig bent, de voordelen die een DB biedt toch niet gebruikt. Vandaar dus: waarom gebruik je een DB als je 'm toch niet gebruikt zoals het moet zijn.

Vroeg of laat zul je toch op problemen botsen hoor; is het nu bij het toevoegen van nieuwe features, bug's opsporen, onderhoud, performance....

[GarBaGe]

Klinkt alsof de topicstarter gewoon een (tab-gescheiden) txt-bestandje had moeten gebruiken, ipv een database.

[bigtree]

GarBaGe schreef op 01 april 2004 @ 13:36:
Klinkt alsof de topicstarter gewoon een (tab-gescheiden) txt-bestandje had moeten gebruiken, ipv een database.

Nee nee, in een CSV-bestand heeft de volgorde van de waarden nog betekenis.
In de situatie van de topicstarter niet.

[Annie]

curry684 schreef op 29 maart 2004 @ 13:35:
[...]

Ik vind vooral de eerste 2 extreem correct dat het een aparte tabel is, ik snap alleen de koppeltabel er even niet zo snel bij. De 3e is twijfelachtig als ik goed interpreteer, maar voor puristen zeker correct.

offtopic:
Een persoon kan meerdere titels hebben. Evenzo voor de aanhef (Beste heer, Geachte heer, Weledelgeleerde heer, ....).

[Anoniem: 17852]

bigtree schreef op 01 april 2004 @ 00:43:
Daarnaast zul je relatief ingewikkelde code uit moeten voeren als één gekoppeld record verwijderd moet worden uit een set.

zeer relatief mag ik hopen

code:

update table set ref = replace(ref, concat('%,',oudindex,',%'), '') where ref like concat('%,',oudindex,',%')

[ Voor 17% gewijzigd door Anoniem: 17852 op 04-04-2004 22:11 ]

[Janoz]

Ten eerste heb je die code waarschijnlijk niet getest want zoals hij daar staat werkt het voor geen meter. Met kleine verbeteringen zou het inderdaad kunnen werken (zolang je overal maar de conditie aanhoudt dat er ook een l4eading en trailing ',' moet zijn), maar is het zo traag als dikke stront door een trechter. Een full table scan over een volledig tekst veld (immer leading %) om hier vervolgens een dure string operatie op uit te voeren. En dan heb je nog slechts alleen de referentie weggehaald!

Verder kan ik maar weinig anders over je ignorantie zeggen dan dat het inderdaad op de zeer korte termijn wel handig is om te proberen met je vork iets te gaan snijden als het dichtstbijzijnde mes in de keuken ligt. Bij een slap aardappeltje lukt dat misschien ook nog wel, maar zodra je aan je lapje vlees begint kun je misschien wel beter naar de keuken lopen.

[.oisyn]

die vergelijking

[Night-Reveller]

[dronken modus]
Ik geniet namelijk al een tijdje met het lezen van deze discussie over een triviale zaak. Een schopje lijkt me waardevol; er kan meer geleerd worden!

Ten eerste wil ik weten hoe het met de situatie van de TS staat? De eerste indruk bij mij was als de fipo...fout datamodel, maar je eindapplicatie is zonder meer indrukwekkend (stuur ff een mailtje naar tvgids.nl ofzo)! Je zei dat je je datamodel zou omgooien, maar werkt dat al? etc.

Ten tweede wil ik keihard vertellen dat arthur_v wat ver gaat in zijn begrip over normalisatie en onderhoud (ben zelf ook een pragmatish man), maar in de praktijk best kan werken. Ik wil nu eigenlijk weten in hoeverre ik jouw mening serieus kan oordelen; Wat voor studie doe je/heb je gedaan? Wat doe je voor werk? Ik geloof namelijk best dat jou aanpak werkt.

Maar laten we het abstract en conceptueel houden; cijfers boeien niet. Volgens plakbandrol en arthur_v is het binnen meetbare resultaten haalbaar, maar volgens puristen 'zo traag als dikke poep door een trechter'. Come on! Waar hebben we het over? Ik zie dat het mogelijk is om met je applicatie roem en pecunia kan verwerven! Op de korte termijn (leuke hobby) is de simpele weg het voordeligst, maar op de lange termijn en misschien met pecunia (echt leuke hobby) moet ik je toch de meer flexibele weg aanbevelen en niet naar arthur_v luisteren!
[/dronken modus]

"Winning a discussion on the internet is like winning the paralympics: Even if you win, you're still retarded!"

dus gewoon reageren

[ Voor 11% gewijzigd door Night-Reveller op 10-04-2004 04:37 ]