De Devschuur Coffee Corner - Iteratie ➑

[Gamebuster]

WernerL schreef op vrijdag 27 maart 2015 @ 16:30:
24" vind ik wel prima. Wat moet je met zo' n achterlijk groot scherm voor je neus?

* Gamebuster heeft net een 60" TV gekocht

Deze namelijk: pricewatch: LG 60LB580V Zilver

[ Voor 20% gewijzigd door Gamebuster op 28-03-2015 19:05 ]

[Jan_V]

Firesphere schreef op vrijdag 27 maart 2015 @ 16:41:
[...]

Of gewoon niet trouwen.

Heb het enkele jaren uit kunnen stellen, maar moet nu toch een keer. Blijkbaar vinden vrouwen dat leuk (en ik zelf ook wel een beetje)

[xos]

incaz schreef op zaterdag 28 maart 2015 @ 18:37:
Blijft jammer idd. MySQL zou dergelijke indices gewoon moeten ondersteunen. Er is geen ambiguiteit, de werking is glashelder.

Hoe zou MySQL dat moeten implementeren dan?

[F.West98]

Waarom zou het niet kunnen?

[Megamind]

xos schreef op zaterdag 28 maart 2015 @ 19:59:
[...]

Hoe zou MySQL dat moeten implementeren dan?

Index laten zetten op een function output?

[incaz]

xos schreef op zaterdag 28 maart 2015 @ 19:59:
[...]

Hoe zou MySQL dat moeten implementeren dan?

In principe zoals een multicolumn index, waarbij je gewoon de functies voor indexeren opgeeft als achtereenvolgende columns. Dat zal meestal year, month, day zijn, maar zou ook schooljaar, kwartaal kunnen zijn als dat eenduidige functies zijn. Je slaat dan het resultaat op in de index en je hebt er direct toegang toe.
Gebruik van de geindexeerde functies zou dan gewoon op normale manier moeten worden geoptimaliseerd.

[WernerL]

Gamebuster schreef op zaterdag 28 maart 2015 @ 19:02:
[...]

* Gamebuster heeft net een 60" TV gekocht

Deze namelijk: pricewatch: LG 60LB580V Zilver

Heb je wat te compenseren?
[/flauw]

[Gamebuster]

WernerL schreef op zaterdag 28 maart 2015 @ 20:27:
[...]


Heb je wat te compenseren?
[/flauw]

Ja, ik krijg geen harde

Ik dacht, ik probeer het met wat grotere beelden van blote borsten enzo

[ Voor 16% gewijzigd door Gamebuster op 28-03-2015 21:11 ]

[HuHu]

Dan had je toch voor een tv met 3D-mogelijkheden moeten gaan.

[Ryur]

HuHu schreef op zaterdag 28 maart 2015 @ 21:47:
Dan had je toch voor een tv met 3D-mogelijkheden moeten gaan.

Of juist niet! Dan zie je alle imperfecties & fake van alle 'sterren' (en afhankelijk van je smaak kan "sterren" zelfs letterlijk worden genomen).
[/teveel gezopen]

[Gamebuster]

3D is overrated

[F.West98]

4D is tha bomb

[gekkie]

hmm ik hou het toch gewoon ouderwets bij dubbel D .. kinderhand is snel gevuld zullen we maar zeggen.

[Firesphere]

gekkie schreef op zaterdag 28 maart 2015 @ 22:30:
hmm ik hou het toch gewoon ouderwets bij dubbel D .. kinderhand is snel gevuld zullen we maar zeggen.

Kinderhand misschien, maar de mijne niet!

[SPee]

Gamebuster schreef op zaterdag 28 maart 2015 @ 19:02:
[...]

* Gamebuster heeft net een 60" TV gekocht

Deze namelijk: pricewatch: LG 60LB580V Zilver

Dan zorg ik voor de audio: Denon AVR-X1100W en Denon DBT-1713UD icm JBL Arena 130, 125C &120.

[CodeCaster]

incaz schreef op zaterdag 28 maart 2015 @ 20:16:
[...]


In principe zoals een multicolumn index, waarbij je gewoon de functies voor indexeren opgeeft als achtereenvolgende columns. Dat zal meestal year, month, day zijn, maar zou ook schooljaar, kwartaal kunnen zijn als dat eenduidige functies zijn. Je slaat dan het resultaat op in de index en je hebt er direct toegang toe.
Gebruik van de geindexeerde functies zou dan gewoon op normale manier moeten worden geoptimaliseerd.

Als performance al een probleem zou zijn bij zo'n query, zijn er zoals gewoonlijk verschillende opties. Wanneer de query gedaan wordt om bijvoorbeeld een verjaardagspagina te genereren ("welke members hebben een geboortedatum ingevuld en zijn op deze dag, ongeacht het jaar, jarig?"), kun je deze pagina éénmaal per dag genereren, cachen en enkel bijwerken wanneer iemand (de geboortedatum op) zijn profiel aanpast.

Je kunt ook persisted, indexed, computed columns toevoegen, die als output DAY(birthday) hebben. Dan kun je daarop queryen. Als dat geen optie is voor jouw RDBMS, voeg je zelf een kolom toe per datumdeel waarop je veelvuldig wil queryen, die je vervolgens vult met een trigger.

Om maar wat te noemen.

[Alex)]

What the hell, Steam...

Laat maar, het Javascriptje erachter had gewoon nog niet door dat LastPass al iets had ingevuld

[ Voor 40% gewijzigd door Alex) op 29-03-2015 00:33 ]

[F.West98]

Er zijn sites die LastPass actief weren

[Firesphere]

F.West98 schreef op zondag 29 maart 2015 @ 00:35:
Er zijn sites die LastPass actief weren

Ehhh, wat, echt? Welke sites dan? Dat heb ik gelukkig nog nooit meegemaakt.

[F.West98]

Firesphere schreef op zondag 29 maart 2015 @ 00:46:
[...]

Ehhh, wat, echt? Welke sites dan? Dat heb ik gelukkig nog nooit meegemaakt.

Sites met fancy JS.....
Geen idee welke, maar dat je dan geen Ctrl C kan doen EN geen rechtermuisknop. Dus dat je niets kan genereren zonder moeilijk te doen.

[Douweegbertje]

F.West98 schreef op zondag 29 maart 2015 @ 00:53:
[...]

Sites met fancy JS.....
Geen idee welke, maar dat je dan geen Ctrl C kan doen EN geen rechtermuisknop. Dus dat je niets kan genereren zonder moeilijk te doen.

Tja nu heb je het toevallig over één ding. Als weerwoord: heel fijn dat jij denkt dat het copy/pasten of uberhaupt het wachtwoord onder je plak toets houden veilig is noch handig.
En 9/10x wordt zoiets gedaan om te voorkomen dat men het wachtwoord uit het éne veld copied in het 'wachtwoord check' veld.
Het is 10x veiliger als je geen input van een 3rd party direct kan 'injecten' maar goed.

[F.West98]

Douweegbertje schreef op zondag 29 maart 2015 @ 03:43:
[...]


Tja nu heb je het toevallig over één ding. Als weerwoord: heel fijn dat jij denkt dat het copy/pasten of uberhaupt het wachtwoord onder je plak toets houden veilig is noch handig.
En 9/10x wordt zoiets gedaan om te voorkomen dat men het wachtwoord uit het éne veld copied in het 'wachtwoord check' veld.
Het is 10x veiliger als je geen input van een 3rd party direct kan 'injecten' maar goed.

Nouja je kan dan dus niet met rechtermuisknop generate openen, het inserten werkt niet en dan maar copy-pasten werkt OOK niet.

[HuHu]

KeePass kun je instellen om toetsaanslagen te simuleren en geen copy-paste te gebruiken. Dan zou het gewoon moeten werken per website. Dat wordt echter als "minder veilig" beschouwt, omdat een keylogger dan je hele wachtwoord binnen krijgt (net zoals je hem zelf zou typen).

Een wachtwoord copy-pasten is beter, want een keylogger registreert alleen de ctrl-v toetsaanslag. Omdat je ook het clipboard uit zou kunnen lezen wordt het wachtwoord in meerdere kleine stukjes zowel (1) via copy-paste geplaatst, als (2) getypt met toetsaanslagen: http://keepass.info/help/v2/autotype_obfuscation.html

[F.West98]

LastPass integreert in de browser. Die zou toch gewoon het value-attribuut aan kunnen passen? Dan heb je geen keyloggers nodig...

[HuHu]

Ik gok dat wat JavaScript code op de website wijzigingen aan het value-attribuut terugdraait als er geen keyboard-event was.

[RayNbow]

Gamebuster schreef op zaterdag 28 maart 2015 @ 22:01:
3D is overrated

Kirby disagrees

[Feanathiel]

Hmm, GitHub was vandaag wat trager. Even naar de status pagina gekeken, en toen was het mij duidelijk. Laatste paar dagen niks van gemerkt; die lui hebben het goed voor elkaar daar.

[incaz]

CodeCaster schreef op zaterdag 28 maart 2015 @ 23:10:

Als performance al een probleem zou zijn bij zo'n query, zijn er zoals gewoonlijk verschillende opties.

Ja, of je gebruikt gewoon 'BETWEEN ... AND ...' en maakt gewoon gebruik van de index, maar dat neemt niet weg dat indexeren op date-functions mi een functionaliteit is die het dbms gewoon zou kunnen bieden. En als ze dan toch bezig zijn, indexeren mogelijk maken op elke pure functie.

[Matis]

HuHu schreef op zondag 29 maart 2015 @ 04:01:
Ik gok dat wat JavaScript code op de website wijzigingen aan het value-attribuut terugdraait als er geen keyboard-event was.

Klopt, de inlogpagina van BND doet dat ook. Daar moet ik mijn gebruikersnaam vanuit LastPass kopieren naar het gebruikersnaamveld. Anders denkt ie dat ik vergeten ben mijn gebruikersnaam in tevullen.

[RobertMe]

incaz schreef op zondag 29 maart 2015 @ 10:22:
[...]


Ja, of je gebruikt gewoon 'BETWEEN ... AND ...' en maakt gewoon gebruik van de index, maar dat neemt niet weg dat indexeren op date-functions mi een functionaliteit is die het dbms gewoon zou kunnen bieden. En als ze dan toch bezig zijn, indexeren mogelijk maken op elke pure functie.

RDBMSen ondersteunen dat ook. En dat is ook de reden waarom je MySQL geen RDBMS moet noemen. MySQL ondersteund gewoon enorm veel niet. Ik zag een tijd terug ook een presentatie van 'nieuwe' features in de SQL standaard (2005 en 2008 denk ik) en daar waren ook best veel dingen tussen die MySQL niet ondersteund, maar zelfs wel in SQLite werken

ja, ik weet dat MySQL technisch gezien gewoon een RDBMS is, maar het mist gewoon zo enorm veel features die de concurrentie wel heeft...

[gekkie]

Net nog gebruikt in Postgresql .. maar moet wel een timestamp veld gebruiken zonder timezone .. anders is tie niet immutable en wil hij er geen index voor creeeren. Maar werkt dan prima en vlot met date_trunc() functies.
Achja heb toch in een DB het liefste alles gewoon in UTC opgeslagen .. timezone is leuk voor de applicatie en presentatie-laag om zich druk over te maken.

[Creepy]

Ook mysql ondersteunt prima indexen op date, datetime en timestamp velden, mocht iemand hier willen doen alsof dat niet het geval is Maar een functie gebruiken aan de linkerkant van de vergelijking betekent een full table scan.

[Firesphere]

Pure horror hier in huis vanochtend.
Een echte Hitchcock!

De koffie was op

[gekkie]

Firesphere schreef op zondag 29 maart 2015 @ 12:19:
Pure horror hier in huis vanochtend.
Een echte Hitchcock!

De koffie was op

Maar er was nog bier? .. wat een overdreven gedoe

Creepy schreef op zondag 29 maart 2015 @ 12:00:
Ook mysql ondersteunt prima indexen op date, datetime en timestamp velden, mocht iemand hier willen doen alsof dat niet het geval is Maar een functie gebruiken aan de linkerkant van de vergelijking betekent een full table scan.

Dan zou ik er dus toch niet uitkomen met iets als een:

SQL:

select date_trunc('mintues', timestamp) as timestamp_minutes from table where date_trunc('minutes', timestamp) > %s  group by timetamp_minutes

Zou nogal vervelend zijn voor m'n timeseries queries .. want die lopen met een index toch beduidend vlotter in Postgres dan zonder ..
Maar goed ik heb dan nu ook wel wat onmogelijke queries gemaakt in postgresql om timeseries data als json terug te krijgen die vrijwel direct in d3js grafiekjes kan pompen.

[ Voor 66% gewijzigd door gekkie op 29-03-2015 12:42 ]

[incaz]

Creepy schreef op zondag 29 maart 2015 @ 12:00:
Ook mysql ondersteunt prima indexen op date, datetime en timestamp velden, mocht iemand hier willen doen alsof dat niet het geval is Maar een functie gebruiken aan de linkerkant van de vergelijking betekent een full table scan.

Indexeren op datefunctions idd, en die gebruiken als ze in een where of join gebruikt zijn. Het is niet noodzakelijk dat het gebruik van een functie leidt tot een full table scan - het is gewoon een missende implementatie van iets wat echt heel fijn zou zijn.

RobertMe schreef op zondag 29 maart 2015 @ 11:04:
[...]

RDBMSen ondersteunen dat ook. En dat is ook de reden waarom je MySQL geen RDBMS moet noemen. MySQL ondersteund gewoon enorm veel niet.

... en php is ook kut.

Mijn ervaringen tot nu toe zijn met informix, mssql, oracle en mysql, en mysql voldoet over het algemeen prima. Postgresql heb ik nog niet mee gewerkt, die staat nog wel nadrukkelijk op mijn verlanglijstje.

[Firesphere]

Ik gebruik bij voorkeur MariaDB in plaats van MySQL.

[F.West98]

Ik vond tijdens het leren van .NET MVC dingetjes enzo wel dat MSSQL enórm veel features heeft t.o.v. MySQL

[Firesphere]

incaz schreef op zondag 29 maart 2015 @ 10:22:
[...]


Ja, of je gebruikt gewoon 'BETWEEN ... AND ...' en maakt gewoon gebruik van de index, maar dat neemt niet weg dat indexeren op date-functions mi een functionaliteit is die het dbms gewoon zou kunnen bieden. En als ze dan toch bezig zijn, indexeren mogelijk maken op elke pure functie.

Dat ik daar niet direct aan gedacht heb.


Performance winst waar je u tegen zegt

[gekkie]

Firesphere schreef op zondag 29 maart 2015 @ 12:43:
Ik gebruik bij voorkeur MariaDB in plaats van MySQL.

Ik ben atheist .. liever een DB waarbij ik geen bidprentjes, wezengroetjes en rozenkransen nodig heb ..
Maar gewoon eentje die gelijk mekkert als er ook maar enige ambiguiteit is in wat ik van hem vraag en netjes aangeeft waar die ambiguiteit hem in zit.

[Firesphere]

gekkie schreef op zondag 29 maart 2015 @ 12:51:
[...]

Ik ben atheist .. liever een DB waarbij ik geen bidprentjes, wezengroetjes en rozenkransen nodig heb ..
Maar gewoon eentje die gelijk mekkert als er ook maar enige ambiguiteit is in wat ik van hem vraag en netjes aangeeft waar die ambiguiteit hem in zit.

Je weet waar de naam MariaDB vandaan komt? Want het heeft niets met bidprentjes te maken
En ambiguiteit aanwijzen, dat doet MariaDB gewoon hoor.

[gekkie]

Firesphere schreef op zondag 29 maart 2015 @ 12:54:
[...]
Je weet waar de naam MariaDB vandaan komt? Want het heeft niets met bidprentjes te maken
En ambiguiteit aanwijzen, dat doet MariaDB gewoon hoor.

Uiteraard, hmm maar eens even wat gelezen .. word me alleen nog niet echt duidelijk wat nou de standaard is voor "SQL_MODE" .. en of je nu dus standaard out of the box dingen als ONLY_FULL_GROUP_BY krijgt.

Ik vind het opzich prima als je performance shortcut extensions erin bouwt .. maar die horen standaard uit te staan, zodat je ze met je volle verstand aan mag zetten en de consequenties mag dragen.

[RobertMe]

Creepy schreef op zondag 29 maart 2015 @ 12:00:
Ook mysql ondersteunt prima indexen op date, datetime en timestamp velden, mocht iemand hier willen doen alsof dat niet het geval is Maar een functie gebruiken aan de linkerkant van de vergelijking betekent een full table scan.

Ik doelde inderdaad op het gebruik van functionele indexen. Die worden niet door MySQL gesupport, maar wel door de meeste andere RDBMSen.

gekkie schreef op zondag 29 maart 2015 @ 11:54:
Achja heb toch in een DB het liefste alles gewoon in UTC opgeslagen .. timezone is leuk voor de applicatie en presentatie-laag om zich druk over te maken.

Het mooie is dat een timestamp with timezone onderwater ook wordt opgeslagen als UTC. Deze gebruikt dus ook niet meer data dan een timestamp without timezone. Het kost alleen een beetje overhead omdat bij elke write & read er dus van/naar UTC geconverteerd moet worden (iets wat je in jouw geval dus in de applicatie zult doen).

gekkie schreef op zondag 29 maart 2015 @ 13:06:
[...]
Ik vind het opzich prima als je performance shortcut extensions erin bouwt .. maar die horen standaard uit te staan, zodat je ze met je volle verstand aan mag zetten en de consequenties mag dragen.

Totdat je bij een bedrijf terecht komt waar ze MySQL met alleen maar MyISAM support compilen, want InnoDB is trager. En iets als transacties en FKs heb je niet nodig, want database consistentie is iets wat de programmeur/applicatie moet afhandelen (ook in het geval dat MySQL eruit klapt midden tijdens een "transactie") En ook daar heb ik "ze" erop moeten wijzen dat MySQL strings gewoon afkapt als deze te lang is voor de kolom, en "foobar" in een (var)char(1) dus "f" oplevert, en geen error (want daar hadden ze een bug mee, en ze hadden geen idee waar het vandaan kwam).

[Firesphere]

RobertMe schreef op zondag 29 maart 2015 @ 13:17:
[...]

Totdat je bij een bedrijf terecht komt waar ze MySQL met alleen maar MyISAM support compilen, want InnoDB is trager. En iets als transacties en FKs heb je niet nodig, want database consistentie is iets wat de programmeur/applicatie moet afhandelen (ook in het geval dat MySQL eruit klapt midden tijdens een "transactie") En ook daar heb ik "ze" erop moeten wijzen dat MySQL strings gewoon afkapt als deze te lang is voor de kolom, en "foobar" in een (var)char(1) dus "f" oplevert, en geen error (want daar hadden ze een bug mee, en ze hadden geen idee waar het vandaan kwam).

Eeeehhhhhh echt?

[RobertMe]

Firesphere schreef op zondag 29 maart 2015 @ 13:20:
[...]

Eeeehhhhhh echt?

Yip Laten we het erop houden dat ik blij ben dat ik daar weg ben.

[Firesphere]

RobertMe schreef op zondag 29 maart 2015 @ 13:27:
[...]

Yip Laten we het erop houden dat ik blij ben dat ik daar weg ben.

Holy crap. Ok, ja, dat kan ik me voorstellen.

[Creepy]

Ik kan overigens niet zo snel documentatie vinden van een rdbms die wel indexen met date functions op de kolom ondersteunt. Maar er lijkt hier gesuggereerd te worden dat dat er wel is. In de docs van mssql en pgsql kom ik dat niet zo snel tegen. Ook niet zo gek lijkt me, aangezien de waarde van de kolom door de functie heen gehaald moet worden en je dus een full table scan zal moeten doen. Een rdbms die zelf extra indexen gaat aanleggen voor mogelijke functies lijkt me ook niet handig want dat kost weer extra write performance.

[ Voor 37% gewijzigd door Creepy op 29-03-2015 13:43 ]

[Firesphere]

Creepy schreef op zondag 29 maart 2015 @ 13:38:
Ik kan overigens niet zo snel documentatie vinden van een rdbms die wel indexen met date functions op de kolom ondersteunt. Maar er lijkt hier gesuggereerd te worden dat dat er wel is. In de docs van mssql en pgsql kom ik dat niet zo snel tegen. Pok niet zo gek lijkt me, aangezien de waarde van de kolom door de functie heen gehaald moet worden en je dus een full table scan zal moeten doen. Een rdbms die zelf extra indexen gaat aanleggen voor mogelijke functies lijkt me ook niet handig want dat kost weer extra write performance.

Datums zijn gewoon altijd gezeik, linksom of rechtsom.

[Creepy]

Das jouw mening

[Firesphere]

Creepy schreef op zondag 29 maart 2015 @ 13:44:
Das jouw mening

Dat klopt

[RobertMe]

Ik doelde op functionele indexen in het algemeen. Niet op iets als incaz omschreef om automatisch indexen te gebruiken als er bepaalde date functies gebruikt werden. Maar functionele voor iets als hier omschreven door Megamind lijkt mij dat gewoon moet werken (alhoewel de opmerking van gekkie wel plausible klinkt, dat dit weer niet kan op een "timestamp with timezone" kolom (in PG), omdat voor elke query de functie dan een ander resultaat kan geven (op basis van de gevraagde timezone))

[ Voor 6% gewijzigd door RobertMe op 29-03-2015 13:46 ]

[gekkie]

RobertMe schreef op zondag 29 maart 2015 @ 13:17:
[...]
Het mooie is dat een timestamp with timezone onderwater ook wordt opgeslagen als UTC. Deze gebruikt dus ook niet meer data dan een timestamp without timezone. Het kost alleen een beetje overhead omdat bij elke write & read er dus van/naar UTC geconverteerd moet worden (iets wat je in jouw geval dus in de applicatie zult doen).

Mjah ik kwam vooral wat gedoe tegen met due date_trunc functies en geen timezone, aangezien je server en client wel een timezone hebben .. en er was dus toch enige ongewenste automagische conversie met verkeerde resultaten tot gevolg .. dus elke DB connectie zet nu expliciet de timezone naar UTC.
Nu werkt het allemaal prima, maar goed blijft altijd een gedoe .. timezones

Totdat je bij een bedrijf terecht komt waar ze MySQL met alleen maar MyISAM support compilen, want InnoDB is trager. En iets als transacties en FKs heb je niet nodig, want database consistentie is iets wat de programmeur/applicatie moet afhandelen (ook in het geval dat MySQL eruit klapt midden tijdens een "transactie") En ook daar heb ik "ze" erop moeten wijzen dat MySQL strings gewoon afkapt als deze te lang is voor de kolom, en "foobar" in een (var)char(1) dus "f" oplevert, en geen error (want daar hadden ze een bug mee, en ze hadden geen idee waar het vandaan kwam).

Tsja verplaatsen van het probleem zal inderdaad performance winst opleveren als je het probleem vervolgens niet elders oplost
Ik heb toch echt liever een DB die gemaakt is door mensen die slimmer of wakkerder zijn dan ik ben en me gewoon om de oren meppen.

Creepy schreef op zondag 29 maart 2015 @ 13:38:
Ik kan overigens niet zo snel documentatie vinden van een rdbms die wel indexen met date functions op de kolom ondersteunt. Maar er lijkt hier gesuggereerd te worden dat dat er wel is. In de docs van mssql en pgsql kom ik dat niet zo snel tegen. Ook niet zo gek lijkt me, aangezien de waarde van de kolom door de functie heen gehaald moet worden en je dus een full table scan zal moeten doen. Een rdbms die zelf extra indexen gaat aanleggen voor mogelijke functies lijkt me ook niet handig want dat kost weer extra write performance.

Erhmm het gebeurd niet automagisch nee, je moet er wel zelf even met CREATE INDEX een index voor jouw specifieke geval maken (zoals je ook voor een column doet)

[ Voor 19% gewijzigd door gekkie op 29-03-2015 13:47 ]

[CodeCaster]

Creepy schreef op zondag 29 maart 2015 @ 13:38:
Ik kan overigens niet zo snel documentatie vinden van een rdbms die wel indexen met date functions op de kolom ondersteunt. Maar er lijkt hier gesuggereerd te worden dat dat er wel is. In de docs van mssql en pgsql kom ik dat niet zo snel tegen. Ook niet zo gek lijkt me, aangezien de waarde van de kolom door de functie heen gehaald moet worden en je dus een full table scan zal moeten doen. Een rdbms die zelf extra indexen gaat aanleggen voor mogelijke functies lijkt me ook niet handig want dat kost weer extra write performance.

PostgreSQL Functional Indexes?

[Creepy]

CodeCaster schreef op zondag 29 maart 2015 @ 13:45:
[...]

PostgreSQL Functionl Indexes?

Ah kijk, dat kan op deze manier wel ja. Maar uiteraard altijd voorgedefinieerd.

[gekkie]

Creepy schreef op zondag 29 maart 2015 @ 13:47:
[...]
Ah kijk, dat kan op deze manier wel ja. Maar uiteraard altijd voorgedefinieerd.

Maakt jouw DB dan gratis en voor niks indexen op elke kolom .. ongeacht of je die gaat gebruiken ?

[Creepy]

nee natuurlijk niet, maar die suggestie leek even gewekt te worden.

[CodeCaster]

MSSQL ondersteunt dat ook niet, daar moet je ook een aparte kolom maken met de functie-output, die persisten (dus of een "echte" kolom, of een computed kolom die persisted is) en dáár een index op zetten èn op die kolom queryen. Optimaal is het allemaal niet.

[ Voor 30% gewijzigd door CodeCaster op 29-03-2015 13:52 ]

[Firesphere]

Maar indexes op extreme variabelen, zoals bijvoorbeeld datetimes etc. zijn volgens mij gewoon tricky, om weer terug te komen op waar ik deze discussie mee aftrapte.

Er zijn teveel variabelen om echt lekker te kunnen filteren. Als je keys of indexes weet, is het een stuk makkelijker.

[gekkie]

Creepy schreef op zondag 29 maart 2015 @ 13:49:
nee natuurlijk niet, maar die suggestie leek even gewekt te worden.

DB met een glazenbol die in de toekomst kan kijken .. welke queries ik hoevaak ga doen en welke performance critical zijn.. en hoe daar binnen de memory constraints zo effectief mogelijke indexes bij passen ..
Dromen mag

[gekkie]

Firesphere schreef op zondag 29 maart 2015 @ 13:51:
Maar indexes op extreme variabelen, zoals bijvoorbeeld datetimes etc. zijn volgens mij gewoon tricky, om weer terug te komen op waar ik deze discussie mee aftrapte.

Er zijn teveel variabelen om echt lekker te kunnen filteren. Als je keys of indexes weet, is het een stuk makkelijker.

Datum is toch ook alleen maar een getal (als je de tijdszone en daytimesaving gedoe eraf haalt) ?

Sterker nog voor mijn json uitpoep gaat de timestamp door:

SQL:

"SELECT EXTRACT(EPOCH FROM date_trunc('milliseconds', query_timestamp_utc at time zone 'UTC')) * 1000 as query_timestamp_utc, "

En dan heb je gewoon een (big)int.

[ Voor 19% gewijzigd door gekkie op 29-03-2015 13:58 ]

[Firesphere]

gekkie schreef op zondag 29 maart 2015 @ 13:55:
[...]

Datum is toch ook alleen maar een getal (als je de tijdszone en daytimesaving gedoe eraf haalt) ?

Ja, maar op een range filteren is een ander verhaal, omdat je soort-van wildcards moet gebruiken. Op andere indexes weet je over het algemeen waar je op moet filteren.

[incaz]

gekkie schreef op zondag 29 maart 2015 @ 12:51:
[...]
Maar gewoon eentje die gelijk mekkert als er ook maar enige ambiguiteit is in wat ik van hem vraag en netjes aangeeft waar die ambiguiteit hem in zit.

Is heel erg hetzelfde probleem dat veel mensen met php hebben. Zelf heb ik daar dus eigenlijk nooit aanvaringen mee.

Zonder fk-constraints kom je nog een heel end trouwens. Niet aan te bevelen, maar minder groot issue dan je zou verwachten. Zonder transactions wordt het wel beroerd.

En het afkappen van input... Ik heb daar eens over nagedacht, maar eigenlijk zie ik niet wat daar het probleem van is. Het levert problemen op als je gaat vergelijken op where field = 'foobar' MAAR dat probleem treedt op bij de output en niet bij de input.
Ik denk eigenlijk niet dat een error op het afkappen automatisch dat probleem voorkomt.

RobertMe schreef op zondag 29 maart 2015 @ 13:45:
Ik doelde op functionele indexen in het algemeen. Niet op iets als incaz omschreef om automatisch indexen te gebruiken als er bepaalde date functies gebruikt werden.

Niet automatisch indexen hoor - maar wel dat je het makkelijk als index op kunt geven, en dat ze automatisch gebruikt worden door de optimizer als je een datefunction gebruikt en het gunstig is.

[gekkie]

Firesphere schreef op zondag 29 maart 2015 @ 13:57:
[...]
Ja, maar op een range filteren is een ander verhaal, omdat je soort-van wildcards moet gebruiken. Op andere indexes weet je over het algemeen waar je op moet filteren.

Hoe bedoel je wildcards ?

Ik index dus met een date_trunc() op een tijdsschaal die grover is die opgeslagen wordt ja, als alle waarden uniek zijn heeft indexen inderdaad niet zoveel zin.

Maar ik krijg data met een microseconde timestamp .. en wil de data hebben between seconds ... dus een index getrunct op seconden geeft me een aardige winst.

[Firesphere]

gekkie schreef op zondag 29 maart 2015 @ 14:01:
[...]

Hoe bedoel je wildcards ?

Ik index dus met een date_trunc() op een tijdsschaal die grover is die opgeslagen wordt ja, als alle waarden uniek zijn heeft indexen inderdaad niet zoveel zin.

Maar ik krijg data met een microseconde timestamp .. en wil de data hebben between seconds ... dus een index getrunct op seconden geeft me een aardige winst.

Hmmm, dat is op zich wel een goed idee ja. Ik gebruik dus volledige datetime's, maar m'n filter werkt op date.

[RobertMe]

De BETWEEN oplossing zou in principe toch ook correct moeten werken. De index is immers gesorteerd. De database kan dus op basis van de BTREE efficiënt zoeken naar de eerste waarde, vervolgens de volgende stuk voor stuk testen of ze nog binnen het range liggen, en als er eentje buiten het range ligt kan die stoppen met zoeken.

Het enige voordeel wat het opslaan van "een stukje" heeft (met date_trunc dus) is dat de index kleiner is en daardoor sneller gelezen kan worden van disk en het doorzoeken/testen van de waardes zal ook sneller zijn. Maar dat verschil zal, denk ik, verwaarloosbaar zijn ten opzichte van uberhaupt een index (kunnen) gebruiken vs een full table scan.

[gekkie]

Firesphere schreef op zondag 29 maart 2015 @ 14:03:
[...]
Hmmm, dat is op zich wel een goed idee ja. Ik gebruik dus volledige datetime's, maar m'n filter werkt op date.

Date zelfs .. tsja misschien maria vragen of ze een nieuwe kolom wil baren .. ter test ..
met de handel getrunct op alleen datum zonder tijd. Kijken hoe veel vlotter die is .. en daarna overstappen of een andere DB .. want je data meerdere keren opslaan is ook zo wat.

[Firesphere]

Ik denk, voor het project waar het om gaat, ik meer heb aan het gescheiden opslaan van datum en tijd. Dat zal denk ik een flinke performance boost zijn, aangezien alles draait om de datetimes.

gekkie schreef op zondag 29 maart 2015 @ 14:11:
[...]

Date zelfs .. tsja misschien maria vragen of ze een nieuwe kolom wil baren .. ter test ..
met de handel getrunct op alleen datum zonder tijd. Kijken hoe veel vlotter die is .. en daarna overstappen of een andere DB .. want je data meerdere keren opslaan is ook zo wat.

Het is geen dubbele data, en Maria heeft gewoon Date en Time als mogelijke columns. Dus dat is't probleem niet direct lijkt me.

[ Voor 57% gewijzigd door Firesphere op 29-03-2015 14:13 ]

[gekkie]

Firesphere schreef op zondag 29 maart 2015 @ 14:12:
Ik denk, voor het project waar het om gaat, ik meer heb aan het gescheiden opslaan van datum en tijd. Dat zal denk ik een flinke performance boost zijn, aangezien alles draait om de datetimes.
[...]
Het is geen dubbele data, en Maria heeft gewoon Date en Time als mogelijke columns. Dus dat is't probleem niet direct lijkt me.

Als je het uit gaat splitsen niet nee .. hooguit dat je ergens .. in db of in je applicatie wat tijd kwijt bent aan het splitsen, maar dat zal idd nog wel meevallen. DB wissel zal er vast wel niet inzitten als het project al onderweg is.

[Firesphere]

gekkie schreef op zondag 29 maart 2015 @ 14:18:
[...]

Als je het uit gaat splitsen niet nee .. hooguit dat je ergens .. in db of in je applicatie wat tijd kwijt bent aan het splitsen, maar dat zal idd nog wel meevallen. DB wissel zal er vast wel niet inzitten als het project al onderweg is.

Heh, no way, dit draait al 2 jaar en het enige dat ik momenteel doe is alles proberen beter te laten draaien, meer caching, meer snelheid, etc.

Probleem zal eerder zijn dat ik ook in m'n imports de zooi moet aanpassen. Ik ben afhankelijk van 5 API's om alles samen te voegen tot een logisch geheel, dus het omzetten gaat wel even wat werk kosten. Maar een andere DB engine o.i.d. is echt geen optie meer nu.

[gekkie]

Firesphere schreef op zondag 29 maart 2015 @ 14:20:
[...]

Heh, no way, dit draait al 2 jaar en het enige dat ik momenteel doe is alles proberen beter te laten draaien, meer caching, meer snelheid, etc.

Probleem zal eerder zijn dat ik ook in m'n imports de zooi moet aanpassen. Ik ben afhankelijk van 5 API's om alles samen te voegen tot een logisch geheel, dus het omzetten gaat wel even wat werk kosten. Maar een andere DB engine o.i.d. is echt geen optie meer nu.

Mjah dat is met postgresql ook wel zo ... standaard instellingen van Debian packages zijn vrij conservatief, zeker qua geheugen gebruik .. dus als je meer geheugen hebt en dat laat staan heb je een krachtige DB in een dwangbuis ...

En opzich als je aan splitsing date en time altijd genoeg gaat hebben dan is het geen probleem, maar het kunnen creeëren van een index op een timestamp kolom maakt het wel een stuk flexibeler.
Als blijkt dat het ineens per uur moet ipv per dag .. best .. een CREATE INDEX date_trunc('hour', timestampcolumn) .. en klaar .. eventueel concurrent te doen .. en weer door

Achja .. wellicht eens mee expirimenteren voor de toekomst
En maria / mysql draait hier ook wel .. maar dat is omdat de meeste opensource projecten toch alleen op maria/mysql draaien ..

Maar alles wat ik zelf maak .. en alles waarbij een project me de keuze geeft .. defi postgresql

[ Voor 19% gewijzigd door gekkie op 29-03-2015 14:46 ]

[Douweegbertje]

Maar alles wat ik zelf maak .. en alles waarbij een project me de keuze geeft .. defi postgresql

Vooraf definiëren wat je DB moet worden zonder dat je weet wat er moet komen is gewoon al slecht hoor maar ok.

[gekkie]

Douweegbertje schreef op zondag 29 maart 2015 @ 14:58:
[...]
Vooraf definiëren wat je DB moet worden zonder dat je weet wat er moet komen is gewoon al slecht hoor maar ok.

Tsja opensource .. mariadb/mysql .. no thanks .. nosql om het nosql'en .. no thanks ...
graphdb wellicht als het er voor op het lijf geschreven zou zijn.

Ik begin liever met iets waarik wel fidusie in heb dat het bijna alles wat ik ooit zou willen aan kan, dan uitgaan van owwww mysql is voldoende voor die paar simpele query's .. en dan later de meuk moeten omschrijven ipv een indexje erbij creeëren.
Kortom default postgresql tenzij ik een andere zwaarwegende reden zie, kan bij elk project wel overnieuw een interessante studie vooraf maken op basis van een database zonder data met simpele queries .. zonder dat er een OOM of andere problemen zich voordoen .. en dan constateren dat mysql briljant is .. maarja.

(en jsonb en de hstore en ltree extensies zijn ook wel prettig,
en een ogenschijnlijk stabiele developers community, zonder al te veel fratsen als de hele tent verpatsen aan een zonnig orakel en dan toch maar weer forken etc. .. no thanks)

[ Voor 25% gewijzigd door gekkie op 29-03-2015 15:10 ]

[RobertMe]

gekkie schreef op zondag 29 maart 2015 @ 15:02:
en een ogenschijnlijk stabiele developers community, zonder al te veel fratsen als de hele tent verpatsen aan een zonnig orakel en dan toch maar weer forken etc. .. no thanks)

QFT. Buiten dat ik MySQL sowieso al "niet ok" vond is het hele verkoop, forken, ... gebeuren nog eens extra slecht. Eerst de boel voor grof geld aan Sun verkopen, maar als die door Oracle worden opgeslokt gaan janken en zelf weer gaan forken. Dan had je de boel maar niet moeten verkopen, en anders, deal with it. Je hebt je zak met geld gekregen, ga dan niet lopen janken als alsnog iets gebeurd waar je het niet mee eens bent.

Daarnaast is de featureset van PG inderdaad zo groot dat je eigenlijk niet snel naar een andere DB systeem hoeft te kijken.
Wil je (gedeeltelijk) ongestructureerde data opslaan? Prima, maak een json(b) kolom aan (waar je ook nog eens indexen op kunt maken, en vervolgens een betere performance aan iets als MongoDB hebben (WC eend verhaal, maar toch).
Wil je met geospatial data werken? Sure, installeer de PostGIS extensie.
Wil je full text search gebruiken? Dat kan (MySQL kan dat nog steeds alleen op MyISAM, of in ieder geval niet op InnoDB, en dan nog is de functionaliteit van PG uitgebreider, inclusief ranking, verschillende stukken combineren naar een index, met verschillende gewichten per stukje)
Wil je met graphs werken? Ook dat kan (geen idee hoe goed het performed, maar je kunt het in ieder geval in de DB oplossen met recursieve queries, in MySQL zou dit stukken moeilijker zijn, en daarmee ook trager)

[Douweegbertje]

Dat zeg je wel heel simpel, maar postgresql is niet super bij enorm veel reads operations en kan al snel een overkill zijn vs mysql / sqlite etc.
Prima overigens hoor, dat je voor je zelf een solide db hebt gevonden, maar alsnog vind ik de redenatie iets te snel.

En we kunnen het ook omdraaien;

dan uitgaan van owwww mysql is voldoende voor die paar simpele query's .. en dan later de meuk moeten omschrijven ipv een indexje erbij creeëren.

En wat nu als het een relatief klein 'projectje' is waar je veel reads moet doen? Nou dan zit je met een achterlijk 'log' DB systeem die helemaal er niet geschikt voor is.

Ik bedoel, het gaat echt beide kanten op.

[gekkie]

RobertMe schreef op zondag 29 maart 2015 @ 15:30:
[...]

QFT. Buiten dat ik MySQL sowieso al "niet ok" vond is het hele verkoop, forken, ... gebeuren nog eens extra slecht. Eerst de boel voor grof geld aan Sun verkopen, maar als die door Oracle worden opgeslokt gaan janken en zelf weer gaan forken. Dan had je de boel maar niet moeten verkopen, en anders, deal with it. Je hebt je zak met geld gekregen, ga dan niet lopen janken als alsnog iets gebeurd waar je het niet mee eens bent.

Daarnaast is de featureset van PG inderdaad zo groot dat je eigenlijk niet snel naar een andere DB systeem hoeft te kijken.
Wil je (gedeeltelijk) ongestructureerde data opslaan? Prima, maak een json(b) kolom aan (waar je ook nog eens indexen op kunt maken, en vervolgens een betere performance aan iets als MongoDB hebben (WC eend verhaal, maar toch).

yups, het schijnt dat mongo z'n performance ook weer beduidend zou hebben verbeterd in de tussentijd .. maar goed .. dat ik alles in 1 DB kan doen vindt ik ook wel prettig ..

En ook hier geldt weer dat ik mijn data meer vertrouw bij de olifant dan bij een stel nieuwe cowboys, waarbij het over het algemeen zo is dat ze niets oplossen maar vooral de problemen verplaatsen (het liefste richting applicatie .. in het kader van niet ons probleem .. ik heb een keertje een proefje gedaan met die no-sql document meuk .. en in het begin ontwikkelde dat wel makkelijk .. met een semi lege DB performde het ook erg lekker .. maarja .. gradueel werd het toch van kwaad tot erger .. zonder evidente oplossingen. Not gonna do that twice.

[incaz]

Wauw, de haat jegens mysql zit diep Ik word ook niet gelukkig van Sun of Oracle, maar verder... ik ben geloof ik te pragmatisch voor dat soort diepprincipiele gevoelens over technologie. (Andere onderwerpen, soit, maar db's en programmeertalen*?)

Anyway, ik dien hierbij een motie in om 'mysql is kut' op te nemen in de onderwerpencyclus van de coffee corner!

* Behalve python en hun whitespace-gezeur**

** incaz vist

[gekkie]

Douweegbertje schreef op zondag 29 maart 2015 @ 15:31:
Dat zeg je wel heel simpel, maar postgresql is niet super bij enorm veel reads operations en kan al snel een overkill zijn vs mysql / sqlite etc.
Prima overigens hoor, dat je voor je zelf een solide db hebt gevonden, maar alsnog vind ik de redenatie iets te snel.

En we kunnen het ook omdraaien;
[...]
En wat nu als het een relatief klein 'projectje' is waar je veel reads moet doen? Nou dan zit je met een achterlijk 'log' DB systeem die helemaal er niet geschikt voor is.

Ik bedoel, het gaat echt beide kanten op.

sqlite als een simpele "ïn-app" database, daar kun je me prima aan krijgen, maar dan is mysql ook overkill en log, het verschil in logheid tussen mysql en postgresql is volgens mij nagenoeg non-existent.

En als postgresql me te log is .. kan ik altijd nog een unlogged table nemen , maar dat is dan wel mijn eigen expliciete en non-default keuze.
En voornamelijk read zal betekenen dat je postgresql wellicht wat anders moet optimaliseren qua geheugen gebruik, zoals ik al eerder aanhaalde is de default setup van distributies vaak een aardig corset/dwangbuis.
Daarnaast verwacht ik bij dat "kleine projectje" dan ook niet dermate veel reads op heel veel data dat dat werkelijk een probleem is. Als mysql m'n query in 1ms doet en postgresql in 2ms .. voor die bijna lege simpele db .. soit .. couldn't care less ... ik start liever gelijk vanuit iets wat ik naar alle kanten fatsoenlijk uit kan bouwen en waarvoor ik dus ook al boilerplate code heb liggen en wat ook in simpele gevallen niet dermate beroerd performt dat het een struikelblok gaat vormen.

[RobertMe]

De haat tegen MySQL is sowieso enorm hoog sinds de overname door Oracle. Er zijn intussen voldoende Linux distros die MySQL niet meer in de repos hebben staan, en MariaDB als alternatief aanbieden (en installeren als er een MySQL dependency is).

Daarnaast denk ik ook dat de NoSQL beweging een voordeel heeft gehad. Niet perse dat NoSQL daadwerkelijk voordelen heeft (vooral zoals de originele "no SQL"), maar wel dat het ervoor heeft gezorgd dat grote groepen developers onderzoek zijn gaan doen naar alternatieven voor standaard RDBMSen (en ik denk voornamelijk vanuit de MySQL hoek). Waarbij er nu meer voor de nieuwe NoSQL wordt gegaan, not only SQL. Waarbij er dus bv een PG wordt ingezet om zowel de gestructureerde data op te slaan, met daarnaast de ongestructureerde data in JSON kolommen. Of het gebruik van toegespitste key/value stores (Memcached, Redis, ...) voor het opslaan van simpele data (caching bv).

[gekkie]

incaz schreef op zondag 29 maart 2015 @ 15:42:
Wauw, de haat jegens mysql zit diep Ik word ook niet gelukkig van Sun of Oracle, maar verder... ik ben geloof ik te pragmatisch voor dat soort diepprincipiele gevoelens over technologie. (Andere onderwerpen, soit, maar db's en programmeertalen*?)

Anyway, ik dien hierbij een motie in om 'mysql is kut' op te nemen in de onderwerpencyclus van de coffee corner!

* Behalve python en hun whitespace-gezeur**

** incaz vist

Ach haat haat .. wat is haat .. ik bedoel .. het werkt .. doet meestal ook wat je wil .. zeker als je een beetje oplet .. maar goed postgresql doet dat .. en meer.

En het zonnige orakel is niet zo zeer principieel .. als wel een continuiteits dingetje .. meerdere tenten gehoord die in eerste instantie toch maar flink betaald hebben aan het orakel om te zorgen dat het hun data bleef oprakelen aan support meuk contractjes. Voordat je fork dan op stoom is zit er toch een gat .. en aangezien ze het één keer gepresteerd hebben .. waarom zou maria niet van haar voetstuk vallen voor een 2e keer ?

Hmm de whitespace van python overleef ik ook prima eigenlijk, al is een IDE dan wel prettig .. wat me dan weer enigzins tegen de borst stuit .. maar goed.

'mysql is kut' .. wel een slecht surrogaat dan .. toch minder plezier aan te beleven.

[ Voor 3% gewijzigd door gekkie op 29-03-2015 16:36 ]

[RayNbow]

gekkie schreef op zondag 29 maart 2015 @ 13:55:
[...]

DB met een glazenbol die in de toekomst kan kijken .. welke queries ik hoevaak ga doen en welke performance critical zijn.. en hoe daar binnen de memory constraints zo effectief mogelijke indexes bij passen ..
Dromen mag

Misschien niet een DB die in de toekomst kan kijken, maar we kunnen misschien wel denken aan een JITter. Een database dat in de gaten houdt wat voor query's er worden uitgevoerd en hoe vaak.

[Struikrover]

Dang, error in iptables script waardoor ik me heb buitengesloten van de dev server.
Het universum vertelt me om te gaan chillen op zondag

[gekkie]

RayNbow schreef op zondag 29 maart 2015 @ 16:42:
[...]

Misschien niet een DB die in de toekomst kan kijken, maar we kunnen misschien wel denken aan een JITter. Een database dat in de gaten houdt wat voor query's er worden uitgevoerd en hoe vaak.

Mjah maar dan nog hangt het er wel vanaf welke queries je belangrijker vind dan andere, maar op zich zou dat inderdaad wel (deels) moeten kunnen. Opzich doe je het handmatig ook door slow queries te loggen inclusief explain .. en vervolgens dat te interpreteren .. en met een redelijke kans een indexje erbij maken als eerste poging om het beter te maken.

[gekkie]

Struikrover schreef op zondag 29 maart 2015 @ 16:50:
Dang, error in iptables script waardoor ik me heb buitengesloten van de dev server.
Het universum vertelt me om te gaan chillen op zondag

Haha komt me bekend voor ... alles in de firewall dicht .. en dan ssh van 22 naar een andere poort verhuizen zonder na te denken ...

[Struikrover]

^ lol . Dat van mij was ook heel dom. Applicatie specifieke poorten staan onder de regels voor toegang van buiten. Drie keer raden wat je vaker aanpast...
Eerste wat ik morgen doe ik die IP adressen bovenaan zetten

[Firesphere]

gekkie schreef op zondag 29 maart 2015 @ 14:33:
[...]

Mjah dat is met postgresql ook wel zo ... standaard instellingen van Debian packages zijn vrij conservatief, zeker qua geheugen gebruik .. dus als je meer geheugen hebt en dat laat staan heb je een krachtige DB in een dwangbuis ...

Ik zou eerlijk gezegd niet weten hoe ik een DB in een dwangbuis heb. Behalve dat ik vast zit aan MySQL of MariaDB, heb ik verder alles zelf in beheer

En opzich als je aan splitsing date en time altijd genoeg gaat hebben dan is het geen probleem, maar het kunnen creeëren van een index op een timestamp kolom maakt het wel een stuk flexibeler.
Als blijkt dat het ineens per uur moet ipv per dag .. best .. een CREATE INDEX date_trunc('hour', timestampcolumn) .. en klaar .. eventueel concurrent te doen .. en weer door

Gezien de natuur van deze applicatie, denk ik dat een splitsing meer toegevoegde waarde heeft. Maar dat is natuurlijk wel project-afhankelijk in elke omstandigheid. In dit geval is de volledige timestamp heel erg van toepassing, maar hoef ik er niet altijd op te filteren, maar soms weer wel, etc.

Achja .. wellicht eens mee expirimenteren voor de toekomst
En maria / mysql draait hier ook wel .. maar dat is omdat de meeste opensource projecten toch alleen op maria/mysql draaien ..

Maar alles wat ik zelf maak .. en alles waarbij een project me de keuze geeft .. defi postgresql

Achteraf gezien, had ik dit inderdaad moeten beginnen in Postgres. Maar dat is de koe in haar kont kijken, en ik moet nu roeien met de riemen die ik heb.

[gekkie]

Firesphere schreef op zondag 29 maart 2015 @ 17:45:
[...]
Ik zou eerlijk gezegd niet weten hoe ik een DB in een dwangbuis heb. Behalve dat ik vast zit aan MySQL of MariaDB, heb ik verder alles zelf in beheer

Als je database rammelkast plenty geheugen geeft, maar je database (default) conservatief geconfigureerd staat .. en je er derhalve geen gebruik van maakt. Had je ook bijvb in kunnen zetten voor een mega cache als je vooral simpele reads hebt.
DB een beetje meer lucht geven en je kunt zo een wereld van verschil hebben.

Gezien de natuur van deze applicatie, denk ik dat een splitsing meer toegevoegde waarde heeft. Maar dat is natuurlijk wel project-afhankelijk in elke omstandigheid. In dit geval is de volledige timestamp heel erg van toepassing, maar hoef ik er niet altijd op te filteren, maar soms weer wel, etc.
[...]
Achteraf gezien, had ik dit inderdaad moeten beginnen in Postgres. Maar dat is de koe olifant in haar kont kijken, en ik moet nu roeien met de riemen die ik heb.

met de date_trunc functies en indexen erop zou ik ze in postgresql denk ik niet zo heel gauw splitsen, maar goed zou idd soms ook misschien nog wel handig kunnen zijn. Maar in jouw geval is het idd de snelste oplossing met de meeste winst denk ik.

[RobertMe]

gekkie schreef op zondag 29 maart 2015 @ 18:18:
[...]

met de date_trunc functies en indexen erop zou ik ze in postgresql denk ik niet zo heel gauw splitsen, maar goed zou idd soms ook misschien nog wel handig kunnen zijn. Maar in jouw geval is het idd de snelste oplossing met de meeste winst denk ik.

Zou een index op een DATE kolom dan echt zoveel sneller zijn dan een BETWEEN op een DATETIME index? Lijkt mij dat dat verschil toch minimaal is, in ieder geval in vergelijking met een full table scan wat Firesphere tot nu toe had.

[Creepy]

Met de 200.000 records die Firesphere heeft denk ik niet dat het merkbaar gaat schelen. Met miljoenen records kan ik me voorstellen dat de index zonder tijdseenheid sneller zal zijn dan met.

[Struikrover]

Zoals altijd maar 1 manie om er achter te komen: meten

[Acid_Burn]

Ik ben nu bezig mijzelf Symfony2 aan te leren (ik zie dat bij verschillende vacatures als eis/voordeel staan)... Nu ben ik behoorlijk thuis in Symfony1 en allemachtig was is dit anders Tot nu toe heb ik wel het gevoel dat S2 veel omslachtiger werkt, maar dat kan komen omdat ik er nog niet zo in thuis ben. De templating engine met twigs is dan wel weer leuk.

[Mercatres]

Acid_Burn schreef op zondag 29 maart 2015 @ 21:41:
Ik ben nu bezig mijzelf Symfony2 aan te leren (ik zie dat bij verschillende vacatures als eis/voordeel staan)... Nu ben ik behoorlijk thuis in Symfony1 en allemachtig was is dit anders Tot nu toe heb ik wel het gevoel dat S2 veel omslachtiger werkt, maar dat kan komen omdat ik er nog niet zo in thuis ben. De templating engine met twigs is dan wel weer leuk.

Twigs
Feel mee gespeeld, weinig concreet mee gedaan

[Biersteker]

Douweegbertje schreef op zondag 29 maart 2015 @ 14:58:
[...]


Vooraf definiëren wat je DB moet worden zonder dat je weet wat er moet komen is gewoon al slecht hoor maar ok.

Naja, ben ik niet helemaal met je eens. Ja, het weten van je queryscheme is super nuttig voor je database keuze. Maar je mag toch ook wel een zekere ruimte geven aan experimental dingetjes, en dan kies je gewoon de meest courante db implementatie, en ga je limitiaties bekijken om vanuit dat standpunt de meest optimale configuraties te testen.

[Douweegbertje]

Biersteker schreef op zondag 29 maart 2015 @ 21:49:
[...]

Naja, ben ik niet helemaal met je eens. Ja, het weten van je queryscheme is super nuttig voor je database keuze. Maar je mag toch ook wel een zekere ruimte geven aan experimental dingetjes, en dan kies je gewoon de meest courante db implementatie, en ga je limitiaties bekijken om vanuit dat standpunt de meest optimale configuraties te testen.

Nee, je wilt niet experimenteren op een project. Daar is een project op zich voor. Vervolgens kies je de meest 'courante' db, voor dat project en niet in zijn algemeenheid. Een fiets is heel erg gangbaar, maar niet om naar Afrika te gaan. Prima als jij dan nog je fiets wilt 'tweaken' om de meest optimale configuratie te behalen maar het blijft kut.

Ik vind het verder een rare discussie, snap sowieso niet waarom er een discussie over nodig is. Je bekijkt altijd vooraf naar de specs e.d. en niet achteraf. Beetje het zelfde om maar te zeggen; HTML is geweldig dus ik gebruik dat voor mijn serverside afhandeling.. oh wait..

[BikkelZ]

Ben we aan het verdiepen in wat er allemaal mogelijk is qua geautomatiseerd releasen met rollback en farm flips en dat soort dingen voor ASP.Net maar dat is toch ff een berg informatie verwerken tjongejonge. Heb me nooit zo met devops bezig gehouden voorheen.

[Megamind]

Douweegbertje schreef op zondag 29 maart 2015 @ 22:44:
[...]
Beetje het zelfde om maar te zeggen; HTML is geweldig dus ik gebruik dat voor mijn serverside afhandeling.. oh wait..

Zo ging het wel met JS

[gekkie]

Douweegbertje schreef op zondag 29 maart 2015 @ 22:44:
[...]


Nee, je wilt niet experimenteren op een project. Daar is een project op zich voor. Vervolgens kies je de meest 'courante' db, voor dat project en niet in zijn algemeenheid. Een fiets is heel erg gangbaar, maar niet om naar Afrika te gaan. Prima als jij dan nog je fiets wilt 'tweaken' om de meest optimale configuratie te behalen maar het blijft kut.

Ik vind het verder een rare discussie, snap sowieso niet waarom er een discussie over nodig is. Je bekijkt altijd vooraf naar de specs e.d. en niet achteraf. Beetje het zelfde om maar te zeggen; HTML is geweldig dus ik gebruik dat voor mijn serverside afhandeling.. oh wait..

Tsja .. beetje een probleem van waar begin je .. en waar stop je .. met iedere keer het wiel uit vinden.

Ik neem aan dat jij blanco begint .. en iedere keer 30 jaar database theorie en ontwikkeling in assembly loopt te kloppen om de optimale configuratie te bepalen .. voordat je met je project begint ?

Of ga je in projecten en in je verdere leven uit van dingen die zich min of meer bewezen hebben, kijkt af en toe eens rond en expirimenteert eens wat.

En waarom zou ik me beperken tot en DB die nipt aan de specs voldoet .. als er ook een DB is die daar dan ook op alle vlakken ook aan voldoet .. en daarnaast nog wat meer in z'n mars heeft.

[ Voor 7% gewijzigd door gekkie op 29-03-2015 23:48 ]

[Douweegbertje]

gekkie schreef op zondag 29 maart 2015 @ 23:45:
[...]

Tsja .. beetje een probleem van waar begin je .. en waar stop je .. met iedere keer het wiel uit vinden.

Ik neem aan dat jij blanco begint .. en iedere keer 30 jaar database theorie en ontwikkeling in assembly loopt te kloppen om de optimale configuratie te bepalen .. voordat je met je project begint ?

Of ga je in projecten en in je verdere leven uit van dingen die zich min of meer bewezen hebben, kijkt af en toe eens rond en expirimenteert eens wat.

Je hoeft niet het uiterste te pakken want dat slaat weer nergens op. Lees nu eens wat ik precies zeg. Ik geef aan dat ik vooraf bekijk wat ik nodig heb, zo'n antwoord kun je afhankelijk van de situatie en het project binnen één uur beantwoord hebben (voor bijv. een database). Ik weet wat wel wat stabiele producten zijn, en wat er ongeveer overblijft qua opties. Echter is alles wat je pakt voor een project, dermate belangrijk voor het verloop dat je dat vooraf goed moet bedenken en definiëren. Deze 'tijd' krijg je gegarandeerd terug omdat je verder in het project tegen minder problemen aanloopt.
Ik schrijf en beschrijf namelijk wél gewoon mijn projecten uit, iets wat gewoon de standaard hoort te zijn. Op basis daarvan kun je pas conclusies trekken, en nooit anders. Niet op een 'gevoel' of een (ooit) bewezen standaard.
Dat jij er van maakt dat ik het wiel opnieuw uitvind omdat ik graag m'n specs wil weten en daarop pas wil bouwen (heuy.. fundering anyone?) snap ik dan weer niet want dan mag je mij even quoten waar ik dat precies vertel.
Als ik iemand zie die zonder te kijken al roept "we gebruiken X voor dit project" dan sla ik die faliekant neer met mijn toetsenbord

[gekkie]

Douweegbertje schreef op zondag 29 maart 2015 @ 23:57:
[...]
Je hoeft niet het uiterste te pakken want dat slaat weer nergens op. Lees nu eens wat ik precies zeg. Ik geef aan dat ik vooraf bekijk wat ik nodig heb, zo'n antwoord kun je afhankelijk van de situatie en het project binnen één uur beantwoord hebben (voor bijv. een database). Ik weet wat wel wat stabiele producten zijn, en wat er ongeveer overblijft qua opties. Echter is alles wat je pakt voor een project, dermate belangrijk voor het verloop dat je dat vooraf goed moet bedenken en definiëren. Deze 'tijd' krijg je gegarandeerd terug omdat je verder in het project tegen minder problemen aanloopt.
Ik schrijf en beschrijf namelijk wél gewoon mijn projecten uit, iets wat gewoon de standaard hoort te zijn. Op basis daarvan kun je pas conclusies trekken, en nooit anders. Niet op een 'gevoel' of een (ooit) bewezen standaard.
Dat jij er van maakt dat ik het wiel opnieuw uitvind omdat ik graag m'n specs wil weten en daarop pas wil bouwen (heuy.. fundering anyone?) snap ik dan weer niet want dan mag je mij even quoten waar ik dat precies vertel.
Als ik iemand zie die zonder te kijken al roept "we gebruiken X voor dit project" dan sla ik die faliekant neer met mijn toetsenbord

Achja de meeste projecten houden zich helaas in the end niet aan de specs die in den beginne zijn gespecificeerd. Voor eerste oplevering al niet .. of anders daarna in opvolging. Dus een beetje speling feature wise zou aardig zijn.

En als er in de wereld van RDMBS'en er nou een overweldigende keuze is als je van opensource uitgaat en iets meer dan in-app data in kwijt wil (exit sqllite). Dan hou ik alleen op die "specs" alleen mysql/maria en postgresql over .. ik heb nog weinig unieke features of performance in mysql/mariadb gevonden ..

Hou je nog over dat het je interessanter lijkt om iets van no SQL of graphs db's te gaan gebruiken.

Ben benieuwd hoelang jij er sóchtends over doet voor je op je werk bent ... al die keuzes die uitgewerkt moeten worden .. wat er op het broodje moet .. of het uberhaupt een broodje moet zijn .. wat voor broodje dan .. wordt het de auto de fiets de trein ... of is het een ik gebruik m'n default tenzij er zwaarwegende redenen zijn om te denken dat dat hem niet gaat worden ... auto met een platte accu of in de garage .. geen brood in huis ..

[Douweegbertje]

gekkie schreef op maandag 30 maart 2015 @ 00:08:
[...]

Achja de meeste projecten houden zich helaas in the end niet aan de specs die in den beginne zijn gespecificeerd. Voor eerste oplevering al niet .. of anders daarna in opvolging. Dus een beetje speling feature wise zou aardig zijn.

En als er in de wereld van RDMBS'en er nou een overweldigende keuze is als je van opensource uitgaat en iets meer dan in-app data in kwijt wil (exit sqllite). Dan hou ik alleen op die "specs" alleen mysql/maria en postgresql over .. ik heb nog weinig unieke features of performance in mysql/mariadb gevonden ..

Hou je nog over dat het je interessanter lijkt om iets van no SQL of graphs db's te gaan gebruiken.

Ben benieuwd hoelang jij er sóchtends over doet voor je op je werk bent ... al die keuzes die uitgewerkt moeten worden .. wat er op het broodje moet .. of het uberhaupt een broodje moet zijn .. wat voor broodje dan .. wordt het de auto de fiets de trein ... of is het een ik gebruik m'n default tenzij er zwaarwegende redenen zijn om te denken dat dat hem niet gaat worden ... auto met een platte accu of in de garage .. geen brood in huis ..

Dus ja, omdat jij je niet aan de specs kan houden, ga je maar van alles doen om er later alles maar van wat te kunnen maken. Het is zeker logisch om over de toekomst na te denken, maar als jij dit al zo goed weet dan zijn dat je daadwerkelijke specs en je heb alsnog alles uitgewerkt. Waarom doe je dat dan gewoon niet? Jij maakt dus specs of een planning die je net zo goed niet kan maken, of domweg na het maken in de prullenbak kan gooien. Weet je hoe stom dit eigenlijk klinkt wat je nu zegt? Niet aan jou persoonlijk gericht hoor, want ik weet wel hoe het daadwerkelijk in de praktijk eraan toe gaat, maar het is allemaal zo simpel.

Verder ben ik relatief snel klaar in de ochtend. Geen idee waarom je dit vraagt. Wellicht denk je een cynische opmerking te maken omdat het blijkbaar raar is om over zaken na te denken. Maar hey, je lichaam en geest kun je net zo goed als product zien. Ik heb een bepaald schema, niet hard op papier hoor maar gewoon om fit te zijn, zowel fysiek als mentaal. Door dit kan ik ook gewoon normaal boodschappen doen en heb ik juist rust aan mijn hoofd omdat ik weet waar ik aan toe ben. Uiteraard bestel ik ook wel eens een keer wat en tief ik wat oude meuk uit de koelkast weg omdat het over de datum is. Uiteindelijk kan ik met gemak de 10km lopen, 3 keer in de week, 1x een voetbal training doen en een wedstrijd op de zaterdag spelen. Verder heb ik totaal geen last van een vermoeide lichaam of geest en ben ik best stress-bestendig geworden. Dat kan je alleen bereiken door over wat dingen na te denken, te plannen en wat dan ook. En nee, voordat je weer begint te overdrijven: ja ik heb zeer zeker nog een sociaal leven en zondig genoeg en niet alles is zwart-wit op papier gezet.

[HuHu]

Er zijn genoeg projecten waarbij het nadenken om tot de perfecte keuze te komen meer kost (in tijd, geld of wat-dan-ook) dan gewoon de standaard keuzes te pakken en te beginnen.

[Martijn19]

Het was voor mij weer het maandelijkse "upgrade-je-javascript-stack" feestje.

Afgelopen week:

Angular -> React + Flux
Node.js -> io.js
Grunt -> Gulp

En als toevoeging Browserify + Babeljs om in ES6 te kunnen werken