MySQL IF THEN INSERT

[BoringDay]

Ik loop tegen een probleem aan bij MySQL:
$condition is een voorwaarde wanneer een INSERT uitgevoerd mag worden.
Deze levert als resultaat 1 aantal record op.
Zowel de insert query in $query als $condition werken als ze los uitgevoerd worden goed (dit is getest).

Maar op het moment ik dit combineer met een IF statement gaat het mis. Eveneens geprobeerd met INSERT WHERE EXISTS. Blijkbaar zie ik iets over het hoofd maar als ik de handleidingen en voorbeelden bekijk zou dit moeten werken. Iemand een idee waar mijn fout zit?

PHP:

$condition  = "SELECT count(*) FROM object_roles AS OBJ, application_roles AS ROL, application_users AS USR WHERE USR.id = ? AND ROL.id = USR.role_id AND OBJ.object = ? AND OBJ.write_level <= ROL.write_level";

            $query       = 'IF (('.$condition.') = 1) THEN ';
            $query      .= 'BEGIN ';
            $query      .= 'INSERT INTO application_youtube (youtube) VALUES(?) ';
            $query      .= 'END';

[Koppensneller]

PHP:

if($condition == 1)
{
   //Doe query
}

[iAdema]

Wat je nu doet is 4 losse query's uitvoeren die voor de rest niets met elkaar te maken hebben(zoals je het nu gemaakt hebt). Je moet ze in een keer uitvoeren. (binnen de if die hierboven staat)

[NMe]

Die check zou ik inderdaad gewoon in PHP doen en niet in MySQL.

iAdema schreef op maandag 08 juli 2013 @ 15:36:
Wat je nu doet is 4 losse query's uitvoeren die voor de rest niets met elkaar te maken hebben(zoals je het nu gemaakt hebt). Je moet ze in een keer uitvoeren. (binnen de if die hierboven staat)

Hij is helemaal niets uit aan het voeren, hij is alleen een string aan het bouwen?

[BoringDay]

Ik voer geen 4 losse queries uit, ik voer maar 1 uit.
$query en $condition is een samenstelling.

@koppensneller dat zou ik als een noodoplossing zien maar in eerste instantie wil ik juist die check in de query zelf behouden, ik neem aan dat daarvoor ook de IF THEN statements zijn bedoeld?

[jarrin]

Zou je de output van $query eens los post, hoeven we die niet meer in ons hoofd samen te voegen.
Daarnaast ook handig om je mysql error code te posten

[HuHu]

Moet je niet zoiets doen:

MySQL:

SET @condition=0
SELECT @condition:=COUNT(*) FROM blabla
IF (@condition = 1)

[BoringDay]

De waarde uit $condition komt is 1 (heb ik al in de debug nagegaan).
Het gaat hier om de IF THEN statement in mysql daar gaat het mis.

@Hulu, dat ga ik eens proberen

[Freedom]

Volgens mij mis je een END IF; in je anonymous block.

[BoringDay]

@Freedom ik begrijp even niet hoe je dat bedoeld.

[Freedom]

In SQL is de syntax voor een IF statement
IF condition
THEN
body
END IF

die END IF heb je niet staan (zou na de END van je BEGIN..END blok moeten)

[BoringDay]

Ok ik snap wat je bedoeld, thanks

[kluyze]

Kan dit wel in MySQL? Een IF THEN in een query? Heb je dan geen stored procedure nodig?

[Freedom]

kluyze schreef op maandag 08 juli 2013 @ 16:14:
Kan dit wel in MySQL? Een IF THEN in een query? Heb je dan geen stored procedure nodig?

Hmm, daar heb je een punt. Volgens mij kan het (weet het voor MySQL niet zeker, in Oracle kan het wel) wel als je nog een extra begin..end om het if statement heenzet, zodat het een anoniem blok wordt. Nogmaals, zo kan het in Oracle SQL, voor MySQL ben ik niet zeker.

[BoringDay]

Daar ga ik idd aan twijfelen want IF THEN lukt niet ook als ik variabel op 1 zet en dan een vergelijking maak.

Maar dan zou de optie INSERT <statement> WHERE EXISTS (<statement>) toch alsnog moeten kunnen?

[NMe]

Nogmaals: doe dit nou gewoon niet. Waarom zou je logica uit je applicatie weg gaan laten en die in je database of query's stoppen?

[BoringDay]

Je kant het ook anders zien, je haalt dan de logica uit de database weg.
Uiteindelijk ga ik het toch ombouwen na stored procedures zodat in de database de regels bepaald worden voor toegankelijkheid van gegevens.

[ Voor 3% gewijzigd door BoringDay op 08-07-2013 17:43 ]

[MueR]

In je database gaat data, in je applicatie gaat logica.

[BoringDay]

En de database logica dan? triggers, stored procedures?

[Zoijar]

Volgens mij is het sowieso niet veilig. Queries binnen een transactie/stored procedure worden sequentieel uitgevoerd. Waar dat op neer komt is een race conditie. Je checked je conditie, die is true, vervolgens past iemand anders de database aan zodat hij false is, en dan ga jij vrolijk verder.

Niks mis met bepaalde logica in je database/stored procedure overigens. Zeker als het een interactie met je database scheelt die hij zelf lokaal kan doen. (maar dan wel logica om je data consistent te houden, of als transactie een operatie uit te voeren; niet om keuzes te maken.)

[ Voor 33% gewijzigd door Zoijar op 08-07-2013 18:35 ]

[jessy100]

BoringDay schreef op maandag 08 juli 2013 @ 18:09:
En de database logica dan? triggers, stored procedures?

Dat doe je toch ook gewoon binnen de php..?

Dan ook nog het punt van classes gebruiken etc etc.

Niet te vergeten dat de query niet uitgevoerd word, er word alleen aan string opgebouwd. Een variabele $query noemen != Query uitvoeren.

[ Voor 31% gewijzigd door jessy100 op 08-07-2013 18:57 ]

[Styxxy]

Wat ik zelf altijd doe, is binnen dezelfde transactie een lock leggen op de tabel en insert doen. In MSSQL is het iets van:

SQL:

BEGIN TRAN

DECLARE @RecordExists = SELECT CASE WHEN EXISTS(SELECT 1 FROM mijntabel WITH (UPDLOCK) WHERE ...) THEN 1 ELSE 0 END

IF @RecordExists = 0 THEN
BEGIN
    INSERT INTO ...
END IF

COMMIT

(Syntax fouten onder voorbehoud. SQL is voor MSSQL, moet nog vertaald worden naar MySQL.)

MySQL documentatie hierover: http://dev.mysql.com/doc/refman/5.0/en/lock-tables.html

[ Voor 11% gewijzigd door Styxxy op 08-07-2013 19:18 ]

[BoringDay]

Styxxy schreef op maandag 08 juli 2013 @ 19:14:
Wat ik zelf altijd doe, is binnen dezelfde transactie een lock leggen op de tabel en insert doen. In MSSQL is het iets van:

SQL:

BEGIN TRAN

DECLARE @RecordExists = SELECT CASE WHEN EXISTS(SELECT 1 FROM mijntabel WITH (UPDLOCK) WHERE ...) THEN 1 ELSE 0 END

IF @RecordExists = 0 THEN
BEGIN
    INSERT INTO ...
END IF

COMMIT

(Syntax fouten onder voorbehoud. SQL is voor MSSQL, moet nog vertaald worden naar MySQL.)

MySQL documentatie hierover: http://dev.mysql.com/doc/refman/5.0/en/lock-tables.html

Dan moet je wel weer rekening houden met deadlocks? volgens mij heb je ook nog iets als asychronische transactions

[MueR]

Styxxy schreef op maandag 08 juli 2013 @ 19:14:
Wat ik zelf altijd doe, is binnen dezelfde transactie een lock leggen op de tabel en insert doen. In MSSQL is het iets van: *knip*

Doe nou niet Styx, leg het een beginner nou goed uit alsjeblieft.. Het kan, maar is niet handig. Het hele ontwerp van BoringDay slaat nergens op, hij is een stuk PHP in MySQL aan het duwen omdat hij ergens ver weg een klok heeft horen luiden. Dat stored procedures en triggers bestaan is leuk, maar dan hoef je ze nog niet voor elke scheet te gebruiken. Straks ga je er nog emails mee sturen ook, want die data heb je immers ook allemaal in je DB.

[ACM]

BoringDay schreef op maandag 08 juli 2013 @ 16:19:
Daar ga ik idd aan twijfelen want IF THEN lukt niet ook als ik variabel op 1 zet en dan een vergelijking maak.

Vziw kent MySQL geen "IF"-statement (op de plek waar SELECT, DELETE, etc mogen). Je kan het vast met een (anonieme, kent MySQL die?) function of stored procedure oplossen, maar zoals de rest al zegt... Dit kan je net zo goed - of beter - gewoon in php doen, je kan niet voor niets een transactie starten vanuit je applicatiecode. Eventueel kan je nog wel bij je SELECT de boel aanvullen met "LOCK FOR UPDATE" zodat je de genoemde race conditions kunt ontwijken, indien nodig.

Maar dan zou de optie INSERT <statement> WHERE EXISTS (<statement>) toch alsnog moeten kunnen?

Insert kent helemaal geen where... Waar haal je vandaan dat dat wel moet kunnen? Er is binnen SQL geen mogelijkheid om een INSERT conditioneel te maken en ook heeft MySQL daar niet echt aanvullende functionaliteit voor.

Wel is het mogelijk om een INSERT te vullen met een SELECT die 0 of meerdere records teruggeeft. Je zou daar in dit geval een beetje hacky gebruik van kunnen maken door zoiets te maken:

SQL:

INSERT INTO application_youtube (youtube)
SELECT ? 
FROM object_roles AS OBJ, application_roles AS ROL, application_users AS USR
 WHERE USR.id = ? AND ROL.id = USR.role_id AND OBJ.object = ? AND OBJ.write_level <= ROL.write_level

Waarbij je eerste parameter dus de waarde is die je anders zou inserten binnen de if. Maar ik raad je bij deze direct af om bovenstaande te gebruiken omdat het een vieze hack is die je beter anders op kan lossen (zie voor die andere oplossingen de php-voorbeelden in dit topic).

Mocht je nou een duplicate PRIMARY KEY willen voorkomen, dan kan je insert nog uitbreiden met 'on duplicate key update ...' (of 'insert ignore into ...' of 'replace into ...'). Maar dat lijkt ook allemaal niet van toepassing voor jouw genoemde voorbeeldqueries.

[Styxxy]

MueR schreef op maandag 08 juli 2013 @ 20:08:
[...]
Doe nou niet Styx, leg het een beginner nou goed uit alsjeblieft.. Het kan, maar is niet handig. H
[...]

Waarschijnlijk snap ik het verhaaltje niet zo goed, want het is een perfect valide oplossing voor sommige zaken (zoals ik het begreep). Ach ja...

offtopic:
Thx NMe om MueR nader te verklaren in DM, lol.

BoringDay schreef op maandag 08 juli 2013 @ 20:01:
[...]
Dan moet je wel weer rekening houden met deadlocks? volgens mij heb je ook nog iets als asychronische transactions

Naargelang de opzet, heb je daar geen problemen mee.

---

ACM legt het precies wat duidelijker uit dan ik (zijn eerste deel is dus wat ik bedoel).

[ Voor 4% gewijzigd door Styxxy op 08-07-2013 22:01 ]

[BoringDay]

@MueR
Ten eerste als je reageert doet het met fatsoen en daarbij weet je niks van mijn opzet af.
Dat jij niet het nut van stored procedures en triggers inziet prima, ik zie wel het nut ervan in.
En in de praktijk is ook helemaal geen uitzondering dat het wordt toegepast, wellicht je wat verder moet kijken dan puur php en mysql. Er zijn wel wat grotere databases die het zeer nuttig toepassen.

@ACM ik ben aardig wat INSERT WHERE (NOT EXISTS) statements tegen gekomen.
Mijn query heeft niks met duplicate keys te maken maar met een validatie van wel of niet iets toevoegen.
ignore insert is dan hier ook niet van toepassing.

[MueR]

Hou nou eens op
Met dat irritante
enteren steeds!
Hoe vaak moeten we dat verdorie nog herhalen?

BoringDay schreef op maandag 08 juli 2013 @ 22:04:
@MueR
Ten eerste als je reageert doet het met fatsoen en daarbij weet je niks van mijn opzet af.
Dat jij niet het nut van stored procedures en triggers inziet prima, ik zie wel het nut ervan in.
En in de praktijk is ook helemaal geen uitzondering dat het wordt toegepast, wellicht je wat verder moet kijken dan puur php en mysql. Er zijn wel wat grotere databases die het zeer nuttig toepassen.

Ik zie wel degelijk het nut in van stored procedures en ik weet ook dat ze genoeg goed gebruikt worden. Ik zie alleen het nut absoluut niet om dit verhaal door een database af te laten handelen, aangezien je niets anders doet dan een simpele count en een if. Knal het hele verhaal in stuk PHP code en je hebt in hetzelfde aantal regels evenveel gedaan en je kan vervolgens ook nog makkelijk debuggen. Er zijn overigens ook genoeg applicaties die het prima in de applicatie zelf toepassen, en dat werkt ook prima.

@ACM ik ben aardig wat INSERT WHERE (NOT EXISTS) statements tegen gekomen.

Oh do tell, waar mogen wij die vinden?

[NMe]

BoringDay schreef op maandag 08 juli 2013 @ 22:04:
Dat jij niet het nut van stored procedures en triggers inziet prima, ik zie wel het nut ervan in.
En in de praktijk is ook helemaal geen uitzondering dat het wordt toegepast, wellicht je wat verder moet kijken dan puur php en mysql. Er zijn wel wat grotere databases die het zeer nuttig toepassen.

Er zijn zat databases die het nuttig toepassen, maar het aantal op PHP gebaseerde websites waar het prettig werkt of überhaupt handiger is dan het naar code halen is vrij beperkt. Alleen al vanwege versioning. Natuurlijk zijn er handige plaatsen voor stored procedures maar ik heb er in mijn ruim 5 jaar professionele ervaring als webdeveloper maar één keer gebruik van gemaakt en dat was tegen mijn zin.

Het probleem met jou is dat jij steeds weer denkt dat jij het beter weet terwijl je keer op keer met onconventionele oplossingen komt voor conventionele problemen en daarbij niks van een ander wil aannemen. Javascript is slecht omdat het "geen OOP is", het is niet veilig "omdat je het in de URL kan zetten" en voor simpele checks zijn stored procedures blijkbaar veel handiger dan de checks doen in je code, waar ze 9 van de 10 keer horen. Neem nou eens een keer van een ander aan dat niet alles wat jij bedenkt een even goed plan is.

[BoringDay]

@MueR, aanstellen is ook een kunst, beetje zinloos om elke keer gaan lopen te zeuren over een enter na een zin met een punt. En google dan kom je het vanzelf tegen.

@NMe, wellicht er meerdere visies zijn van hoe je kan programmeren? Verder hoe ik iets wil opzetten OOP simulatie en database toepassing met stored procedures is dat een keuze die ik zelf maak. Het heeft niks met beter weten te maken, maar met mogelijkheden realiseren. Dat jij en andere ze misschien niet inziet prima maar er zijn wel anderen die wel de mogelijkheden en nut ervan inzien. En of je nu 1 of 5 jaar ervaring hebt vind ik totaal niet interessant.

[CurlyMo]

NMe schreef op maandag 08 juli 2013 @ 22:47:
Er zijn zat databases die het nuttig toepassen, maar het aantal op PHP gebaseerde websites waar het prettig werkt of überhaupt handiger is dan het naar code halen is vrij beperkt. Alleen al vanwege versioning. Natuurlijk zijn er handige plaatsen voor stored procedures maar ik heb er in mijn ruim 5 jaar professionele ervaring als webdeveloper maar één keer gebruik van gemaakt en dat was tegen mijn zin.

Misschien offtopic..., maar ik wil graag nieuwe dingen leren. Het ging hier over een PostgreSQL database:

Ondanks dat ik geen beroepsmatig (stage) database ontwikkelaar (meer) ben hier toch wel een vraag over*. Voor een CRM systeem was het aan mij om de database te ontwikkelen. Een van de eisen was grote mate van abstractie. Dit heb ik gedaan, maar aangezien een simpele insert complexe queries (met transactions) zouden vereisen (gebruikers met meerdere adressen, telefoonnummers, rollen enz), heb ik over die vele tabellen een view met triggers gemaakt. Op deze manier was het simpel invoeren van een nieuwe gebruiker te doen door een insert op de view te doen. Deze handelde vervolgens alle losse tabellen af. Wilde je van een bepaalde gebruiker alle adressen opvragen, dan kon dat natuurlijk a.d.v. het user id in de adressen tabel. Ook waren er triggers die controleerde op de consistentie van de gegevens zoals telefoonnummers. Dit om altijd zeker te weten dat de juiste data in de database terecht zou komen zonder te vertrouwen op de PHP ontwikkelaars.

Zouden jullie zoiets dan altijd in de code doen, want naar mijn idee is het wel handig als je als database ontwikkelaar kan afdwingen wat (per kolom) valide data is?

*en heb mezelf nooit als échte professional op dit gebied beschouwd

@BorignDay, verwar je de INSERT ... WHERE niet met de INSERT ... SELECT .. WHERE? Was ook al opgemerkt door ACM.

[Zoijar]

BoringDay, misschien een nuttige tip voor de toekomst: het is niet heel handig om zo fel, negatief en betweterig over te komen bij mensen waarvan je in de eerste plaats zelf hulp vraagt

[NMe]

BoringDay schreef op maandag 08 juli 2013 @ 23:41:
@NMe, wellicht er meerdere visies zijn van hoe je kan programmeren? Verder hoe ik iets wil opzetten OOP simulatie en database toepassing met stored procedures is dat een keuze die ik zelf maak. Het heeft niks met beter weten te maken, maar met mogelijkheden realiseren. Dat jij en andere ze misschien niet inziet prima maar er zijn wel anderen die wel de mogelijkheden en nut ervan inzien. En of je nu 1 of 5 jaar ervaring hebt vind ik totaal niet interessant.

Jij denkt het keer op keer beter te weten dan mensen waarvan ik wéét dat ze al 10 of meer jaar in het vak zitten en uitermate veel kennis hebben op het gebied waarvan jij laat zien dat je compleet niet doorhebt wat je aan het doen bent. Serieus, je hebt jezelf hier al meermaals compleet voor schut gezet en je lijkt het zelf niet eens door te hebben. Doe jezelf een plezier en leer asjeblieft eerst de basics eens goed aan voordat je rare truukjes gaat verzinnen. Daar ga je veel meer profijt van hebben dan wat je nu keer op keer bij elkaar hackt.

CurlyMo schreef op maandag 08 juli 2013 @ 23:50:
[...]

Zouden jullie zoiets dan altijd in de code doen, want naar mijn idee is het wel handig als je als database ontwikkelaar kan afdwingen wat (per kolom) valide data is?

Het klinkt als iets dat handig zou kunnen zijn maar ik zou persoonlijk toch liever alles zelf doen. Transactie starten, losse query's doen, en als er iets misgaat een rollback. Op het moment dat je zo'n view ook gebruikt om data op te halen is het nog redelijk verdedigbaar om in hetzelfde formaat ook spul op te slaan.

Maar goed, dat is hier niet aan de orde. Dat triggers, views en stored procedures handig zijn in de juiste situatie zal niemand hier ontkennen. Het probleem hier is vooral dat BoringDay logica naar de database wil trekken die daar helemaal niet thuishoort.

[MueR]

BoringDay schreef op maandag 08 juli 2013 @ 23:41:
@MueR, aanstellen is ook een kunst

Je bent er aardig goed in ja.

beetje zinloos om elke keer gaan lopen te zeuren over een enter na een zin met een punt.

Stop er dan eens mee. Text-wrapping is iets waar browsers enorm goed in zijn, dat hoef jij niet voor hem te doen, dan leest het voor ons allen prettiger. Verder: beetje dom om constant sturing van moderators te negeren.

En google dan kom je het vanzelf tegen.

Ik geef je net een link naar de manual van mysql. Wat zou ik moeten googlen? INSERT .. WHERE bestaat niet in MySQL, zoals meerdere mensen ondertussen hebben gezegd. Waar op het internet ga ik een pagina vinden waardoor het magisch ineens wel beschikbaar is? Wat heeft elke versie van de MySQL documentatie overgeslagen en heb jij ontdekt?

[ Voor 4% gewijzigd door MueR op 09-07-2013 00:04 ]

[BoringDay]

@Zoijar, dat zou ik zeker doen mits bepaalde opmerkingen buitenwegen gelaten worden.

@NMe fijn voor dat je die mensen kent, zelf ken ik ze ook wel. En je kan vinden wat je vind maar toch heb ik dingen voor elkaar gekregen.

@MueR: http://stackoverflow.com/...xists-without-primary-key antwoord 3. Zo te zien zijn er toch wel een aantal die het kunnen toepassen.

[Styxxy]

BoringDay schreef op dinsdag 09 juli 2013 @ 00:42:
@MueR: http://stackoverflow.com/...xists-without-primary-key antwoord 3. Zo te zien zijn er toch wel een aantal die het kunnen toepassen.

Het derde antwoord is echt niet gewoon "INSERT INTO ... WHERE", maar wel "INSERT INTO ... SELECT...WHERE". Een érg groot verschil, en net wat MueR en NMe ook zeggen. Anyway, ik heb geen MySQL om mijn machine (meer) staan, dus ik kan het ook niet 1-2-3 testen of dat het nu al dan niet werkt.

Ontopic: kan je eens de volledige query tonen die afgevuurd wordt op de database? Mogelijk zit daar een fout in (en kunnen we ook sneller zien wat er aan de hand is). Daarnaast, persoonlijk probeer ik queries niet te veel in elkaar te proppen; de kans op fouten is dan veel groter.

Ik zie eigenlijk enkele oplossingen:

• Toevoegen van een UNIQUE constraint op de tabel, indien dit niet te zwaar is (geen *tig velden). => De insert zal dan falen bij een duplicate. Deze kan je dan gewoon afhandelen in code.
• Eerste een query uitvoeren die kijkt of dat er records zijn (count), indien dit 0 is => insert uitvoeren. Dit gewoon in code. Nadeel is wel, dat je mogelijk concurrentie problemen hebt (bij een druk systeem, waarbij potentieel vanuit verschillende bronnen dezelfde data ingevoerd gaan worden). Voor kleinschalige systeem is dit niet echt een zorg.
• Zoals ik eerder zei: (1) start een transactie, (2) doe een select met update lock die een "select case when exists(select ...)" doet, (3) voer de insert uit indien er geen records gevonden zijn, (4) commit de transactie (of bij een fout, rollback doen). Hierbij moet je wel goed opletten dat je de transactie zo kort mogelijk houdt, zodat je andere requests / queries (naar deze tabel) niet te lang ophoudt.
• Stored procedure gebruiken of een view => dit zou echt mijn last-resort zijn en in deze situatie gewoon te vermijden (aangezien dit zéér waarschijnlijk niet in de gehele codebase past, volledig andere stijl). En dit brengt ook weer andere (onderhoudbaarheids-) problemen met zich mee.

Hopelijk is dit wat duidelijk.

offtopic:
De bitsige toon is niet bepaald productief voor het zoeken naar een oplossing.

@MueR en NMe: next time misschien beter negeren ?

@BoringDay: misschien ook eens luisteren naar de tips (schrijfstijl, met constante enters enzo) van de mods en andere gebruikers? En ook niet direct de neus afbijten van andere personen.

[ Voor 4% gewijzigd door Styxxy op 09-07-2013 02:11 ]

[Douweegbertje]

Stop gewoon met advies en hulp geven aan deze knakker.
Dit is zijn 2e topic waar hij een vraag stelt, en vervolgens bijdehand gaat lopen doen alsof hij alles snapt terwijl hij steeds met de meest achterlijke programmeer voorbeelden komt. Uiteindelijk gaat dit topic weer dicht, omdat het uit de hand loopt en iedereen heeft weer zijn energie en moeite verpest aan z'n topic.

dus @BoringDay, je vraag is al 10x beantwoord, niet zo moeilijk doen, en het anders nog eens lezen. Wellicht dat je er dan ooit eens uitkomt.

[Hydra]

MueR schreef op maandag 08 juli 2013 @ 20:08:
Doe nou niet Styx, leg het een beginner nou goed uit alsjeblieft.. Het kan, maar is niet handig. Het hele ontwerp van BoringDay slaat nergens op, hij is een stuk PHP in MySQL aan het duwen omdat hij ergens ver weg een klok heeft horen luiden. Dat stored procedures en triggers bestaan is leuk, maar dan hoef je ze nog niet voor elke scheet te gebruiken. Straks ga je er nog emails mee sturen ook, want die data heb je immers ook allemaal in je DB.

Je klinkt een beetje als de gemiddelde Oracle DBA

[MueR]

BoringDay schreef op dinsdag 09 juli 2013 @ 00:42:
@MueR: http://stackoverflow.com/...xists-without-primary-key antwoord 3. Zo te zien zijn er toch wel een aantal die het kunnen toepassen.

Knap, want ik klop net dit in (zoals uit je antwoord):

SQL:

INSERT INTO `z_resource` (`course`, `name`)
VALUES (2,'test')
WHERE NOT EXISTS (
  SELECT id from z_resource WHERE course = 2
)

En MySQL zegt dit:

#1064 - You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'WHERE NOT EXISTS (SELECT id from z_resource WHERE course = 2)' at line 1

Hydra schreef op dinsdag 09 juli 2013 @ 11:54:
Je klinkt een beetje als de gemiddelde Oracle DBA

Ik heb stored procedures gezien die werkelijk email sturen. En "die data staat toch al allemaal in de DB" was ook werkelijk de reden om het middels een SP te doen.

[ Voor 18% gewijzigd door MueR op 09-07-2013 11:58 ]

[Hydra]

Oh, zo te zien heeft 'ie wel de input in het vorige topic ter harte genomen en is 'ie server-side user-rollen aan het checken

[BoringDay]

@douweegbertje
Ten eerste stelde ik een gewone vraag, daarbij kwam ik niet aanzetten met opmerkingen die onvriendelijk waren. Laat die beledigden opmerkingen gewoon voor je en er zijn talen waar dingen juist heel erg logisch zijn die jij misschien niet kan vatten.

@hydra dat had ik toen ook al aangegeven, dat ook zou gaan gebeuren.

[Hydra]

BoringDay schreef op dinsdag 09 juli 2013 @ 14:13:
@douweegbertje
Ten eerste stelde ik een gewone vraag, daarbij kwam ik niet aanzetten met opmerkingen die onvriendelijk waren. Laat die beledigden opmerkingen gewoon voor je en er zijn talen waar dingen juist heel erg logisch zijn die jij misschien niet kan vatten.

Beetje pot-ketel he?

[BoringDay]

Volgens mij ben ik niet begonnen met beledigingen?

[MueR]

Klopt, daar is niemand mee begonnen, jij hebt er voor gekozen om je beledigd te voelen naar aanleiding van mijn opmerking dat je ontwerp nergens op slaat. Dat mag, maar kunnen we nu weer on-topic?

Wat je wil kan niet. Niet in MySQL, niet in PostgreSQL, niet in MSSQL en niet in Oracle. Doe dit nou gewoon in code.

[ Voor 5% gewijzigd door MueR op 09-07-2013 14:24 ]

[P.O. Box]

dat het allemaal niet netjes is enzo is al uitgebreid aan het licht gekomen in dit topic...
ik heb dit zelf ook wel eens nodig, ivm onze niet al te soepele applicatie...

wat je kunt doen is:

SQL:

insert into yourtable (veld1, veld2)
select 'val1', 'val2'
from
othertable
where
$condition = 1
limit 1

waarom othertable? de select table waar je vanuit selecteert boeit niet, omdat je toch maar harde waardes meegeeft... en een insert uit de tabel waaruit je ook selecteert is niet mogelijk, omdat mysql dan in een soort dead-lock komt....
limit 1 --> anders krijg je dat je record x-aantal keer wordt geinsert (x = aantal records uit othertable)...
aan te raden is om voor othertable een tabel te nemen waarvan je zeker weet dat er weinig records zijn en zullen blijven (bijv. een settings tabel)

[Verwijderd]

IEDERE developer leert door fouten te maken en te experimenteren, dat je met vreemde constructies aankomt is geen schande, ik denk dat iedeen hier wel mooie WTF code uit zijn/haar verleden kan presenteren.
Als je echter weigert te leren van je fouten en weigert te snappen waarom wat je doet verkeerd is heb je het verkeerde beroep gekozen.

[base_]

Misschien is een ORM een interessante optie? Zie bv http://propelorm.org/ of doctrine. Dan ben je meteen minder afhankelijk van de gebruite database (werkt met diverse databases: A supported database (MySQL, MS SQL Server, PostgreSQL, SQLite, Oracle)) en kan je ook complexe logica in het model verwerken.

[Hydra]

BoringDay schreef op dinsdag 09 juli 2013 @ 14:18:
Volgens mij ben ik niet begonnen met beledigingen?

Volgens mij ging het redelijk downhill nadat jij met "@MueR, aanstellen is ook een kunst" kwam nadat een mod je vertelt dat je hier op GoT niet geacht wordt na elke zin een enter te geven. Daarnaast reageer je nogal extreem defensief (ook in andere topics) als mensen je vertellen dat de manier waarop je iets probeert te doen niet de juiste is. Vergeet niet dat je vooral dankbaar moet zijn dat mensen, die dit over het algemeen voor hun werk doen en je dus gratis advies geven, uberhaupt op je reageren, ongeacht of je het er mee eens bent.

Afgezien van Oracle DBA's die zichzelf onmisbaar proberen te maken is iedereen er tegenwoordig wel over uit dat je zo weinig mogelijk logica in een RDBMs wilt stoppen. Het is niet meer dan volkomen terecht dat je daar op gewezen wordt. Als je dan eigenwijs gaat doen dan houdt het op natuurlijk, en als je zonder het zelf te testen dingen gaat roepen over WHERE-clausules dan maak je jezelf ietwat ongeloofwaardig.

Anyway, bottom line: tegenwoordig gebruikt vrijwel iedereen OR-mappers om dit soort zaken te regelen. Als je het dan toch perse handmatig wil doen, doe je er goed aan om zoveel mogelijk platform-onafhankelijk SQL te gebruiken (je zult maar over moeten stappen) en dergelijke constructies gaan daar nogal tegenin.

[incaz]

Toevoegend aan Hydra: de query die bepaalt welke rol de user heeft zou ik alleen bij inloggen uitvoeren, en het resultaat opslaan in een session. Je kunt het dan in je applicatie gebruiken om behoorlijke foutmeldingen te genereren en bv de interface aan te passen zodat acties die niet mogen uberhaupt niet beschikbaar zijn (geen veiligheid, wel gebruiksvriendelijkheid.)
Scheelt een boel queries als je de check vaak moet doen.

[Styxxy]

BoringDay schreef op dinsdag 09 juli 2013 @ 14:13:
@douweegbertje [...]
@hydra [...]

Wel grappig om te zien dat je enkel om anderen reageert, terwijl ik mogelijke oplossing aanbied en volledig genegeerd word. Leuk hoor, graag gedaan. Ik zal nog eens een keer moeite doen om de tijd te nemen om jouw topic te bekijken en een antwoord te typen...

[compufreak88]

base_ schreef op dinsdag 09 juli 2013 @ 14:30:
Misschien is een ORM een interessante optie? Zie bv http://propelorm.org/ of doctrine. Dan ben je meteen minder afhankelijk van de gebruite database (werkt met diverse databases: A supported database (MySQL, MS SQL Server, PostgreSQL, SQLite, Oracle)) en kan je ook complexe logica in het model verwerken.

Een ORM gaat niet beter werken als je niet weet wat de ORM op de achtergrond doet. Dan krijg je helemaal rare constructies soms (N+1) queries enzovoort. Een ORM kan een handig hulpmiddel zijn, maar in mijn opzicht zeker geen vervanging van zelf queries schrijven (of weten hoe je ze schrijft).

[drm]

P.O. Box:
wat je kunt doen is:

SQL:

insert into yourtable (veld1, veld2)
select 'val1', 'val2'
from
othertable
where
$condition = 1
limit 1

waarom othertable? de select table waar je vanuit selecteert boeit niet, omdat je toch maar harde waardes meegeeft... en een insert uit de tabel waaruit je ook selecteert is niet mogelijk, omdat mysql dan in een soort dead-lock komt....
limit 1 --> anders krijg je dat je record x-aantal keer wordt geinsert (x = aantal records uit othertable)...
aan te raden is om voor othertable een tabel te nemen waarvan je zeker weet dat er weinig records zijn en zullen blijven (bijv. een settings tabel)

je hebt de FROM clause niet nodig. Die is niet verplicht in een SELECT query. Dan kun je ook meteen de limit weglaten en krijg je precies de query waar TS naar op zoek is.

edit:
dan hoef je ook niet steeds te checken of er wel records in je tabel staan

[ Voor 4% gewijzigd door drm op 09-07-2013 22:17 ]

[ACM]

drm schreef op dinsdag 09 juli 2013 @ 22:15:
je hebt de FROM clause niet nodig. Die is niet verplicht in een SELECT query.

Voor zover ik weet mag een WHERE (en group by, having, e.a.) alleen als er ook een FROM is, het klopt inderdaad je ook bij een select alleen een select list mag opgeven in MySQL ("SELECT 1" is een valide query). Maar je kan het zonder FROM niet conditioneel maken...

Zoals ik ook al eerder impliceerde hoef je niet per se in de select list daadwerkelijk velden uit de tabellen uit je FROM te gebruiken. Je kan ook gewoon willekeurige scalars gebruiken en dus krijg je effectief dan voor een situatie waarbij het bestaan van records die voldoen aan die WHERE dan de gevraagde situatie in 1 query oplevert.

Maar jij stelt effectief dit voor:

SQL:

INSERT INTO tabel (veld) SELECT 1

Dat is effectief hetzelfde als dit:

SQL:

INSERT INTO tabel (veld) VALUES (1)

[pedorus]

P.O. Box schreef op dinsdag 09 juli 2013 @ 14:26:
de select table waar je vanuit selecteert boeit niet, omdat je toch maar harde waardes meegeeft... en een insert uit de tabel waaruit je ook selecteert is niet mogelijk, omdat mysql dan in een soort dead-lock komt....
limit 1 --> anders krijg je dat je record x-aantal keer wordt geinsert (x = aantal records uit othertable)...
aan te raden is om voor othertable een tabel te nemen waarvan je zeker weet dat er weinig records zijn en zullen blijven (bijv. een settings tabel)

Maar wat nu als othertable leeg is? Ik denk dat je op zoek bent naar DUAL.

[RobIII]

incaz schreef op dinsdag 09 juli 2013 @ 17:55:
Toevoegend aan Hydra: de query die bepaalt welke rol de user heeft zou ik alleen bij inloggen uitvoeren, en het resultaat opslaan in een session.

En vervolgens zet je een user in een nieuwe ("lagere") rol en mag je hopen dat z'n sessie verloopt of ranzige truukjes uithalen Ik zou 't gewoon per request doen of in een cache stoppen die je fatsoenlijk kunt invalideren

[P.O. Box]

pedorus schreef op woensdag 10 juli 2013 @ 00:08:
[...]

Maar wat nu als othertable leeg is? Ik denk dat je op zoek bent naar DUAL.

daarom zeg ik ook dat je voor othertable een soort van settingstabel ofzo moet gebruiken... een tabel waarvan je zeker weet dat hij niet leeg is, niet 1000000000 records bevat, en ook "nooit" zal verdwijnen uit je applicatie...

[incaz]

RobIII schreef op woensdag 10 juli 2013 @ 00:28:
[...]

En vervolgens zet je een user in een nieuwe ("lagere") rol en mag je hopen dat z'n sessie verloopt of ranzige truukjes uithalen Ik zou 't gewoon per request doen of in een cache stoppen die je fatsoenlijk kunt invalideren

Dat ligt er inderdaad een beetje aan hoe het is opgebouwd, maar ik zou liever een periodieke functie aan de sessions toevoegen (of uiteraard een andere cache, dat kan ook) zodat je zeker weet dat alle info in de session klopt. Maar alleen bij login is misschien wat te weinig ja

[drm]

ACM:
Voor zover ik weet mag een WHERE (en group by, having, e.a.) alleen als er ook een FROM is, het klopt inderdaad je ook bij een select alleen een select list mag opgeven in MySQL ("SELECT 1" is een valide query). Maar je kan het zonder FROM niet conditioneel maken...

Oh ja, natuurlijk

Zoals ik ook al eerder impliceerde hoef je niet per se in de select list daadwerkelijk velden uit de tabellen uit je FROM te gebruiken. Je kan ook gewoon willekeurige scalars gebruiken en dus krijg je effectief dan voor een situatie waarbij het bestaan van records die voldoen aan die WHERE dan de gevraagde situatie in 1 query oplevert.

Ja, da's dan hetzelfde als wat P.O. Box voortstelt, toch?

Maar jij stelt effectief dit voor:

SQL:

INSERT INTO tabel (veld) SELECT 1

Dat is effectief hetzelfde als dit:

SQL:

INSERT INTO tabel (veld) VALUES (1)

Nee, ik stelde effectief iets voor wat niet kan Je zou er nog wel een virtuele tabel van kunnen maken, in een poging de SELECT uit een tabel te elimineren.

SQL:

INSERT INTO t(v) SELECT * FROM (SELECT 'value') t2 WHERE 1;