Ik vroeg me af of het mogelijk was om een select query te draaien waarbij alleen columns getoond worden die aan bepaalde criteria voldoen, in mijn geval beginnen met c$

De volgende query werkt goed;
show columns from table1 where (substr(field,1,2)='c$')

Nu wil ik de resultaten verwerken in een query en de daadwerkelijke data alleen uit die columns halen. Ik wil dus eigenlijk naar de volgende query toe;

select show columns from table1 where (substr(field,1,2)='c$') from table1

Is zoiets mogelijk in mysql?
Ik had een hele reactie gepost daarstraks, maar toen was ik alles kwijt omdat ik ineens niet meer ingelogd was.

Maar reactie(s) van Jens zijn niet al te vriendelijk ben ik het met je eens.

Het is niet de mooiste oplossing dat ben ik met de rest eens, maar ik zelf zat ook weleens in dezelfde situatie waar een oplossing als deze mij een uitkomst had geboden.

Daarnaast is een site die slecht beveiligd is tegen MySQL injection etc net zo onveilig als jij schetst Jens. Dus je moet met dit 'systeem' net zo voorzichtig zijn als anders en dan kan er weinig gebeuren naar mijn idee.

Betreft de stored procedure;
Ja dit is MySQL. In MySQL 5.1 kun je ook stored routines maken en uitvoeren. Je hebt functies en procedures, en een procedure is hetgene wat jij zoekt in dit geval. Ik zelf heb het geleerd tijdens het voorbereiden van mijn MySQL examen uit het MySQL Study Guide boek, maar er is denk ook wel genoeg op internet te vinden. Google eens op 'Stored Routines MySQL'.

Ben benieuwd of je eruit komt!
Vrije velden wel, maar niet een kolom dat gaat meestal zoiets:


users
-----------------
id
...
...
...

custom_fields
-----------------
user_id
fieldname
value
Bastiaan schreef op 16.03.2009 16:49
heb ik nu al niet eerder gezegd dat dit iets is wat ik niet in de hand heb? En iets minder denigrerend mag wel met je "dream on..."


Ik zeg het alleen maar voor je eigen goed... Je database model is waarschijnlijk niet in orde als je het zo gaat doen... Maar ja, jouw database, niet de mijne...

kees schreef op 16.03.2009 17:00
Maar reactie(s) van Jens zijn niet al te vriendelijk ben ik het met je eens.


Geef eens een voorbeeldje, buiten die hierboven dan?

kees schreef op 16.03.2009 17:00
Daarnaast is een site die slecht beveiligd is tegen MySQL injection etc net zo onveilig als jij schetst Jens. Dus je moet met dit 'systeem' net zo voorzichtig zijn als anders en dan kan er weinig gebeuren naar mijn idee.


Als je je website slecht beveiligt tegen SQLInjection is dat wederom niet het probleem van het datamodel, maar van je scripting kunsten... Een datamodel waar je gebruikers kolommen van tabellen laat aanmaken en wijzigen is bijna nooit een goed datamodel...

Mvg,
Jens
kees schreef op 16.03.2009 17:00
Ja dit is MySQL. In MySQL 5.1 kun je ook stored routines maken en uitvoeren. Je hebt functies en procedures, en een procedure is hetgene wat jij zoekt in dit geval. Ik zelf heb het geleerd tijdens het voorbereiden van mijn MySQL examen uit het MySQL Study Guide boek, maar er is denk ook wel genoeg op internet te vinden. Google eens op 'Stored Routines MySQL'.

Toch iets beter opletten tijdens de les, stored procedures staan sinds versie 5.0 in MySQL. En wanneer je toch beter aan het opletten bent, dynamische datamodellen zijn hét recept voor dramatische performance, er kunnen geen indexen worden gebruikt.

Ik heb MySQL toch al niet zo hoog zitten, maar wat je hier voorschotelt, lijkt ook nog eens aan te tonen dat veel te dure examens ook weggegooid geld zijn.

Ga normaliseren en gooi jouw "dynamische" kolommen in een tabelletje met value-content, dan is er nog iets van te maken. Kun je ook een index gebruiken, dat scheelt weer een slok op een borrel.


CREATE TABLE
  tabelnaam(
    id INT auto_increment primary key,
    kolomnaam VARCHAR(255) NOT NULL,
    waarde TEXT
);
CREATE INDEX i_kolom ON tabelnaam (kolomnaam);

Dit is al een beroerde "oplossing", maar fysiek dynamische kolommen... Performance wordt om te janken.

Maar goed, MySQL is toch al om te janken. (sorry, moest even)
Goeiendag wat een forum dit. Sorry jongens maar vriendelijker kan wel lijkt me.

Ten eerste, ik raad nergens Bastiaan aan om dit te gaan gebruiken, maar aangezien hij toch al heeft besloten om het te gaan doen. Daarom help ik hem graag met een oplossing.

En Frank als jou MySQL niet lekker ligt, prima maar moet dit in al je posts blijken? Lijkt me een beetje overbodig. Als je zo graag haat uitzaait, zou ik zeggen word lid van Ajax en ga Feynoord aanhangers uitschelden ofzo, we hebben het over verschillende database platform die ieder zijn eigenschappen hebben.

En ik ben ook niet perfect net zoals iedereen dus mijn excuus dat ik niet (meer) wist in welke versie dit gekomen was.

Ik zou allemaal eens teurg naar de les normen en waarden gaan, waar je leert anderen mensen te respecteren. En realiseer jezelf wat je toegevoegde waarde is aan dit forum en wat de bedoeling is. (O.a. het helpen van mensen?). Tuurlijk doe je dat wel door iemand te adviseren iets niet te gaan gebruiken, maar aan bijdehand doen hebben we niets aan.

Misschien reageer ik wat overdreven, maar bekijk het eens vanuit de user die dit topic opent.
Kees, je helpt hier iemand willens en wetens met een fout datamodel van de wal in de sloot. Dat zou jij moeten weten, jij hebt tenslotte een MySQL-examen gedaan. Dan zou je ook moeten weten dat het achteraf een gruwelijke klus is om een fout datamodel met bijbehorende applicatie om te bouwen naar een goed datamodel. Wanneer het datamodel dynamisch moet zijn, heb je al een probleem, maar zorg er dan wel voor dat het een overzichtelijk en te hanteren probleem blijft.

Ook op het gebied van veiligheid heb je probleem met het door jou voorgestelde model, iedereen heeft rechten nodig op ALTER TABLE. En als er iets onveilig is, dan is dat het wel. Voor je het weet ben je data kwijt, heeft MySQL toch al een handje van, of laat iemand de boel met opzet onderuit gaan door teveel kolommen toe te voegen. Dit wordt echt een hackersfeestje, maak je daar geen zorgen over.

Ik ben geen liefhebber van MySQL omdat deze database onbetrouwbaar is. Zelfs een goed geconfigureerde database kan door iedere database user weer naar de bliksem worden geholpen, ze kunnen allemaal runtime de instelingen aanpassen. Heb jij net je best gedaan om er voor te zorgen dat datums ook echte datums zijn, maakt een gek jouw instellingen weer ongedaan. Zit jij weer opgescheept met de bekende 0000-00-00 datums.... En dat is nog maar een voorbeeldje, laat ik het daar ook maar even bij houden.

Wanneer jij foute oplossingen ook hulp vindt, prima, maar ik denk daar heel anders over. Ik probeer zoveel mogelijk fouten te voorkomen, dat werkt een stuk sneller en veiliger.

Ontopic: Zorg voor een goed datamodel, een zo goed mogelijk datamodel. Gebruikers hebben nooit rechten nodig om kolommen toe te voegen, te veranderen of te verwijderen, die richting kun je dus niet opgaan.

Reageren