abonnement Unibet Coolblue Bitvavo
  vrijdag 22 november 2013 @ 10:52:38 #211
37634 wobbel
Da WoBBeL King
pi_133508780
quote:
0s.gif Op woensdag 20 november 2013 18:26 schreef slacker_nl het volgende:

[..]

Dat moet je gewoon weigeren, dat voldoet niet aan de IPv4 syntax.

'127.000.000.001' is not a valid ipv4 address.# Tests were run but no plan was declared and done_testing() was not seen.

Dit is de Perl-code om IPv4/IPv6 syntax te valideren:
[ code verwijderd ]

Ach, het is slechts 1 keer ;)
pi_133716168
Iemand hier die gebruik maakt van Laravel?

Ik wil een child toevoegen aan de parent model en deze opslaan, alleen pakt hij de parentId niet omdat die waarde na het opslaan van de parent verspringt naar 1.

Code:

http://paste.laravel.com/1aMv
pi_133719321
Ik heb een tabel met producten, voorbeeld:
- producten
|- id
|- category
|- subcategory
|- product_naam

Ik wil de product_naam vinden van product id 25. Ik weet al wat de category en subcategory is van product 25.

Wat is sneller/efficienter:
SELECT id, product_naam FROM producten WHERE id = '25'
SELECT id, category, subcategory, product_naam FROM producten WHERE id = '25' AND category = 'boeken' AND subcategory = 'engels'
pi_133719769
Aangezien WHERE id = 25 al 100% selectief is zal de rest alleen maar ballast zijn en waarschijnlijk genegeerd worden of anders de query vertragen.

run beide queries 10000 keer ofzo en je weet het.
pi_133720440
quote:
14s.gif Op donderdag 28 november 2013 20:06 schreef KomtTijd... het volgende:
Aangezien WHERE id = 25 al 100% selectief is zal de rest alleen maar ballast zijn en waarschijnlijk genegeerd worden of anders de query vertragen.

run beide queries 10000 keer ofzo en je weet het.
Dit, en je kan altijd even "EXPLAIN" uitvoeren om te kijken wat er allemaal gebeurt.
pi_133720944
quote:
14s.gif Op donderdag 28 november 2013 20:06 schreef KomtTijd... het volgende:
Aangezien WHERE id = 25 al 100% selectief is zal de rest alleen maar ballast zijn en waarschijnlijk genegeerd worden of anders de query vertragen.

run beide queries 10000 keer ofzo en je weet het.
Database is nog niet gevuld (lees: leeg), script is nog niet af. Maar wat je zegt kan wel inderdaad met demo data. Anyways, thanks!

LIMIT 1 lijkt mij ook handig, niet? id is namelijk uniek.
  donderdag 28 november 2013 @ 20:31:48 #217
118585 Crutch
Filantroop || Taalzwengel
pi_133720947
quote:
19s.gif Op donderdag 28 november 2013 18:25 schreef TwenteFC het volgende:
Iemand hier die gebruik maakt van Laravel?

Ik wil een child toevoegen aan de parent model en deze opslaan, alleen pakt hij de parentId niet omdat die waarde na het opslaan van de parent verspringt naar 1.

Code:

http://paste.laravel.com/1aMv
Heb je in de database gekeken of je model überhaupt wordt opgeslagen?
En relationships sla je op met ->push()
Je moeder is een hamster
pi_133721210
quote:
0s.gif Op donderdag 28 november 2013 20:31 schreef xaban06 het volgende:

[..]

Database is nog niet gevuld (lees: leeg), script is nog niet af. Maar wat je zegt kan wel inderdaad met demo data. Anyways, thanks!

LIMIT 1 lijkt mij ook handig, niet? id is namelijk uniek.
Het lijkt je handig met als reden dat het niets toevoegt :?
pi_133721288
quote:
0s.gif Op donderdag 28 november 2013 20:31 schreef Crutch het volgende:

[..]

Heb je in de database gekeken of je model überhaupt wordt opgeslagen?
En relationships sla je op met ->push()

->push is voor bestaande objecten, heb het ondertussen al opgelost door heel lelijk een AI veld toe te voegen en daar op te koppelen.

Eloquent vind het niet leuk als je geen AI id veld hebt.

Het model werd wel correct opgeslagen.
pi_133721345
quote:
0s.gif Op donderdag 28 november 2013 20:31 schreef xaban06 het volgende:

[..]

Database is nog niet gevuld (lees: leeg), script is nog niet af. Maar wat je zegt kan wel inderdaad met demo data. Anyways, thanks!

LIMIT 1 lijkt mij ook handig, niet? id is namelijk uniek.
Je kan ook even een grote batch insert doen om er mee te testen natuurlijk.
pi_133721366
Uhm, hey guys wat vinden jullie het beste framework voor PHP?
Ik heb nou al tering veel artikelen gelezen, maar ben nog niet echt wijzer...
pi_133721530
quote:
0s.gif Op donderdag 28 november 2013 20:41 schreef RetRy32 het volgende:
Uhm, hey guys wat vinden jullie het beste framework voor PHP?
Ik heb nou al tering veel artikelen gelezen, maar ben nog niet echt wijzer...
"het beste", mijn inziens is het vrij persoonlijk wat voor jou het beste is.

Ligt er maar net aan wat je wil bereiken, persoonlijk ben ik wel een fan van Laravel het programmeert lekker snel weg en er is een redelijk grote supportbase aanwezig.
pi_133721831
quote:
14s.gif Op donderdag 28 november 2013 20:38 schreef KomtTijd... het volgende:

[..]

Het lijkt je handig met als reden dat het niets toevoegt :?
Ik dacht dat het wel meerwaarde had, dat het namelijk stopt met verder zoeken wanneer er een match gevonden is. Zonder LIMIT doorzoekt hij alle records dacht ik.
pi_133721938
quote:
0s.gif Op donderdag 28 november 2013 20:50 schreef xaban06 het volgende:

[..]

Ik dacht dat het wel meerwaarde had, dat het namelijk stopt met verder zoeken wanneer er een match gevonden is. Zonder LIMIT doorzoekt hij alle records dacht ik.
Niet als je id Unique is, waar ik wel even vanuit ging natuurlijk.
pi_133722010
quote:
14s.gif Op donderdag 28 november 2013 20:53 schreef KomtTijd... het volgende:

[..]

Niet als je id Unique is, waar ik wel even vanuit ging natuurlijk.
Is het niet :)
pi_133722073
quote:
0s.gif Op donderdag 28 november 2013 20:54 schreef xaban06 het volgende:

[..]

Is het niet :)
Maar hoe weet je dan dat de eerste het juiste resultaat is? Als het onderscheid gemaakt wordt op category,subcategory dan zou je sowieso de 2e query moeten gebruiken even terug te komen op je eerste vraag.

Behalve dat je ze dan weg kan laten in de select, omdat je die waardes al hebt.
pi_133722316
quote:
19s.gif Op donderdag 28 november 2013 20:56 schreef TwenteFC het volgende:

[..]

Maar hoe weet je dan dat de eerste het juiste resultaat is? Als het onderscheid gemaakt wordt op category,subcategory dan zou je sowieso de 2e query moeten gebruiken even terug te komen op je eerste vraag.

Behalve dat je ze dan weg kan laten in de select, omdat je die waardes al hebt.
Ik bedoel, id is altijd uniek, geen duplicates, maar ik heb het niet als unique gedefineerd omdat ik nog niet weet wat unique, primary key, index etc allemaal doen.
pi_133722367
quote:
0s.gif Op donderdag 28 november 2013 21:00 schreef xaban06 het volgende:

[..]

Ik bedoel, id is altijd uniek, geen duplicates, maar ik heb het niet als unique gedefineerd omdat ik nog niet weet wat unique, primary key, index etc allemaal doen.
Wordt jouw id automatisch opgehoogd wanneer je een nieuwe toevoegt? zoja; dan is het al je PK, en uniek.
pi_133722384
quote:
19s.gif Op donderdag 28 november 2013 21:01 schreef TwenteFC het volgende:

[..]

Wordt jouw id automatisch opgehoogd wanneer je een nieuwe toevoegt? zoja; dan is het al je PK, en uniek.
Is een auto_increment veld. Wat is PK?
pi_133722482
De primary key is altijd unique.
pi_133722515
quote:
0s.gif Op donderdag 28 november 2013 21:02 schreef xaban06 het volgende:

[..]

Is een auto_increment veld. Wat is PK?
Primary key, en een auto_increment veld is per definitie uniek en onderdeel v/d PK.

edit: Je kan het ook heel makkelijk testen, om eens kijken wat er dan gebeurt; Voeg maar eens een product toe met een ID dat al bestaat.
pi_133723506
Nog een vraag, ik sla prijzen op als:
199,99

In MySQL doe ik in een SELECT, price+shipmentCost as totalPrice. Dit werkt niet. Het werkt wel wanneer ik de prijzen opsla als:
199.99

Dus een punt in plaats van een komma. Is hier omheen te werken op een nette manier?
pi_133724946
Al zou het kunnen, dat is toch iets wat je absoluut nooit aan wilt beginnen?

Sowieso, sla gewoon de prijs in centen op als int.
pi_133724958
quote:
0s.gif Op donderdag 28 november 2013 21:25 schreef xaban06 het volgende:
Nog een vraag, ik sla prijzen op als:
199,99

In MySQL doe ik in een SELECT, price+shipmentCost as totalPrice. Dit werkt niet. Het werkt wel wanneer ik de prijzen opsla als:
199.99

Dus een punt in plaats van een komma. Is hier omheen te werken op een nette manier?
Waarom niet gewoon de Price en shipmentCost ( Let even op met dit soort CamelCasing overigens !! ) uit DB trekken en PHP het op laten tellen? dan kun je er ook nog variabele kortingen en dergelijke in mee rekenen als je dit nodig hebt?

quote:
14s.gif Op donderdag 28 november 2013 21:50 schreef KomtTijd... het volgende:
Al zou het kunnen, dat is toch iets wat je absoluut nooit aan wilt beginnen?

Sowieso, sla gewoon de prijs in centen op als int.
Dit inderdaad, dat vind je backend ook stuk toffer! :-)
comma getallen ( Floats etc ) gaan gewoon net effe minder lekker door je database heen
  donderdag 28 november 2013 @ 21:51:23 #235
118585 Crutch
Filantroop || Taalzwengel
pi_133724998
quote:
0s.gif Op donderdag 28 november 2013 21:25 schreef xaban06 het volgende:
Nog een vraag, ik sla prijzen op als:
199,99

In MySQL doe ik in een SELECT, price+shipmentCost as totalPrice. Dit werkt niet. Het werkt wel wanneer ik de prijzen opsla als:
199.99

Dus een punt in plaats van een komma. Is hier omheen te werken op een nette manier?
Ja, je waarde altijd opslaan als float of decimal en pas converteren naar #,## wanner je het output naar je template.

Of centen inderdaad.
Je moeder is een hamster
pi_133725327
quote:
0s.gif Op donderdag 28 november 2013 21:25 schreef xaban06 het volgende:
Nog een vraag, ik sla prijzen op als:
199,99

In MySQL doe ik in een SELECT, price+shipmentCost as totalPrice. Dit werkt niet. Het werkt wel wanneer ik de prijzen opsla als:
199.99

Dus een punt in plaats van een komma. Is hier omheen te werken op een nette manier?
1
2
3
4
5
$price = 1999.99;
$price = number_format($price, 2, ',', '.');
print $price . "\n";

# geeft 1.999,99

Zo kan je het in je weergave aanpassen, ik zou het gewoon goed als float/double opslaan in je DB. En als centen opslaan in je DB.. mja, ik snap die redenatie niet. Alsof floats/doubles zo moeilijk zijn voor een database...

Je kan overigens ook..

1
2
3
4
5
6
7
8
setlocale(LC_ALL, array(
    'nl_NL.utf8',
    'nl_NL@euro',
    'nl_NL.iso885915@euro',
    'nl_NL.iso88591',
    'nl_NL',
    'POSIX',
));

proberen te gebruiken. Maar dat kan eventueel misgaan bij de input naar de database. Dan moet je binnen je transactie wellicht even de locale terugzetten naar iets Engelsachtig (LC_MONETARY en/of LC_NUMERIC aanpassen helpt al).

[ Bericht 9% gewijzigd door slacker_nl op 28-11-2013 22:11:41 ]
In theory there is no difference between theory and practice. In practice there is.
pi_133726614
1
2
3
4
5
6
7
8
9
10
<?php
SELECT 
*
FROM productoffers AS po
WHERE po
.id IN (
    
SELECT id
    FROM productoffers
    WHERE sellerId 
=1
)
AND 
po.sellerId 2
?>

Ik wil de productprijzen op halen van producten die zowel bij shop A als bij shop B zijn, waar ga ik de fout in met deze query? Had het ook al met EXISTS geprobeerd maar ik loop even flink te kutten nu :o
pi_133726853
quote:
19s.gif Op donderdag 28 november 2013 22:19 schreef TwenteFC het volgende:

[ code verwijderd ]

Ik wil de productprijzen op halen van producten die zowel bij shop A als bij shop B zijn, waar ga ik de fout in met deze query? Had het ook al met EXISTS geprobeerd maar ik loop even flink te kutten nu :o
where po.sellerid = 1 and po.sellerid =2?
In theory there is no difference between theory and practice. In practice there is.
pi_133726988
quote:
0s.gif Op donderdag 28 november 2013 22:22 schreef slacker_nl het volgende:

[..]

where po.sellerid = 1 and po.sellerid =2?
Dan krijg ik alle producten seller 1 en 2, ongeacht of seller 1 en 2 het beide product hebben.
pi_133727015
:P En nu ik dat typ bedenk ik me op eens iets |:(
pi_133727208
quote:
0s.gif Op donderdag 28 november 2013 21:56 schreef slacker_nl het volgende:

[..]
[ code verwijderd ]

Zo kan je het in je weergave aanpassen, ik zou het gewoon goed als float/double opslaan in je DB. En als centen opslaan in je DB.. mja, ik snap die redenatie niet. Alsof floats/doubles zo moeilijk zijn voor een database...

Je kan overigens ook..
[ code verwijderd ]

proberen te gebruiken. Maar dat kan eventueel misgaan bij de input naar de database. Dan moet je binnen je transactie wellicht even de locale terugzetten naar iets Engelsachtig (LC_MONETARY en/of LC_NUMERIC aanpassen helpt al).
Thanks, zal daar eens naar kijken. Het is allemaal read, ik doe verder zo goed als geen input/insert :)
pi_133727276
quote:
19s.gif Op donderdag 28 november 2013 22:24 schreef TwenteFC het volgende:

[..]

Dan krijg ik alle producten seller 1 en 2, ongeacht of seller 1 en 2 het beide product hebben.
hoezo, tis geen or toch? where (po.sellerid = 1 and po.sellerid = 2) and .. zou m.i. moeten werken.
In theory there is no difference between theory and practice. In practice there is.
pi_133727399
quote:
0s.gif Op donderdag 28 november 2013 22:29 schreef slacker_nl het volgende:

[..]

hoezo, tis geen or toch? where (po.sellerid = 1 and po.sellerid = 2) and .. zou m.i. moeten werken.
:P hoe kan één sellerId 1 en 2 zijn dan?

:@ Maar heb het al opgelost, er was simpelweg geen product dat zowel bij 1 als 2 beschikbaar was :@ :@ Het wordt hoogtijd dat ik ga slapen.
pi_133727650
quote:
19s.gif Op donderdag 28 november 2013 22:32 schreef TwenteFC het volgende:

[..]

:P hoe kan één sellerId 1 en 2 zijn dan?

:@ Maar heb het al opgelost, er was simpelweg geen product dat zowel bij 1 als 2 beschikbaar was :@ :@ Het wordt hoogtijd dat ik ga slapen.
Owja, das waar, maar je kan ook joinen met jezelf volgens mij.

dan krijg je iets als

1
2
3
4
5
6
7
8
SELECT 
    *   
FROM 
    productoffer AS po
JOIN 
    productoffer AS po2 on po2.id = po.id AND po.reseller_id = 1 
WHERE                                                                                                                                              
    po2.reseller_id = 2;

Al kan die AND in de JOIN ook een WHERE zijn, over die syntax twijfel ik even..
In theory there is no difference between theory and practice. In practice there is.
pi_133729144
quote:
0s.gif Op donderdag 28 november 2013 22:37 schreef slacker_nl het volgende:

[..]

Owja, das waar, maar je kan ook joinen met jezelf volgens mij.

dan krijg je iets als
[ code verwijderd ]

Al kan die AND in de JOIN ook een WHERE zijn, over die syntax twijfel ik even..
Heb het nu werkend maar je kan inderdaad gewoon een query in de ON gooien.
Wel tussen ( ) volgens mij. Toch bedankt voor de hulp ^O^
pi_133732830
Net een verneukte query uitgevoerd, doet hij toch nog aardig :P
Weergave van records 0 - 29 ( 74,554,590 totaal, query duurde 0.0055 sec)
pi_133755508
Ik wil in SQL met MATCH de overeenkomsten van een zoekopdracht vergelijk met een kolom en daar een percentage uit berekenen, dit werkt nu al goed.

Maar hoe kan ik woorden uitsluiten van deze match?
pi_133757216
quote:
0s.gif Op donderdag 28 november 2013 21:56 schreef slacker_nl het volgende:

[..]
[ code verwijderd ]

Zo kan je het in je weergave aanpassen, ik zou het gewoon goed als float/double opslaan in je DB. En als centen opslaan in je DB.. mja, ik snap die redenatie niet. Alsof floats/doubles zo moeilijk zijn voor een database...

Je kan overigens ook..
[ code verwijderd ]

proberen te gebruiken. Maar dat kan eventueel misgaan bij de input naar de database. Dan moet je binnen je transactie wellicht even de locale terugzetten naar iets Engelsachtig (LC_MONETARY en/of LC_NUMERIC aanpassen helpt al).
setlocale lijkt geen verandering er in te brengen.
  FOK!mycroftheld vrijdag 29 november 2013 @ 22:09:17 #249
128465 verified  bondage
Ingewikkeld
pi_133758325
quote:
19s.gif Op vrijdag 29 november 2013 21:15 schreef TwenteFC het volgende:
Ik wil in SQL met MATCH de overeenkomsten van een zoekopdracht vergelijk met een kolom en daar een percentage uit berekenen, dit werkt nu al goed.

Maar hoe kan ik woorden uitsluiten van deze match?
NOT MATCH(...)
pi_133759430
quote:
0s.gif Op donderdag 28 november 2013 21:56 schreef slacker_nl het volgende:

Zo kan je het in je weergave aanpassen, ik zou het gewoon goed als float/double opslaan in je DB. En als centen opslaan in je DB.. mja, ik snap die redenatie niet. Alsof floats/doubles zo moeilijk zijn voor een database...
Een database kan prima floats en doubles opslaan, maar de exacte waarde die je opslaat is niet de waarde die je terugkrijgt. Floats en doubles kunnen namelijk niet ieder getal exact weergeven. 1,99 wordt dan misschien 1,9899999999. En dat gaat vroeg of laat afrondingsproblemen geven die ook nog eens best lastig te vinden zijn. Bij financiele informatie is dat niet wenselijk, dus kun je beter met centen rekenen en pas bij weergave afronden.
  vrijdag 29 november 2013 @ 22:35:58 #251
187069 slacker_nl
Sicko pur sang
pi_133759561
quote:
0s.gif Op vrijdag 29 november 2013 22:33 schreef Light het volgende:

[..]

Een database kan prima floats en doubles opslaan, maar de exacte waarde die je opslaat is niet de waarde die je terugkrijgt. Floats en doubles kunnen namelijk niet ieder getal exact weergeven. 1,99 wordt dan misschien 1,9899999999. En dat gaat vroeg of laat afrondingsproblemen geven die ook nog eens best lastig te vinden zijn. Bij financiele informatie is dat niet wenselijk, dus kun je beter met centen rekenen en pas bij weergave afronden.
Jij wilt zeggen dat een postgres of mysql or oracle 1,99 als 1,98999 of als 1,97 teruggeeft? Ik geloof daar geen drol van.
In theory there is no difference between theory and practice. In practice there is.
pi_133759840
quote:
0s.gif Op vrijdag 29 november 2013 22:35 schreef slacker_nl het volgende:

[..]

Jij wilt zeggen dat een postgres of mysql or oracle 1,99 als 1,98999 of als 1,97 teruggeeft? Ik geloof daar geen drol van.
Light overdrijft een beetje, maar heeft wel een puntje.

What Every Computer Scientist Should Know About Floating-Point Arithmetic
Tegenwoordig moet je Dr. Ir. zijn om een beetje correct Nederlands te kunnen neerpleuren.
Abusing semicolons since 1987.
pi_133759912
quote:
0s.gif Op vrijdag 29 november 2013 22:35 schreef slacker_nl het volgende:

[..]

Jij wilt zeggen dat een postgres of mysql or oracle 1,99 als 1,98999 of als 1,97 teruggeeft? Ik geloof daar geen drol van.
Zie bijvoorbeeld ook hier:
http://stackoverflow.com/(...)ion-problem-in-mysql
pi_133759922
quote:
0s.gif Op vrijdag 29 november 2013 22:35 schreef slacker_nl het volgende:

[..]

Jij wilt zeggen dat een postgres of mysql or oracle 1,99 als 1,98999 of als 1,97 teruggeeft? Ik geloof daar geen drol van.
Het is gewoon opletten met wat je doet, bijv round(1.4545,2) geeft 1.45 terug.
pi_133760169
quote:
19s.gif Op vrijdag 29 november 2013 22:43 schreef TwenteFC het volgende:

[..]

Het is gewoon opletten met wat je doet, bijv round(1.4545,2) geeft 1.45 terug.
Het probleem is niet round(), het probleem is die 1.4545 en de nauwkeurigheid daarvan. Als je alleen dat getal hebt, zal het wel goed gaan. Als je spannende berekeningen doet en verschillende getallen gebruikt, kun je een afwijking krijgen.
pi_133760705
Ik maak in ieder geval geen berekeningen, ik krijg een lijst aangeleverd met producten + prijzen, deze insert ik gewoon in een database, maar moet tijdens het showen de prijs + verzendkosten bij elkaar optellen.

Maar laat ook maar, ik zie net dat de prijzen worden aangeleverd in #.##, met punt dus en niet met komma, stom stom stom :)
  zaterdag 30 november 2013 @ 00:11:17 #257
187069 slacker_nl
Sicko pur sang
pi_133763634
quote:
0s.gif Op vrijdag 29 november 2013 21:48 schreef xaban06 het volgende:

[..]

setlocale lijkt geen verandering er in te brengen.
Vreemd, hier wel. Wat is de return value van setlocale? Zie de docs even, daar staan wat nuttige dingen in..
In theory there is no difference between theory and practice. In practice there is.
pi_133799071
Vraagje over mijn database design:

Ik heb een locatie die onderdeel is van een groep en de locatie bevat meerdere ruimtes.
Nu wil ik openingstijden toevoegen en wel op een manier dat de groep de standaard openingstijden bevat voor elke locatie binnen de groep. Een locatie kan afwijkende openingstijden hebben die specifiek aan de locatie gekoppeld moeten worden. En tot slot kan het zijn dat een ruimte nog eigen openingstijden heeft die dan voorgaan.

Ik heb dus de tabellen:
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
CREATE TABLE `group` (
  `id` TINYINT NULL AUTO_INCREMENT DEFAULT NULL,
  `name` TINYINT NULL DEFAULT NULL,
  PRIMARY KEY (`id`)
);

CREATE TABLE `location` (
  `id` TINYINT NULL AUTO_INCREMENT DEFAULT NULL,
  `group_id` TINYINT NULL DEFAULT NULL,
  PRIMARY KEY (`id`)
);

CREATE TABLE `room` (
  `id` TINYINT NULL AUTO_INCREMENT DEFAULT NULL,
  `location_id` TINYINT NULL DEFAULT NULL,
  PRIMARY KEY (`id`)
);

CREATE TABLE `opening_hours` (
  `id` TINYINT NULL AUTO_INCREMENT DEFAULT NULL,
  `open_time` TIME NULL DEFAULT NULL,
  `close_time` TIME NULL DEFAULT NULL,
  `weekday` TINYINT NULL DEFAULT NULL,
  PRIMARY KEY (`id`)
);

Wat is nu de beste manier om de opening_hours aan de betreffende tabellen te koppelen. Ik zie zelf twee opties:
- twee velden toevoegen aan de opening hours, één voor het type tabel waar hij naar linkt (related_type) en één voor het bijbehorende id (related_id). Nadeel hiervan is dat je geen foreign keys kunt gebruiken omdat je niet weet naar welke tabel het related_id veld verwijst.
- Voor elk type een koppelingstabel maken. Dan kan je wel met foreign keys werken, maar krijg je misschien een wildgroei aan tabellen.

Welke van de twee opties is "beter" en waarom?
En zijn er nog andere opties?
pi_133801664
Derde optie: een opening_hours_id toevoegen aan group, location en room welke ook NULL kan zijn.
Schuimpje... mijn liefste. Verlaat mij nimmer weer...
pi_133802186
quote:
3s.gif Op zondag 1 december 2013 13:41 schreef papernote het volgende:
Derde optie: een opening_hours_id toevoegen aan group, location en room welke ook NULL kan zijn.
Opzich ook een mooie oplossing inderdaad, alleen heb ik hier een ander probleem, namelijk dat de openingstijden per dag verschillend kunnen zijn (het weekday veld in opening_hours) Dat betekent dat ieder eigenlijk 7 "openingstijden" heeft. Om nou aan elke tabel zeven velden toe te voegen lijkt me ook niet erg mooi.
pi_133802524
quote:
0s.gif Op zondag 1 december 2013 13:53 schreef Alfje het volgende:

[..]

Opzich ook een mooie oplossing inderdaad, alleen heb ik hier een ander probleem, namelijk dat de openingstijden per dag verschillend kunnen zijn (het weekday veld in opening_hours) Dat betekent dat ieder eigenlijk 7 "openingstijden" heeft. Om nou aan elke tabel zeven velden toe te voegen lijkt me ook niet erg mooi.
Dan kun je beter aan de tabel opening_hours een kolom location_id (of room_id) toevoegen, om aan te geven voor welke locatie die openingstijden gelden. Dan weet je ook zeker dat je voor iedere lokatie de tijden apart kunt aanpassen zonder dat je tijden van andere lokaties verandert.
pi_133882668
quote:
0s.gif Op zondag 1 december 2013 13:53 schreef Alfje het volgende:

[..]

Opzich ook een mooie oplossing inderdaad, alleen heb ik hier een ander probleem, namelijk dat de openingstijden per dag verschillend kunnen zijn (het weekday veld in opening_hours) Dat betekent dat ieder eigenlijk 7 "openingstijden" heeft. Om nou aan elke tabel zeven velden toe te voegen lijkt me ook niet erg mooi.
Als je het echt wilt normaliseren ontkomt je daar niet aan, anders gaat het botsen met je business rules. Wat je nog wel zou kunnen doen is een table "opening schema's" maken waarin je dus verschillende sets van openingstijden kunt definieren, eventueel zou je dat ook weer naar 2 tables kunnen normaliseren met weer een opsplitsing per dag.

Overigens zou ik in dit geval helemaal niet zo ver gaan met normaliseren, wanneer performance niet een groot probleem is, en er bijvoorbeeld geen belangrijke transacties plaatsvinden zou ik de openingstijden gewoon op extra columns zetten zoals dat met NoSQL databases ook gangbaar is.
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
pi_133947081
Ik loop alweer tegen een probleem op.
1PHP Fatal error:  Cannot use object of type mysqli_result as array in file.php

1
2
3
4
5
6
7
8
9
10
11
12
13
<?php
$productQuery     
"SELECT ean, name FROM products WHERE category = '$category'";
$productResult    $mysqli->query($productQuery);

while (
$productRow $productResult->fetch_assoc()) {
    
$productPriceQuery     "SELECT ean, price+shipmentCost AS totalPrice FROM prices WHERE ean = $productRow[ean] ORDER BY totalPrice ASC";
    
$productPriceResult    $mysqli->query($productPriceQuery);
    
    
$totalPrice            $productPriceResult->fetch_assoc();

    echo 
$productPriceResult["productURL"];
}
?>

Ik krijg de melding op regel 11.
  Moderator / Redactie Sport / Devops donderdag 5 december 2013 @ 16:00:27 #264
176766 zoem
zoemt
pi_133947270
Beste oplossing (vziw ik uit de context kan halen): gebruik een (LEFT) JOIN.

Oplossing voor jouw snippet: sla de documentatie erop na ;)
quote:
Return Values

Returns FALSE on failure. For successful SELECT, SHOW, DESCRIBE or EXPLAIN queries mysqli_query() will return a mysqli_result object. For other successful queries mysqli_query() will return TRUE.


[ Bericht 3% gewijzigd door zoem op 05-12-2013 16:14:03 ]
pi_133947430
quote:
0s.gif Op donderdag 5 december 2013 16:00 schreef zoem het volgende:
Beste oplossing (vziw ik uit de context kan halen): gebruik een JOIN.

Oplossing voor jouw snippet: sla de documentatie erop na ;)

[..]

Ik weet dat het efficienter kan dmv een 1 langere query, maar voor nu wil ik het doen zoals ik het heb, moet ook gewoon kunnen toch?
  Moderator / Redactie Sport / Devops donderdag 5 december 2013 @ 16:08:15 #266
176766 zoem
zoemt
pi_133947545
quote:
0s.gif Op donderdag 5 december 2013 16:05 schreef xaban06 het volgende:

[..]

Ik weet dat het efficienter kan dmv een 1 langere query, maar voor nu wil ik het doen zoals ik het heb, moet ook gewoon kunnen toch?
Natuurlijk, dat gaat ook werken. Alleen kan het aantal queries dan gigantisch oplopen als je een hele reeks aan producten hebt, waardoor de pagina traag wordt en/of de server het (onnodig) druk kan krijgen bij veel bezoekers.
pi_133947586
quote:
0s.gif Op donderdag 5 december 2013 16:08 schreef zoem het volgende:

[..]

Natuurlijk, dat gaat ook werken. Alleen kan het aantal queries dan gigantisch oplopen als je een hele reeks aan producten hebt, waardoor de pagina traag wordt en/of de server het (onnodig) druk kan krijgen bij veel bezoekers.
Klopt, maar dat is het geval niet :) En ik wil het liever nu werkend hebben dan dat ik me weer moet inlezen, proberen, repareren, proberen, etc etc. Kost erg veel tijd voor nu :)

Wat is er precies fout in mijn script?
  FOK!mycroftheld donderdag 5 december 2013 @ 16:10:23 #268
128465 verified  bondage
Ingewikkeld
pi_133947613
quote:
0s.gif Op donderdag 5 december 2013 16:08 schreef zoem het volgende:

[..]

Natuurlijk, dat gaat ook werken. Alleen kan het aantal queries dan gigantisch oplopen als je een hele reeks aan producten hebt, waardoor de pagina traag wordt en/of de server het (onnodig) druk kan krijgen bij veel bezoekers.
En daarbij nog de overhead welke wordt veroorzaakt door het verkeer tussen het script en de MySQL server... Ik zou zelf niet zo snel query's in een loop gaan zetten als dat niet nodig is.
  Moderator / Redactie Sport / Devops donderdag 5 december 2013 @ 16:11:14 #269
176766 zoem
zoemt
pi_133947639
quote:
0s.gif Op donderdag 5 december 2013 16:09 schreef xaban06 het volgende:

[..]

Klopt, maar dat is het geval niet :) En ik wil het liever nu werkend hebben dan dat ik me weer moet inlezen, proberen, repareren, proberen, etc etc. Kost erg veel tijd voor nu :)

Wat is er precies fout in mijn script?
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
<?php
$productQuery     
"SELECT ean, name FROM products WHERE category = '$category'";
$productResult    $mysqli->query($productQuery);

while (
$productRow $productResult->fetch_assoc()) {
    
$productPriceQuery     "SELECT ean, price+shipmentCost AS totalPrice FROM prices WHERE ean = $productRow[ean] ORDER BY totalPrice ASC";
    
$productPriceResult    $mysqli->query($productPriceQuery);
    
    
$totalPrice            $productPriceResult->fetch_assoc();

    echo 
$productPriceResult["productURL"]; // productPriceResult is dus een mysqli object, geen array
    
echo $totalPrice["productURL"]; // totalPrice moet je hebben, want die had je al omgezet naar een assoc array
    
}
?>
pi_133947807
quote:
0s.gif Op donderdag 5 december 2013 16:11 schreef zoem het volgende:

[..]
[ code verwijderd ]

Ik zie geen verschil tussen jouw en mijn code, of wel? :@
  FOK!mycroftheld donderdag 5 december 2013 @ 16:15:28 #271
128465 verified  bondage
Ingewikkeld
pi_133947813
quote:
0s.gif Op donderdag 5 december 2013 16:09 schreef xaban06 het volgende:

[..]

Klopt, maar dat is het geval niet :) En ik wil het liever nu werkend hebben dan dat ik me weer moet inlezen, proberen, repareren, proberen, etc etc. Kost erg veel tijd voor nu :)

Wat is er precies fout in mijn script?
Je kunt je query simpelweg aanpassen naar:

1
2
3
4
$productQuery     = "SELECT products.ean, products.name, prices.price+prices.shipmentCost AS totalPrice, products.productURL
                     FROM products
                     JOIN prices ON products.ean = prices.ean
                     WHERE category = '$category'";
pi_133947891
quote:
0s.gif Op donderdag 5 december 2013 16:15 schreef bondage het volgende:

[..]

Je kunt je query simpelweg aanpassen naar:
[ code verwijderd ]

Hartstikke bedankt voor de query, wordt gewaardeerd, maar mijn query wordt straks nog langer en dan weet ik dat ik er niet meer uit zal komen, vandaar hield ik het simpel :)

Zal het straks eens uitproberen.
  Moderator / Redactie Sport / Devops donderdag 5 december 2013 @ 16:17:20 #273
176766 zoem
zoemt
pi_133947903
quote:
0s.gif Op donderdag 5 december 2013 16:15 schreef xaban06 het volgende:

[..]

Ik zie geen verschil tussen jouw en mijn code, of wel? :@
De laatste regel in de loop is de verbetering, de voorlaatste regel is foutief.
quote:
0s.gif Op donderdag 5 december 2013 16:15 schreef bondage het volgende:

[..]

Je kunt je query simpelweg aanpassen naar:
[ code verwijderd ]

De vraag is of er meerdere prijzen zijn per artikel, want dan moet de code iets aangepast worden. Anders was dit een prima drop-in replacement geweest :)
pi_133947942
quote:
0s.gif Op donderdag 5 december 2013 16:17 schreef zoem het volgende:

[..]

De laatste regel in de loop is de verbetering, de voorlaatste regel is foutief.

[..]

De vraag is of er meerdere prijzen zijn per artikel, want dan moet de php code iets aangepast worden.
Per product zijn er meerdere prijzen, ik haal de goedkoopste eruit per product.
  FOK!mycroftheld donderdag 5 december 2013 @ 16:30:33 #275
128465 verified  bondage
Ingewikkeld
pi_133948400
quote:
0s.gif Op donderdag 5 december 2013 16:18 schreef xaban06 het volgende:

[..]

Per product zijn er meerdere prijzen, ik haal de goedkoopste eruit per product.
Deze query zou die data moeten teruggeven. Kan echter niet testen en weet niet zeker of het zo klopt... Misschien dat zoem hier eventueel een aanvulling op kan geven.

1
2
3
4
5
6
7
8
SELECT * FROM (
    SELECT products.ean, products.name, prices.price+prices.shipmentCost AS totalPrice, products.productURL
    FROM products
    JOIN prices ON products.ean = prices.ean
    WHERE category = '$category'
) AS t
GROUP BY t.ean
HAVING t.totalPrice = MIN(t.totalPrice)


[ Bericht 0% gewijzigd door bondage op 05-12-2013 17:48:45 ("; weggehaald na de variable) ]
  Moderator / Redactie Sport / Devops donderdag 5 december 2013 @ 16:32:45 #276
176766 zoem
zoemt
pi_133948465
Dat is het bekende groupwise maximum (of minimum) probleem. Via de bekende zoekmachine zijn daar tal voorbeelden en oplossingen over te vinden.
pi_133950827
quote:
0s.gif Op donderdag 5 december 2013 16:30 schreef bondage het volgende:

[..]

Deze query zou die data moeten teruggeven. Kan echter niet testen en weet niet zeker of het zo klopt... Misschien dat zoem hier eventueel een aanvulling op kan geven.
[ code verwijderd ]

Dit is inderdaad de juiste manier, en juist op deze manier hou je je queries ook redelijk leesbaar vind ik.
🕰️₿🕰️₿🕰️₿🕰️₿🕰️₿🕰️ TikTok next Block
pi_133966822
quote:
0s.gif Op donderdag 5 december 2013 16:32 schreef zoem het volgende:
Dat is het bekende groupwise maximum (of minimum) probleem. Via de bekende zoekmachine zijn daar tal voorbeelden en oplossingen over te vinden.
Thanks voor deze reactie.

Volgens mij moet dit werken:
1
2
3
SELECT products.ean, prices.ean, prices.price
FROM products, prices
WHERE prices.price=(SELECT MIN(prices.price) FROM prices WHERE products.ean = prices.ean);

/edit
het lijkt te werken, echter wil ik price+shipmentCost bijelkaar optellen, dan veranderd de WHERE, maar snap m niet helemaal :@
  FOK!mycroftheld vrijdag 6 december 2013 @ 00:04:34 #279
128465 verified  bondage
Ingewikkeld
pi_133967458
quote:
0s.gif Op donderdag 5 december 2013 23:51 schreef xaban06 het volgende:

[..]

Thanks voor deze reactie.

Volgens mij moet dit werken:
[ code verwijderd ]

/edit
het lijkt te werken, echter wil ik price+shipmentCost bijelkaar optellen, dan veranderd de WHERE, maar snap m niet helemaal :@
prices.price+prices.shipmentCost AS totalPrice in de select werkt niet? Als het niet werkt zou je je query in een andere query kunnen zetten en dan in de buitenste query de waarden optellen.
  vrijdag 6 december 2013 @ 10:06:07 #280
187069 slacker_nl
Sicko pur sang
pi_133972657
Kennen jullie PDO? Ga het gebruiken!! Die sql die "SELECT * FROM meuk where iets = $bla"; is jakkes. Maak een prepared statement en execute die:

1
2
3
# De syntax zal wellicht iets anders zijn, maar gebruik het!
$stm = $PDO_object->prepare("SELECT * FROM meuk WHERE iets = ?");
$stm->execute($bla);
In theory there is no difference between theory and practice. In practice there is.
abonnement Unibet Coolblue Bitvavo
Forum Opties
Forumhop:
Hop naar:
(afkorting, bv 'KLB')