Brommerforum.nl - Print: Reply


Deze reply is gepost in de afdeling Main Forum in het onderwerp 'Nachttopic Deel 31 (0.00-07.00)' (ID 50081).
De reply is geschreven door mcdronkz (UserID 2324) op 5-6-2008 0:01.

Check m'n verslag

natuurlijk niet wat we willen. Fatsoenlijke databases hebben hier een mooie voorziening voor: vreemde sleutels of foreign keys. Zo kun je een veld uit de ene tabel koppelen aan de ander. Mocht bijvoorbeeld het Taal_ID gemuteerd worden, dan kun je in de database instellen of die actie wordt tegengehouden, of dat de Taal_ID van de records in “Vertalingen” automatisch gewijzigd wordt. Dit is werkelijk een heel fraaie manier van werken en er is ook altijd zekerheid dat de verwijzingen in de database overeenstemmen met elkaar. In MySQL is InnoDB de enige die dit ondersteund, maar de nieuwe storage engine voor de nog te verschijnen MySQL 6 genaamd “Falcon” zal dit ook ondersteunen. Bij de wat meer professionele databases is dit al sinds jaar en dag gemeengoed.

Dan zijn er dus ook nog de statische teksten. Deze kunnen in een database geplaatst worden, maar ook in een flatfile in het bestandssysteem. Dit is een keuze waarop geen eenduidig antwoord valt te geven en allebei hebben ze hun voor- en nadelen. Het hangt af van de manier waarop de statische teksten in een database gezet worden, of de manier waarop ze in flatfiles geplaatst worden. In de database willen we ze eigenlijk in een mooi genormaliseerd ontwerp hebben, dat is op zich niet zo’n groot discussiepunt. Wat flatfiles betreft wordt het een stuk moeilijker. We kunnen kiezen voor een CSV bestand, een PHP bestand met arrays of globalen erin, een XML bestand of nog talloze andere mogelijkheden.

Een CSV bestand is gewoon niet praktisch. Er zit totaal geen structuur in en de applicatie zal er niet veel sneller worden door het verwerken ervan. Ook is het niet zo fijn om bij te houden, laat staan er een GUI voor te moeten schrijven zodat een ander (bijvoorbeeld de ontwerper) de teksten bij kan houden. In mijn ogen ongeschikt.

Een PHP bestand met (in dit geval) een array erin klinkt al een stuk beter. Met multidimensionale arrays kan het een zeer gestructureerde manier van werken zijn, en ook over de performance hoeven we ons niet al te veel zorgen te maken, mits het fatsoenlijk opgebouwd wordt (maar daar ga ik voor het gemak van uit). Echter is het niet erg leesbaar voor iemand zonder enige vorm van PHP kennis, en fouten worden al gauw gemaakt i.v.m. escaping van quotes en dat soort dingen. Een GUI er omheen ontwikkelen zal vast mogelijk zijn, maar dat wordt dusdanig complex dat het de moeite niet waard is. ’t Zou opzich best geschikt zijn in sommige situaties waar de ontwikkelaar ook de vertalingen beheerd, maar dat soort situaties komen maar weinig voor, zeker in het bedrijfsleven.



Copyright © 2000 - 2016 - All rights reserved