DIG Digital Corner
Alles wat je altijd al over computers, hardware, software, internet en elektronische gadgets had willen weten, maar niet op Tweakers.net durft te vragen.
En die had hij er zelf al bijgezet. Maar het was nog vroeg en ik had nog geen koffie gehad.quote:Op vrijdag 3 september 2010 09:30 schreef Xcalibur het volgende:
Tuvai bedoelt het begin en einde van de string, dus ^ en $
| 1 |
.
Stroek: Sitethief, die is heel groot en sterk :Y.
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
Ik zie in mijn database (mySQL) steeds staan dat er een 'overheat' is. Ik kan dan op optimaliseer klikken en dan is het weg.. iemand een idee hoe dit veroorzaakt wordt?
Ik weet niks van Hindoes. Wel van Samoerai en andere dingen.
Overhead dus.quote:Op zaterdag 4 september 2010 14:54 schreef boem-dikkie het volgende:
Ik zie in mijn database (mySQL) steeds staan dat er een 'overheat' is. Ik kan dan op optimaliseer klikken en dan is het weg.. iemand een idee hoe dit veroorzaakt wordt?
Overhead zijn stukjes 'vervuilde' / loze ruimte die je tabel/database ooit gebruikt heeft als opslagruimte van een record dat verwijderd is, of voor het uitvoeren van grote queries. Veel databaseplatformen doen dit automatisch, MySQL doet dit niet om zo een stukje sneller te zijn.
Ik heb er zelf al jaren geen last meer van gehad, sinds ik InnoDB ald storage engine gebruik, en records niet meer daadwerkelijk delete (in plaats daarvan zet ik een indicatorveldje op 'true', of een datum).
Ik delete ook niet daadwerkelijk.. maar gaat het in de toekomst nog problemen opleveren? Of maakt het niet veel uit?quote:
[..]
Overhead dus.
Overhead zijn stukjes 'vervuilde' / loze ruimte die je tabel/database ooit gebruikt heeft als opslagruimte van een record dat verwijderd is, of voor het uitvoeren van grote queries. Veel databaseplatformen doen dit automatisch, MySQL doet dit niet om zo een stukje sneller te zijn.
Ik heb er zelf al jaren geen last meer van gehad, sinds ik InnoDB ald storage engine gebruik, en records niet meer daadwerkelijk delete (in plaats daarvan zet ik een indicatorveldje op 'true', of een datum).
Ik weet niks van Hindoes. Wel van Samoerai en andere dingen.
Dat je MyISAM gebruikt gaat je nog wel een keer problemen opleveren ja.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
MySQL met MyISAM als storage engine is, zoals Glowmouse al laat doorschemeren, nou niet bepaald het meest stabiele databaseplatform dat er is. Je zult heel vaak zien dat je overhead zult krijgen, en dat je tabellen bij extreme groei gewoon 'kapot' gaan waardoor je i.p.v. OPTIMIZE TABLE zelfs een REPAIR TABLE commando moet uitvoeren, om het .MYD bestandje (fysieke databestand van MySQL - MyISAM) te repareren.quote:Op zaterdag 4 september 2010 15:14 schreef boem-dikkie het volgende:
Ik delete ook niet daadwerkelijk.. maar gaat het in de toekomst nog problemen opleveren? Of maakt het niet veel uit?
Zie OPTIMIZE TABLE als het defragmenteren van je database.
Overigens wil ik niet zeggen dat MySQL - MyISAM per definitie slecht is hoor. Voor kleine website`jes waar je het over tienduizenden en misschien honderdduizenden records hebt, is het goed genoeg. Maar het is niet geschikt om met miljoenen records om te gaan voor grotere websites / applicaties.
Tabellen gaan niet kapot door hun grootte maar door kapotte hardware of door stroomuitval. In het eerste geval zit je met geen enkele engine 100% veilig.quote:
[..]
dat je tabellen bij extreme groei gewoon 'kapot' gaan waardoor je i.p.v. OPTIMIZE TABLE zelfs een REPAIR TABLE commando moet uitvoeren, om het .MYD bestandje (fysieke databestand van MySQL - MyISAM) te repareren.
Het is alleen goed genoeg als je het niet erg vindt als je data verloren gaat of als users inconsistente gegevens zien.quote:
[..]
Overigens wil ik niet zeggen dat MySQL - MyISAM per definitie slecht is hoor. Voor kleine website`jes waar je het over tienduizenden en misschien honderdduizenden records hebt, is het goed genoeg. Maar het is niet geschikt om met miljoenen records om te gaan voor grotere websites / applicaties.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Ik heb in het verleden een eigen forum gehad (PHP en MySQL - MyISAM) waarvan de Posts-tabel op een gegeven moment richting de miljoen records ging. Die tabel ging steeds vaker gewoon 'kapot', zonder dat er sprake was van een verkeerd ingerichte of kapotte server, of stroomuitval. Nu is het zeker zo dat er op elk platform wel eens iets goed mis kan gaan door een van de oorzaken die jij al noemt, maar ik ben dit tot nu toe alleen nog maar tegengekomen bij MySQL in de praktijk. En vaak ook.quote:Op zaterdag 4 september 2010 18:09 schreef GlowMouse het volgende:
Tabellen gaan niet kapot door hun grootte maar door kapotte hardware of door stroomuitval. In het eerste geval zit je met geen enkele engine 100% veilig.
MySQL - MyISAM is goed voor kleine en snelle dingen. Voor een simpele website met een contactformuliertje en gastenboek hoef ik geen relationele database op de achtergrond.quote:Het is alleen goed genoeg als je het niet erg vindt als je data verloren gaat of als users inconsistente gegevens zien.
Als je het kunt reproduceren dan moet je een bugreport indienen, maar MyISAM gaat echt niet zomaar kapot. Het wordt best veel gebruikt voor datamining, en dan heb je het niet over kleine tabellen.quote:
[..]
Ik heb in het verleden een eigen forum gehad (PHP en MySQL - MyISAM) waarvan de Posts-tabel op een gegeven moment richting de miljoen records ging. Dit tabel ging steeds vaker gewoon 'kapot', zonder dat er sprake was van een verkeerd ingerichte of kapotte server, of stroomuitval. Nu is het zeker zo dat er op elk platform wel eens iets goed mis kan gaan door een van de oorzaken die jij al noemt, maar ik ben dit tot nu toe alleen nog maar tegengekomen bij MySQL in de praktijk. En vaak ook.
Onzin, het is niet voor niks dat MySQL standaard overgaat op InnoDB.quote:MySQL - MyISAM is goed voor kleine en snelle dingen. Voor een simpele website met een contactformuliertje en gastenboek hoef ik geen relationele database op de achtergrond.
eee7a201261dfdad9fdfe74277d27e68890cf0a220f41425870f2ca26e0521b0
Wat is eigenlijk naast tweakers/webwereld en natuurlijk php.net een goede website om up to date te blijven wbt trends in programmering/webdesign?
En wie heeft er ervaring met Git(Hub), is het echt zo goed als men zegt, of hangt dat heel erg af van wat de wensen zijn?
En wie heeft er ervaring met Git(Hub), is het echt zo goed als men zegt, of hangt dat heel erg af van wat de wensen zijn?
Stroek: Sitethief, die is heel groot en sterk :Y.
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
Kan iemand wat linkjes posten naar wat het probleem van MyISAM precies is?
Ik heb er zelf nog nooit problemen mee gehad, en ik vind de exacte rowcount altijd wel prettig....
Ik heb er zelf nog nooit problemen mee gehad, en ik vind de exacte rowcount altijd wel prettig....
Iemand een idee hoe ik op een nette manier parameters kan meesturen naar een include
Dus ik roep aan:
En geïnclude wordt:
Als bovenstaande includen gaat niet, omdat de server dan opzoek gaat naar een pagina die include.php?number=123 heet en niet een pagina die include.php heet.
EDIT: Het doorgeven van variabelen is niet nodig.
[ Bericht 4% gewijzigd door poepeneesje op 06-09-2010 18:17:10 ]
Dus ik roep aan:
| 1 |
| 1 |
EDIT: Het doorgeven van variabelen is niet nodig.
[ Bericht 4% gewijzigd door poepeneesje op 06-09-2010 18:17:10 ]
Aan dit bericht kunnen geen rechten worden ontleend.
als je een variabele boven je include in de eerste pagina defineerd dan word deze gewoon meegenomen in de include
Ik had inderdaad al opgemerkt ja.quote:Op maandag 6 september 2010 19:47 schreef Darkomen het volgende:
als je een variabele boven je include in de eerste pagina defineerd dan word deze gewoon meegenomen in de include
Aan dit bericht kunnen geen rechten worden ontleend.
Nog een vraag 
.
Als de pagina als include opvraag zie ik in Firebug:
.| 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 26 27 | class Database { public $host = DB_HOST; public $database = DB_DBNAME; public $user = DB_USERNAME; public $password = DB_PASSWORD; public function connect() { $connect = mysql_connect($this->host, $this->user, $this->password) or die (mysql_error()); if($connect) { mysql_select_db($this->database) or die (mysql_error()); } } public function disconnect() { mysql_close($connect) or die (mysql_error()); } } ?> |
Iemand die mij kan vertellen wat ik fout doe?quote:Fatal error: Using $this when not in object context in /home/vhosting/k/[..]/htdocs/cms/libs/database.class.php on line 18
Aan dit bericht kunnen geen rechten worden ontleend.
Foutmelding verklapt het min of meer al: $this is alleen beschikbaar wanneer je het over geïnstantieerde objecten hebt. Je dient dus eerst een instantie te maken van je database class/object d.m.v. $var = new Database();, alvorens je $var->connect() kunt uitvoeren.quote:Op maandag 6 september 2010 21:10 schreef poepeneesje het volgende:
Nog een vraag
[ code verwijderd ]
Als de pagina als include opvraag zie ik in Firebug:
[..]
Iemand die mij kan vertellen wat ik fout doe?
MySQL met MyISAM is inderdaad maar een slecht databaseplatform als je het gaat vergelijken met stabielere platformen als MySQL - InnoDB, Orable, SQL Server, enzovoorts. MyISAM ondersteunt onder andere geen transactions en relaties, en er is vrijwel geen data integriteit.quote:Op maandag 6 september 2010 11:23 schreef Xcalibur het volgende:
Kan iemand wat linkjes posten naar wat het probleem van MyISAM precies is?
Ik heb er zelf nog nooit problemen mee gehad, en ik vind de exacte rowcount altijd wel prettig....
Natuurlijk is het veel beter om een relationeel databaseplatform te gebruiken, en je database logisch in te richten.
Toch is het een afweging die je kunt maken. Voor kleine websites met enkel een paar 'platte' gegevenstabellen (gastenboek, tagboard, reacties, etc.), is MyISAM een prima keuze. Voor grotere projecten/applicaties, gebruik je een relationeel databaseplatform.
Of je set die waardes gewoon in je constructor? Dan kun je ze oproepen met this, en meegeven bij het instantiëren van de gehele class....quote:
[..]
Foutmelding verklapt het min of meer al: $this is alleen beschikbaar wanneer je het over geïnstantieerde objecten hebt. Je dient dus eerst een instantie te maken van je database class/object d.m.v. $var = new Database();, alvorens je $var->connect() kunt uitvoeren.
quote:PHP 5 allows developers to declare constructor methods for classes. Classes which have a constructor method call this method on each newly-created object, so it is suitable for any initialization that the object may need before it is used.
| 1 2 3 4 5 6 | $this->dbhost = $dbhost; $this->dbname = $dbname; $this->dbuser = $dbuser; $this->dbpassword = $dbpassword; } |
Stroek: Sitethief, die is heel groot en sterk :Y.
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
Faat: *zucht* zoals gewoonlijk hoor Sitethief weer in de bocht >:)
of je haalt gewoon alle This weg en het is ook opgelost 
.
omdat het publieke variabele zijn kun je ze in alle functies aanroepen.
mits je de waardes in public neerzet
.omdat het publieke variabele zijn kun je ze in alle functies aanroepen.
mits je de waardes in public neerzet
Redacted
Tuvai.net, Sitethief en cablegunmaster: Bedankt voor jullie reactie 
.
Ik heb het zelf als volgt opgelost:
Is dit een goede manier of is jullie manier beter en wil je dan uitleggen waarom?
.Ik heb het zelf als volgt opgelost:
| 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 26 27 28 | class Database { private static $host = DB_HOST; private static $database = DB_DBNAME; private static $user = DB_USERNAME; private static $password = DB_PASSWORD; private static $connect; public function connect() { self::$connect = mysql_connect(self::$host, self::$user, self::$password) or die (mysql_error()); if(self::$connect) { mysql_select_db(self::$database) or die (mysql_error()); } } public function disconnect() { mysql_close(self::$connect) or die (mysql_error()); } } ?> |
Aan dit bericht kunnen geen rechten worden ontleend.
Je zou inderdaad, zoals Sitethief al aangeeft, kunnen overwegen om je verbinding te initialiseren in een 'constructor', een functie genaamd __construct() die automatisch altijd aangeroepen wordt bij het instantiëren van je Database object.quote:Op maandag 6 september 2010 23:28 schreef poepeneesje het volgende:
Tuvai.net, Sitethief en cablegunmaster: Bedankt voor jullie reactie
Ik heb het zelf als volgt opgelost:
[ code verwijderd ]
Is dit een goede manier of is jullie manier beter en wil je dan uitleggen waarom?
Verdiep je ook eens in 'protection levels' (public, private, protected), 'inheritance' en het verschil tussen 'static' en 'non static'.
Als je daarmee overweg kunt, kun je op zich eens gaan stoeien met het bouwen van leuke modellen. http://www.sitemasters.be(...)tected_en_Private%29
http://theserverpages.com/php/manual/en/language.oop5.static.php
Meeste termen kende ik hier al van maar ik dank je voor de linksquote:Op maandag 6 september 2010 23:41 schreef Tuvai.net het volgende:
[..]
Je zou inderdaad, zoals Sitethief al aangeeft, kunnen overwegen om je verbinding te initialiseren in een 'constructor', een functie genaamd __construct() die automatisch altijd aangeroepen wordt bij het instantiëren van je Database object.
Verdiep je ook eens in 'protection levels' (public, private, protected), 'inheritance' en het verschil tussen 'static' en 'non static'.
http://www.sitemasters.be(...)tected_en_Private%29
http://theserverpages.com/php/manual/en/language.oop5.static.php
.en wat hij zegt is een __construct() eigenlijk toch het beste in jou geval.
je hoeft namelijk de waardes maar 1x in te stellen lijkt mij.
dus op zijn netst qua code is Sitethief het efficientst bezig.
Redacted
