ID's in tabellen zijn zeer zelden opeenvolgend, en dat boeit niks. Het zijn identifiers, geen counters. Als je ruimtegebrek hebt kun je beter de kolom groter maken, ipv een INT een BIGINT ofzo. ID's aanpassen waarnaar gerefereerd wordt is zelden een goed idee.quote:Op donderdag 30 oktober 2008 16:30 schreef WheeleE het volgende:
Tussen de bedrijven door aan het knutselen op een procedure in SQL om een aantal tabellen met identitycolumns te fixen. Er zitten nogal wat flinke gaten in de telling door slordige shutdowns enzo. Elke identitykolom wordt echter wel gebruikt om aan te referen in andere tabellen, geforceerd dor constraints.
Het probleem is gelukkig nog niet dringend, maar voordat straks mijn applicatie niet meer overweg kan met de grootte van de id's wil ik het fixen.
Ben bezig met me wowmap te voorzien van markers ( http://wyrimaps.net/wow ). Dit gaan een hele boel markers worden gezien de dingen die ik op de kaart wil plaatsen. Door deze in google gears te zetten hoop ik de performence omhoog te halen voor plekken waar mensen al gekeken hebben. Een 2e waar naar ik aan het kijken ben zijn de map tiles of ik die kan cache enzo het sneller laadbaar maken. (En uiteraard op bandbreedte besparenquote:Op donderdag 30 oktober 2008 16:20 schreef CraZaay het volgende:
Het grootste probleem is de penetratie van Google Gears denk ik, maar de mensen die Gears geïnstalleerd hebben weten wel wat het is en staan je ongetwijfeld toe om het te gebruiken. Het zijn juist early adopters die ermee willen experimenteren. Het opent wel een wereld van mogelijkheden overigens, vooral voor offline werken. Waarvoor ga je het gebruiken?
Klopt ook wel, maar in dit geval zitten er identitygaps van ettelijke tienduizenden nummers tussen. Het datatype is al numeric(18). De database is het probleem niet direct, die kan het nog aan, maar de applicatie zelf is niet aan te passen (lang leve legacy!). De applicatie kan straks niet meer met de grote id's om gaan, en dat wil ik voor zijn.quote:Op donderdag 30 oktober 2008 18:42 schreef Farenji het volgende:
[..]
ID's in tabellen zijn zeer zelden opeenvolgend, en dat boeit niks. Het zijn identifiers, geen counters. Als je ruimtegebrek hebt kun je beter de kolom groter maken, ipv een INT een BIGINT ofzo. ID's aanpassen waarnaar gerefereerd wordt is zelden een goed idee.
In Google Maps zei je he? In dat geval is het binnenhalen van de markers (positie, etc) niet het probleem, maar het renderen in Google Maps. Dat duurt lang met veel markersquote:Op donderdag 30 oktober 2008 19:02 schreef WyriHaximus het volgende:
Ben bezig met me wowmap te voorzien van markers ( http://wyrimaps.net/wow ). Dit gaan een hele boel markers worden gezien de dingen die ik op de kaart wil plaatsen. Door deze in google gears te zetten hoop ik de performence omhoog te halen voor plekken waar mensen al gekeken hebben.
Ben het zo aan het maken dat hij per tile ze markers binnen haald. Zodat ook alleen voor die tile de markers geapplied hoeven worden op dat moment. Hoe ik dat met markers ga doen die later tevoorschijn gehaald worden moet ik nog verzinnenquote:Op zondag 2 november 2008 09:37 schreef CraZaay het volgende:
[..]
In Google Maps zei je he? In dat geval is het binnenhalen van de markers (positie, etc) niet het probleem, maar het renderen in Google Maps. Dat duurt lang met veel markers
Nicequote:Op zondag 2 november 2008 00:58 schreef WyriHaximus het volgende:
Trouwens JS compressie is erg leuk! http://dean.edwards.name/packer/ Alles word in eens compleet onlees baar maar het werkt prima
.
Het probleem blijft als je 10 tiles hebt die zichtbaar zijn met ieder 10 markersquote:Op zondag 2 november 2008 11:35 schreef WyriHaximus het volgende:
Ben het zo aan het maken dat hij per tile ze markers binnen haald. Zodat ook alleen voor die tile de markers geapplied hoeven worden op dat moment. Hoe ik dat met markers ga doen die later tevoorschijn gehaald worden moet ik nog verzinnen.
Wat is het voordeel daarvan? Ik heb dat nooit begrepen. De snelheidswinst is toch te verwaarlozen, js files download je toch maar 1 keer en zo groot zijn die files toch niet (zeker niet vergeleken met images ed).quote:Op zondag 2 november 2008 00:58 schreef WyriHaximus het volgende:
Trouwens JS compressie is erg leuk! http://dean.edwards.name/packer/ Alles word in eens compleet onlees baar maar het werkt prima
.
Het kan een beetje dataverkeer schelen. Al gebruikt de echte kekke serveradmin natuurlijk sowieso HTTP compressie zodat het niet nodig is.quote:Op zondag 2 november 2008 21:37 schreef Farenji het volgende:
[..]
Wat is het voordeel daarvan? Ik heb dat nooit begrepen. De snelheidswinst is toch te verwaarlozen, js files download je toch maar 1 keer en zo groot zijn die files toch niet (zeker niet vergeleken met images ed).
Hier en daar? Zeg maar gerust op iedere site die serieus bezig is met front-end optimalisatie, zeker degenen die zich aan de "gouden regels" houden (zoals opgesteld door Yahoo).quote:Op zondag 2 november 2008 21:48 schreef soylent het volgende:
In mijn ogen marginale voordelen die de moeite van het complexere buildproces niet echt rechtvaardigen, maar hier en daar zie je het nog wel eens op sites.
Dat is nog altijd beter dan 10 zichbare tiles met 10 zichbare markers and 10.000 markers die buiten het gezichtsveld toch geladen wordenquote:Op zondag 2 november 2008 14:55 schreef CraZaay het volgende:
[..]
Het probleem blijft als je 10 tiles hebt die zichtbaar zijn met ieder 10 markers
Het is idd om je standaard puistenkop tegen te houden en wat bandbreedte te besparen boven op de standaard HTTP compressiequote:Op zondag 2 november 2008 21:48 schreef soylent het volgende:
[..]
Het kan een beetje dataverkeer schelen. Al gebruikt de echte kekke serveradmin natuurlijk sowieso HTTP compressie zodat het niet nodig is.
En het houdt tot op enige hoogte echte n00bs tegen die de originele code willen zien. Mensen die serieus geïnteresseerd zijn kunnen het meestal wel ontsleutelen, en voor de bekendere packers zijn scripts zo beschikbaar, maar de standaard puistekop die zichzelf h4x0r vindt komt er soms niet doorheen.
In mijn ogen marginale voordelen die de moeite van het complexere buildproces niet echt rechtvaardigen, maar hier en daar zie je het nog wel eens op sites.
Leuke site, dat toen en nu gebeuren. Zitten bijzonder veel bekende locaties tussen, Amsterdam (waar ik nu woon) en Hilversum, waar ik geboren ben en de basisschool heb bezocht. Grappig om al die plekken zo te zien!quote:Op maandag 24 november 2008 19:14 schreef SuperRembo het volgende:
M'n Toen/Nu pagina toont altijd een willekeurige foto. Als je er via Google op terecht komt zag je vaak eerst een foto die niets het zoekresultaat te maken had. Nu heb ik 'm zo aangepast dat ie rekening houdt met waar je op gezocht hebt. Dus Google zoeken naar 'muiderpoort toen nu' geeft nu meteen de goede foto. Het werkt nog niet helemaal perfect, dus ik moet nog wat finetunen.
(En het loopt via de referer, dus als je die uit zet dan werkt het niet)
Ik begrijp er totaal niks van, maar volgens mij begrijp je het zelf ook niet helemaalquote:Op maandag 8 september 2008 21:27 schreef CraZaay het volgende:
Met Shindig aan het kloten (en dan met name de hooks om je eigen OpenSocial implementatie erachter te hangen) en wat met Greasemonkey aan het kloten (op enter rammen in Rabo Internetbankieren ipv op de submitknop te moeten klikken, yay!).
Ik heb ook met Shindig gespeeld, leuk spul. Ik snap het welquote:Op maandag 19 januari 2009 17:51 schreef whosvegas het volgende:
Ik begrijp er totaal niks van, maar volgens mij begrijp je het zelf ook niet helemaal![]()
1 2 3 4 5 6 7 8 9 | db => 'testdb', username => 'root', password => 'doei!' ); my @rows = $db->table('folders')->fetch( where => 'ID > 12' ); my $firstRow = shift @rows; my $rowID = $firstRow->ID(); # returns 13 |
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 | TestLibs::Folder->hasMany('Files')->ofClass('TestLibs::File')->on('folderID'); # one to one relation - a file has one folder TestLibs::File->hasA('Folder')->ofClass('TestLibs::Folder')->on('folderID'); my $folder = TestLibs::File->new( ID => 1 )->getFolder(); # get the folder of File with ID = 1 # many to many relation - multiple files can have multiple tags # first define the link between the 2 objects\ TestLibs::File->hasMany('TagLinks')->in('jt_files_tags')->on('fileID'); # use this link to construct the many2many relation TestLibs::File->hasLinked('Tags')->ofClass('TestLibs::Tag')->linkedBy( role => 'TagLinks' )->on('tagID'); my @tags = TestLibs::File->new( ID => 1 )->getTags(); # get the tags for File with ID = 1 # derived relation - a folder has all tags of its files TestLibs::Folder->hasDerived('FileTags')->via('TestLibs::File' => 'Tags'); |
Ja, die heeft zijn nut ruimschoots bewezen en doet het nog steeds goed, maar is niet echt heel efficient - als je wat ingewikkeldere relaties wil gebruiken gaat de performance heel hard achteruit - het ophalen van bijv 1000 tags van een file dmv een jointabel resulteerde in 1001 calls naar de database, terwijl het in principe ook met 1 query kan. Bij nog ingewikkeldere relaties stijgt het aantal queries exponentieel. Moet je voorstellen hoe traag het wordt als je gaat werken met tabellen van miljoenen rows en 3e, 4e of hogere graads relaties. Dus vandaar dat het tijd werd voor versie 2.0.quote:Op donderdag 29 januari 2009 18:04 schreef slacker_nl het volgende:
Wilde net zeggen, je was toch al met zoiets bezig.
Forum Opties | |
---|---|
Forumhop: | |
Hop naar: |