DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
Zoiets begrijp ik?
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | productentabel | id | productnaam | | 1 | Apparaat 1 | | 2 | Apparaat 2 | | 3 | Apparaat 3 | | 4 | Accessoire 1 | | 5 | Accessoire 2 | Dus als accessoire 1 bij product 2 en 3 hoort en accessoire 2 bij product 1 en 2 dan zal het als volgt moeten in een relatietabel? productenrelatiestabel | id | accessoire_id | gerelateerd_product_id | | 1 | 4 | 2 | | 2 | 4 | 3 | | 3 | 5 | 1 | | 4 | 5 | 2 | |
Je moeder is een hamster
maar dan zonder id in de tweede tabel
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
en je maakt van accessoire_id en product_id (niet gerelateerd_product_id) een composite key. Hiermee dwing je uniqueness af.
Heel veel groetjes, Catch22
En zoals mijn opa zei: "Al is het meisje nog zo mooi, haar poep stinkt ook". Rust Zacht opa..
Met GHB nooit meer nee
Storneren een optie?
En zoals mijn opa zei: "Al is het meisje nog zo mooi, haar poep stinkt ook". Rust Zacht opa..
Met GHB nooit meer nee
Storneren een optie?
quote:Op donderdag 5 april 2012 13:06 schreef GlowMouse het volgende:
maar dan zonder id in de tweede tabel
Dus 'id' is niet verplicht in een tabel? Nou mooi, kan die weg.quote:Op donderdag 5 april 2012 13:09 schreef Catch22- het volgende:
en je maakt van accessoire_id en product_id (niet gerelateerd_product_id) een composite key. Hiermee dwing je uniqueness af.
En wat Catch22- zegt, bedoel je daarmee dat ik een kolom moet toevoegen waarin ik aangeef bij welk product(id) deze niet hoort?
Wat is daar het praktisch nut van?
Je moeder is een hamster
hij bedoelt dat het woordje "gerelateerd" een beetje onzinnige toevoeging is aan de kolom-naam. Beter weglaten.
En als tweede bedoelt hij, dat je een key ook over meerdere kolommen kan defineren. Daarom is de kolom ID overbodig. Aangezien de combinatie [accessoire_id + product_id] sowieso al uniek is.
En als tweede bedoelt hij, dat je een key ook over meerdere kolommen kan defineren. Daarom is de kolom ID overbodig. Aangezien de combinatie [accessoire_id + product_id] sowieso al uniek is.
Met een koppeltabel geef je aan welke 2 entiteiten bijelkaar horen. Deze combinatie is uniek. Dit stel je in door een composite key te gebruiken. Hierdoor heeft die rij niet nog een eigen id nodig, want zijn unique identifier is de composite keyquote:
[..]
[..]
Dus 'id' is niet verplicht in een tabel? Nou mooi, kan die weg.
En wat Catch22- zegt, bedoel je daarmee dat ik een kolom moet toevoegen waarin ik aangeef bij welk product(id) deze niet hoort?
Wat is daar het praktisch nut van?
en in een koppeltabel zijn beide id's "gerelateerd_", dus dat moet je gewoon weglaten.
Heel veel groetjes, Catch22
En zoals mijn opa zei: "Al is het meisje nog zo mooi, haar poep stinkt ook". Rust Zacht opa..
Met GHB nooit meer nee
Storneren een optie?
En zoals mijn opa zei: "Al is het meisje nog zo mooi, haar poep stinkt ook". Rust Zacht opa..
Met GHB nooit meer nee
Storneren een optie?
Oh, lol. Die kolomnamen zijn hier puur ter illustratie.quote:Op donderdag 5 april 2012 13:55 schreef KomtTijd... het volgende:
hij bedoelt dat het woordje "gerelateerd" een beetje onzinnige toevoeging is aan de kolom-naam. Beter weglaten.
En als tweede bedoelt hij, dat je een key ook over meerdere kolommen kan defineren. Daarom is de kolom ID overbodig. Aangezien de combinatie [accessoire_id + product_id] sowieso al uniek is.
Je moeder is een hamster
Je hebt 2 hoofdtabellen:quote:
Maar hoe werkt zo'n composite key?
Kan iemand mij een voorbeeld geven?
Users met info en id
Rights met naam van rechten etc en id
UserRights met user_id en rights_id
Je kunt dus voor 1 user meerdere rechten toekennen en andersom.
Zoiets dus:
| 1 2 3 4 5 6 7 8 9 10 11 12 13 14 | SELECT Users.*, Rights.name FROM Users INNER JOIN UserRights ON UserRights.user_id = Users.id INNER JOIN Rights ON Rights.id = UserRights.right_id WHERE Users.id = 1 |
quote:
Maar hoe werkt zo'n composite key?
Kan iemand mij een voorbeeld geven?
| 1 2 3 4 5 6 | CREATE TABLE `user_rights` ( `user_id` INT NOT NULL , `right_id` INT NOT NULL , PRIMARY KEY(`user_id`, `right_id`) , INDEX (`right_id`) ); |
Tof!
Ik heb weer eens een query vraagje.
Ik heb een nested set model en nu wil ik van een bepaald groepjes nodes de parent naam achterhalen
Dit werkt bijna Het gaat mis bij nodes die 2 niveaus diep zitten.
aan deze query moet een where worden toegevoegd:
is dit uberhaupt mogelijk?
Ik heb een nested set model en nu wil ik van een bepaald groepjes nodes de parent naam achterhalen
| 1 2 3 4 5 6 | SELECT parent.name AS parentName, products.* FROM nested_menu AS node, nested_menu AS parent, produkten AS products WHERE node.lft BETWEEN parent.lft AND parent.rgt AND node.menu_id = products.product_menu AND products.highlight=1 GROUP BY product_id ORDER BY parentName, first_price ASC |
Dit werkt bijna Het gaat mis bij nodes die 2 niveaus diep zitten.
aan deze query moet een where worden toegevoegd:
| 1 | AND node.lft > parent.lft IF product_id <van deze rij> != product_id <vorige rij> |
is dit uberhaupt mogelijk?
Je kunt hier even kijken (al lijkt je query er al een beetje op)quote:Op donderdag 5 april 2012 23:07 schreef Swetsenegger het volgende:
Ik heb weer eens een query vraagje.
Ik heb een nested set model en nu wil ik van een bepaald groepjes nodes de parent naam achterhalen
[ code verwijderd ]
Dit werkt bijna Het gaat mis bij nodes die 2 niveaus diep zitten.
aan deze query moet een where worden toegevoegd:
[ code verwijderd ]
is dit uberhaupt mogelijk?
http://stackoverflow.com/(...)e-children-of-a-node
Eerlijk gezegd zet ik nooit alles in 1 grote query vaak maakt dit dingen alleen maar langzamer dan bijvoorbeeld een paar losse
(niet altijd hoor).
Is het niet makkelijker om te stellen dat node.id != parent.id ? Volgens mij ben je er al als je dat toeveoegt aan je query.quote:
Ik heb weer eens een query vraagje.
Ik heb een nested set model en nu wil ik van een bepaald groepjes nodes de parent naam achterhalen
[ code verwijderd ]
Dit werkt bijna Het gaat mis bij nodes die 2 niveaus diep zitten.
aan deze query moet een where worden toegevoegd:
[ code verwijderd ]
is dit uberhaupt mogelijk?
Als je de indexen goed hebt, kun je behoorlijk grote query's nog snel uitvoeren. Meerdere query's maken kan ook, maar dat vereist weer extra logica in PHP en die kost ook tijd.quote:
[..]
Je kunt hier even kijken (al lijkt je query er al een beetje op)
http://stackoverflow.com/(...)e-children-of-a-node
Eerlijk gezegd zet ik nooit alles in 1 grote query vaak maakt dit dingen alleen maar langzamer dan bijvoorbeeld een paar losse
Nee, zelfde probleem... als je maar 1 niveau diep bent klopt dat namelijk wel.quote:
[..]
Is het niet makkelijker om te stellen dat node.id != parent.id ? Volgens mij ben je er al als je dat toeveoegt aan je query.
Hmm... 't klinkt wel als een leuk probleemquote:
[..]
Nee, zelfde probleem... als je maar 1 niveau diep bent klopt dat namelijk wel.
quote:
[..]
Hmm... 't klinkt wel als een leuk probleem
Ik heb het maar opgelost door het hoogste niveau een tag te geven en op die tag te filteren.Niet mooi zeker niet binnen de elegante nested set oplossing, wel effectief.
Da's ook een optie natuurlijk. Maar ik wil wel proberen een nettere oplossing te vinden. Moet ik alleen eerst die tabelstructuur voor mezelf helder krijgen.quote:Op vrijdag 6 april 2012 22:05 schreef Swetsenegger het volgende:
[..]
Niet mooi zeker niet binnen de elegante nested set oplossing, wel effectief.
http://crisp.tweakblogs.n(...)-only-one-query.htmlquote:
[..]
Niet mooi zeker niet binnen de elegante nested set oplossing, wel effectief.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Ow maar mijn menu tree opbouwen doe ik ook met 1 query.quote:
[..]
http://crisp.tweakblogs.n(...)-only-one-query.html
| 1 2 3 4 5 6 | SELECT parent.".$menuName." AS parentname, node.menu_id, node.".$menuName." AS name, node.lft, node.rgt, ( COUNT( parent.".$menuName." ) -1) AS depth FROM nested_menu AS node, nested_menu AS parent WHERE node.lft BETWEEN parent.lft AND parent.rgt GROUP BY node.menu_id ORDER BY node.lft |
Jouw query is lelijker omdat hij niet via indices gesorteerd kan worden.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Ow vast, maar ik heb nu een menu tree waar je zonder problemen items tussen kan voegen, kan deleten, op kan schuiven, etc.quote:
Jouw query is lelijker omdat hij niet via indices gesorteerd kan worden.
Ideaal om klanten via een cmsje zelf een menu te laten bouwen. En ja... daar komen misschien 40 records in. Deze query draait in 15.2ms voor het volledige menu.
Ik wil een path veranderen (voor een applicatie die foto's weg schrijft naar een bepaalde dir) en gebruik het volgende command:
Het werkt echter niet, wat doe ik verkeerd?
| 1 | UPDATE image SET path = UPDATE(path, d:/dir/dir2,g:/dir/dir2); |
Het werkt echter niet, wat doe ik verkeerd?
Op donderdag 15 januari 2015 19:01 schreef Maanvis het volgende:
smegmanus is de as van het kwaad. een verbrand stukje Hitler.
smegmanus is de as van het kwaad. een verbrand stukje Hitler.
quote:
Ik wil een path veranderen (voor een applicatie die foto's weg schrijft naar een bepaalde dir) en gebruik het volgende command:
[ code verwijderd ]
Het werkt echter niet, wat doe ik verkeerd?
| 1 2 3 | UPDATE table_name SET column1=value, column2=value2,... WHERE some_column=some_value |
Dus moet het worden
| 1 2 3 | UPDATE image SET path = "d:/dir/dir2" WHERE id=xx |
Bv. of gebruik je mysql procedures / functions?
It was an opportunity to honour our memories and to make room for new ones
